Showing posts with label DHS. Show all posts
Showing posts with label DHS. Show all posts

Sunday, May 19, 2013

DHS Study of Critical Infrastructure Risks from GPS Disruptions

I've blogged about how we are to reliant on GPS, for example see: Are we to reliant on GPS/GNSS? Royal Academy of Engineering says we are. Now the Department of Homeland Security is saying the same thing in the report:

National Protection and Programs Directorate Department of Homeland Security
National Risk Estimate: Risks to U.S. Critical Infrastructure from Global Positioning System Disruptions
The Office of Infrastructure Protection

Bottom Line: U.S. critical infrastructure sectors are increasingly at risk from a growing dependency on GPS for positioning, navigation, and timing (PNT) services. Such dependencies are not always apparent

"Human skills for using manual techniques could erode due to lack of training and practice as GPS becomes more ubiquitous", means that just because we have calculators and computers does not mean we should not teach and learn to do math with paper and pencil, and how to use a sextant. Also few understand how the banking and stock market have become dependent on timing synchronized transactions, at the nano-second or better levels of accuracy and precision.

For more information visit, http://www.dhs.gov/criticalinfrastructure, today. The day-after-tomorrow may be to late. Space Weather is reporting that sunspot AR1748 may release more X-Class flares this week, this time directed toward Earth. See Geomagnetic Storms: An Evaluation of Risks and Risk Assessments, 2011.

See also, The National Infrastructure Advisory Council Final Report and Recommendations on the insider threat to critical infrastructures, 2008 and Critical Infrastructure Partnership Advisory Council 2012 annual update.


Sunday, June 24, 2012

Cyber War or Cyber Peace, are your systems safe?

In May [May/15/2012] Dr. Hamadoun I. Toure', International Telecommunication Union (ITU) Secretary-General, gave a speech High Level Dialogue - The Governance of Cyberspace and Cyberpeace calling for Cyberpeace.

..."We therefore need to act - and we need to act fast - to set up new strategies to ensure cyberpeace at national, regional and international levels.

I am firmly convinced that building an international framework for cybersecurity - with key, high-level principles, such as international cooperation - is vital to ensure cybersecurity and the correct governance of cyberspace.

Governments, the private sector, international organizations and civil society are now called upon to develop the implementation of international norms and principles that will lead to a sustainable and proactive culture of cybersecurity, building on national, regional and international efforts."

Dr. Toure' is calling for cyberpeace because according to Richard Clarke, who served three presidents as counter-terrorism czar, now at Good Harbor Consulting, we have already been deeply involved in a cyberwar for several years.

You may think this is academic exercise, however you may not even have to look far to find a security problem in your own facility. Have you actually taken a close look at that Air Freshener by the file server? Perhaps it is really a Pwn Plug from Pwnie Express, or maybe The New Guy is not really addicted to texting but is using a PwnPhone for industrial espionage.

What brings me to discuss all of this is the recent discovery of the malware known as sKyWIper, Flame or Flamer. Confusion on the name exists due to finding different parts of the same attack at the same time by different organizations, and the controversy over a module named FLAME written in the Lua scripting language. Malware Attribute Enumeration and Characterization (MAEC) is meant to prevent this type of description/naming problem.

Flame (the most popular name in the press) has apparently been evading detection for years and targeting systems in the Middle East. The May 28th 2012 Virus News headline read:

Kaspersky Lab announces the discovery of a highly sophisticated malicious program that is actively being used as a cyber weapon attacking entities in several countries. The complexity and functionality of the newly discovered malicious program exceed those of all other cyber menaces known to date.

The Laboratory of Cryptography and System Security (CrySyS Lab) is publishing sKyWIper (A.K.A. Flame A.K.A. Flamer): A complex malware for targeted attacks, a live document that is being modified all the time as more is learned about this complex cyber attack. The Security List has also put together The Flame: Questions and Answers A.K.A 'the Flame FAQ prepared by Kaspersky Lab; see also Kaspersky Lab and ITU Research Reveals New Advanced Cyber Threat.

The thing I find most interesting is how Microsoft Certificate Was Used to Sign "Flame" Malware. Microsoft's official response: Unauthorized digital certificates could allow spoofing and in their blog. I always did think signing code just so I could install a driver on Windows was nothing but a money making scam, this proves it. Anyone with the wherewithal and the incentive can break anything. Such as compromising Windows Update, Flame malware hijacks Windows Update to spread from PC to PC with a MD5 collision attack.

Marc Stevens from the Centrum Wiskunde & Informatica (CWI) in Amsterdam, known for 'breaking' the MD5 hash function for https security in 2008, analyzed the recent Flame virus: Attacks on Hash Functions and Applications, Marc Stevens. PhD thesis. 19 June 2012, and cryptanalyst discovers new cryptographic attack variant in Flame spy malware.

One almost humorous comment, if it was not for the seriousness of the issue, on Slash Dot:

"It seems the authors of Stuxnet/Duqu/Flame used the LZO library [LZO is a portable loss-less data compression library written in ANSI C.], which is under GNU General Public License (GPL). And so, someone has asked the U.S. government to release the code under the GPL. (Other code uses various permissive licenses. As works of the U.S. federal government, the rest is of course public domain. [I'm not sure that applies to Israeli's claim of involvement?] Perhaps the author could enlist the SFLC to send a copyright notice to the U.S. government...

Under the GPL, only people that the executable was distributed to are allowed to request the code - and since it's a weapon, the US government isn't alliowed to send it to Iran." [Due to International Traffic in Arms Regulations 2011 or the updated Consolidated version with admendments, that is not actually considred "official".]

As an aside, in that past I was involved with a 68000 based system that was destined for a coal mine in China. We had to jump through many State Department/ITAR hoops to get our 68000 approved, as not being to powerful to ship to China at that time. When the mine complained that it did not arrive on time, someone dug into why. We were told, with no way to verify, they found that a Cray Supercomputer fell of the delivery truck and it was taking them a while longer to ship stuff to the mine, so it would not fall off again. Thinking of that incident makes me want to get a XMOS XK-XMP-64 HypberCube Development Board, has more power today than the Cray then...sorry to must get back on topic... Did the assumed government organizations invovled get State Department approval to export this technology to ITAR band countries?

Flame also uses the scripting language Lua. Lua can very easily interfaced with C code. I've used it in embedded systems to handle user interface issues. On the coal mining machine I mentioned earlier it was common for motors and their transducers to be changed in the field. So I set up Lua scripts that the end user could easily edit to put in the proper scaling factors. Many parts of Flame have high order logic written in Lua - with effective attack subroutines and libraries compiled from C++.

Even tho Flame authors order infected computers to remove all traces of the malware, this is probably the beaning of the story rather than the end.

If you have limited time, yet want to keep up on the field then sign up for Bruce Schneier Crypto-Gram Newsletter.

Some organizations have taken to using "active defense" or "strike-back" technology, to turn the tables on their attackers. Does this only end when it has escalated to the annihilation of Mankind? Perhaps you'll want to join the debate on Should There Be an International Treaty on Cyberwarfare?

New publications that are starting to come out of academia and the military and moving into the real world. A good place to get a summary of the security issues we should all be dealing with are the Pocket Guides published by the Department of Homeland Security (DHS) Cyber Security Division Software Assurance Section:

Additional information and resources in software assurance and cybersecurity are available:

Build Security In (BSI) is a collaborative effort that provides practices, tools, guidelines, rules, principles, and other resources that software developers, architects, and security practitioners can use to build security into our products.

Then there are several other organizations such as SAE International, that covers automotive standards getting involved in securing systems. SAE has recently put together the Vehicle Electrical System Security Committee. Does anyone really expect our vehicles to not be attacked at some point? Who's Minding Your Data? The Department of Transportation already thinks it is going to happen: An Introduction to Cyber Security Issues for Transportation.

There is also the SESAMO project that started last month [May/2012] with the goal of integrating security and safety assessment together into methods and tools for model-driven development of embedded systems. SESAMO is one of the many projects of ARTEMIS Industry Association, which is a collaboration of European Government and private industry covering Embedded Systems directly. For example Fostering analysis on industrial embedded systems development process and CHESS: Four pilars for building time-predictable and dependable systems are recent topics of their May 2012 magazine issue.

The March/April 2012 of CrossTalk covered Securing a Mobile World which you can view as Digital Flip Book version (a technique that never fits on any screen I've ever used, forcing millennia-old paper portrait format on to modern landscape screens is never going to work correctly) or download the PDF. As well as Creating Attack-Aware Software Applications with Real-Time Defenses in Vol. 24, No. 5, Sep/Oct 2011 by Coates, Michael, Groves, Dennis, Melton, John, Watson, Colin.

CrossTalk is the Journal of Defense Software Engineering approved by the U.S. Department of Defense. It discusses engineering development of software in order to improve the reliability, sustainability, and responsiveness of the U.S.'s warfighting capability, via new software engineering technologies, and occasionally covers policy decisions.

You may be interested in the SwA Forums, on reliability, security, and the supply chain are their major focus areas.

"In a world where we had made security a must-have in the infrastructure we build on, rather than in the code we develop, think of how much more amazing code could have been written. Instead, we spend endless time in code reviews, following best practices, and otherwise cleaning up after our security-challenged operating systems, languages and platform." -- James Turner.

Now what can we do to prevent our own designs from becoming those kinds of news headlines? For starters many (Most?) organizations need to get out of their comfort zone with dangerous languages like C and look more at languages such as ADA, or even modern C++ with smart pointers if ADA is to big of a leap for Embedded System developers; See also Ada-95: A guide for C and C++ programmers by Simon Johnston.

Some pointers to practical to apply techniques to develop better code, from the SANS InfoSec Reading Room on Secure Code, of which these are Must Read:

  • Securely Programming in C by Sayed Jamil Ahmed. This paper will discuss the main issues in secure programming in the C programming language in a UNIX environment (Buffer Overflows, Format Strings and Race Conditions), topics such as overflows are relevant in Windows, and Embedded Systems too.
  • The Intrinsic Hole In Information Security by Douglas Gaer. The lack of type safety in the C program crates a massive hole in information security.
  • Defeating Overflow Attacks by Jason Deckard. Buffer overflows are the most common of all software bugs, even after decades of being told this. Buffer overflow attacks are detectable and preventable. This paper describes what a buffer overflow attack is and how to protect applications from such an attack.
  • Inside the Buffer Overflow Attack:Mechanism, Method, & Prevention by Mark E. Donaldson. The objective of this study is to take one inside the buffer overflow attack and bridge the gap between the "descriptive account" and the "technically intensive account".

Related items from other sources:

Consider taking the class on Secure Coding in C & C++, to learn of the most common attacks on systems of all types, Embedded included:

  • Buffer Overflows
  • Fundamentals of Shellcode Creation
  • Proof of Concept Exploit Demonstration
  • Null Terminated Byte Strings
  • Standard Library function behavior
  • Integers
  • Integer Overflows & Underflows
  • Integer Promotions
  • Sign Errors
  • Off by One errors

The Software Engineering Institute of Carnegie Mellon has a large section on Secure Coding and Secure Coding Standards.

To close out this our paper here today, Test Driven Development with the help of some basic frame works is something you can start applying today to your systems.

Google C++ Testing Framework. Google's framework for writing C++ tests on a variety of platforms (Linux, Mac OS X, Windows, Cygwin, Windows CE, and Symbian). Based on the xUnit architecture. Supports automatic test discovery, a rich set of assertions, user-defined assertions, death tests, fatal and non-fatal failures, value- and type-parameterized tests, various options for running the tests, and XML test report generation.

CUnit: A Unit Testing Framework for C is built as a static library which is linked with your testing code. It uses a simple framework for building test structures, and provides a set of assertions for testing common data types. In addition, several different interfaces are provided for running tests and reporting results.

CppUnit 2 is a C++ test framework primarily targeted at unit testing, but with high level features that makes it attractiveness for small functional testing. Collection oriented assertions, rich customization, better test organization with test meta data, dependencies, parallelization, time-out...

CppUTest is used extensively in the book Test Driven Development for Embedded C (Pragmatic Programmers) by James Grenning, whom was a signer of the Agile Manfesto.

Bernard Cole, editor at Embedded.com, summarizes several other security techniques in The growing challenge of securing embedded systems.

In the end there are no shortcuts to security and safety. It takes time, money, and proper requirements to build a system that is secure. It also takes a management team with the commitment to make quality products and the vision to look beyond the next quarters proffits.


Saturday, November 20, 2010

Emergency Broadcast Alerts coming to your Cell Phone, baning of Mobile Cell Phones, baning of parental rights...

This week I noted a couple of different items that are a good example of the right hand of the Government not knowing what the left hand of the Government is doing, in the headlines this week. The first being that the Government is establishing a system to push Emergency Broadcast Alerts to our Cell Phones and other electronic widgets. The second is the banning of using Cell Phones while in a vehicle, so we could not get them while moving.

As the first item has some technology relevant to embedded systems I'll cover it first. Over at The Department of Homeland Security's (DHS) Federal Emergency Management Agency (FEMA) we find the following announcement:

"... announced the adoption of a new digital message format for the Integrated Public Alert and Warning System (IPAWS), the nation's next generation emergency alert and warning network. The new digital message format being adopted by FEMA is the Organization for the Advancement of Structured Information Standards (OASIS) Common Alerting Protocol (CAP) v1.2 Standard. This open standard will enable alert messages to be easily composed by emergency management officials for communication with citizens using a much broader set of devices to reach as many people as possible. The three documents defining the FEMA IPAWS technical standards and requirements for CAP and its implementation are: (1) OASIS CAP Standard v1.2; (2) IPAWS Specification to the CAP Standard (CAP v1.2 IPAWS USA Profile v1.0); (3) CAP to EAS Implementation Guide."

First leaving one to wonder what is the Organization for the Advancement of Structured Information Standards (OASIS), and where to find the Common Alerting Protocol Version 1.2 standard.

OASIS, Organization for the Advancement of Structured Information Standards, is a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society. OASIS is a good place to look before you go off and invent yet an other new standard; "The great thing about Standards, is everyone can have their own." OASIS has an Emergency subdivision where we find out the details about CAP.

Abstract:

"The Common Alerting Protocol (CAP) is a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. CAP allows a consistent warning message to be disseminated simultaneously over many different warning systems, thus increasing warning effectiveness while simplifying the warning task. CAP also facilitates the detection of emerging patterns in local warnings of various kinds, such as might indicate an undetected hazard or hostile act. And CAP provides a template for effective warning messages based on best practices identified in academic research and real-world experience."

The OASIS open standards consortium ... announced approval of the Emergency Data Exchange Language (EDXL) Common Alerting Protocol (CAP) version 1.2, a message format for exchanging emergency alerts and public warnings over all kinds of networks. Advanced via an international collaboration of the public and private sectors, CAP 1.2 is now an official OASIS Standard, a status that signifies the highest level of ratification.

EDXL-CAP allows a consistently well structured message to be disseminated simultaneously over many different warning systems. The standard is simple to understand and easy to implement. Its all-hazard, all-media format means it can provide notifications via radio, television, cell phones, email, and other media. The new version of CAP delivers digital signature support, which offers added security and authentication for next-generation alerting systems.

--- OASIS News Augest 12, 2010.

As an aside, the "Earthquake Report" example in the CAP v1.2 Appendix, reminded me of something I wanted to pass on. Check your home owners insurance to see if you have Earthquake Insurance. Unless you live in someplace like California, your house insurance does not cover Earthquakes without an additional rider, which is generally fairly inexpensive. Check with your insurance agent, because the insurance is cheap in places that don't normal have them. However in the history of the North America Continent the biggest Earthquakes happened in places that did not normally have Earthquakes. If you wait till you have even a miner tremor before investing in this cheap insurance, you'll have to wait a month or more before the policy would take effect.

I also came across Alcatel-Lucent's announcement of their new Broadcast Message Center solution to help service providers turn mobile phones into life savers. While I'm sure there is a connection to this and the FEMA announcement above, finding a tangible link to cite eludes me at the moment.

I just hope they don't make me pay for these incoming messages, Cell Phone Spam is a distraction we do not need. What happens during Rush Hour when everyone gets the same message at the same time and no one is looking at the road??

That brings us to the second item I mentioned in the opening of this Blog entry, Cell Phone Distractions.

The Internet rummer mill has miss quoted U.S. Transportation Secretary Ray LaHood as saying the Government is working towards preventing Cell Phones from working in moving vehicles, because of the distractions that they cause.

Over at the official blog of the U.S. Secretary of Transportation, we find out what he actually said about Setting the record straight on technological solutions to distracted driving:

"There's a lot of technology out there now that can disable phones and we're looking at that. A number of [cell technology innovators] came to our Distracted Driving Summit here in Washington and presented their technology, and that's one way. But you have to have good laws, you have to have good enforcement, and you have to have people take personal responsibility. That's the bottom line."

The new Government run site Distraction shows some graphic examples of how Distracted Driving kills.

"U.S. Transportation Secretary Ray LaHood Monday, September 20, 2010 announced that distracted driving-related crashes claimed 5,474 lives and led to 448,000 traffic injuries across the U.S. in 2009. According to National Highway Traffic Safety Administration (NHTSA) research, distraction-related fatalities represented 16 percent of overall traffic fatalities in 2009 - the same percentage as in 2008."

Perhaps the right hand group and the left hand group, should spend some time over at the University of Minnesota's HumanFIRST: Human Factors Interdisciplinary Research in Simulation and Transportation project?

"The HumanFIRST (Human Factors Interdisciplinary Research in Simulation and Transportation) Program employs the tools and methods of psychology and human factors engineering to improve scientific understanding of driver performance and cognitive functions."

In the Law of Unintended Consequences the site Insurance Institute for Highway Safety, Highway Loss Data Institute, tells us in their September 28th, 2010 report that, Texting bans don't reduce crashes; effects are slight crash increases because the Texter is trying harder to hide what they are doing, becoming even more distracted.

Never rely on politicians and bureaucrats to understand what they are doing...



A good example of the good intentions of politicians that turn out badly is Article #2, among many other sections, from the Committee on the Rights of the Child (CRC). The CRC is the body of independent experts that monitors implementation of the Convention on the Rights of the Child by its State parties. Ratified by all nations except the United States and Somalia. Which is something that some in our current Lame Duck Congress what to change before the end of the year. For our international readers, a Lame Duck in this context is a member of Congress that lost their reelection bid, but still has the power to make law until their new replacement is sworn in at the first of the New Year. Since they lost, Lame Ducks are considered the most dangerous kind of politician of all, because they are no longer answerable to their constituents.

Article 2:

"...2. States Parties shall take all appropriate measures to ensure that the child is protected against all forms of discrimination or punishment on the basis of the status, activities, expressed opinions, or beliefs of the child's parents, legal guardians, or family members."

Have you ever meet a child or teenager that did not need disciplined? Sending your Teen to their room for a week for Texting while driving might just cause Lawyers, or worse, to show up at your door...

Sunday, June 20, 2010

Safety and Security Considerations for Component-Based Engineering of Software-Intensive Systems; Engineering software for survivability intro.

In the document known as the AS is State Report [SIC] from the Navy Software Process Improvement Initiative (SPII), the Assistant Secretary of the Navy for Research, in 2007, stated that all systems are to be considered to be Software Intensive, unless a strong case can be made to the contrary. The Navy has been working with other branches of Government to develop plans related to Software Safety.

The Navy and obscure branch of the Department of Homeland Security known as Build Security In, a project of the Strategic Initiatives Branch of the National Cyber Security Division (NCSD), has released a new draft [June 11th/2010] of Safety and Security Considerations for Component-Based Engineering of Software-Intensive Systems.

The Naval Sea Systems Command (NAVSEA) Composition draft is based on the earlier Department of Defense, Joint Software Systems Safety Engineering Handbook, Draft Version 0.95, 2009.

Specifically, the paper discusses:

  • The types of anomalous, unsafe, and non-secure behaviors that can emerge when components interact in component-based systems;
  • Analysis and assessment techniques that can be used to predict where and how such anomalous behaviors are likely to occur;
  • Architectural engineering countermeasures that can be used by the system's developer to either prevent such behaviors or to contain and minimize their impact, thereby mitigating the risk they pose to the safe, secure operation of the system.
  • Architectural engineering techniques and tools that can be used to mitigate many emergent risks and hazards.

The referenced documents on system and software development alone make the paper worth a look.

"Because properties such as safety and security are not intrinsic to individual components in isolation-these properties emerge from the interactions between components or the interactions between a component and its environment or a human user-individual component testing and analysis (e.g., through static and dynamic analysis, fault injection, fuzzing, etc.) can only provide incomplete and indirect evidence of how the component might behave when interoperating with other components within a component-based system. Emergent properties can only be demonstrated through testing that involves component interactions, e.g., pair-wise component testing and testing of whole component assemblies."

I'm not sure I agree with the papers premises that buffer-overflows should be mitigated by 'sandboxing' areas of code that could have buffer-overflows. That might end up being a really big 'sandbox' in some cases. Why not design the code to not allow buffer overflows?

Other sections I find much easier to stomach, such as:

  • Hazards and risks that arise from composition.
  • Parameter-passing issues.
  • Timing and sequencing issues. Right data at the wrong time; firing your 50mm gun before aiming it is not good.
  • Resource conflicts. Race Conditions and Deadlocks.
  • Unanticipated execution of unused/dormant code. One of my favorites pet-peeves is to see 'dead code' in live products.

Section five gives some guidance on FMEA, FMECA, and Hazard Analysis for Component-Based Software:

"As noted in the Joint Software Systems Safety Engineering Handbook, because software has no physical failure modes, Failure Modes and Effects Analysis (FMEA), Failure Mode, Effects, and Criticality Analysis (FMECA),61 and related analysis can be difficult to apply to software intensive systems. This said, software does have functions that can be implemented incorrectly, operate erroneously, or fail to operate at all for various reasons. For component-based software, FMEA/FMECA that strives to identify the causes and potential severity (or criticality, in FMECA parlance) of failures of software functions needs to consider not just errors within individual software components, but errors that may arise from "mismatches", such as expected but-not-received, unexpected, or incorrectly-formatted input from or output to other components."

The Draft goes on to explain ways of mitigating risks.

Unlike most documents out of the Government and Military Academia, this one at least mentions Embedded Software:

"Embedded Software: Software physically incorporated into a physical system, device, or piece of equipment whose function is not purely data processing, or external but integral to that system/device/equipment. The functionality provided by embedded software is usually calculation in support of sensing, monitoring, or control of some physical element of the equipment, device, or system, e.g., mathematical calculations of distances used in calibrating the targeting mechanisms of a weapon system; interpretation and comparison of heat sensor readings in a nuclear-powered submarine engine against a set of safe temperature thresholds."

Alas they still do not grasp the constrained resources of most Embedded Systems.

Appendix C. "Engineering software for survivability" gives a good, short, synopsis what should be considered when designing any Embedded System that needs to keep running, no mater what.