Security

Securing Critical Infrastructure with MILS

By Paul Chen

On February 12, the White House released the Presidential Policy Directive 21 (PPD-21), Critical Infrastructure Security and Resilience. The DHS website describes PPD-21 as “advancing a national policy to strengthen and maintain secure, functioning, and resilient critical infrastructure.” Sixteen different critical infrastructure sectors are identified, including: Chemical, Communications, Energy, Financial Services, Healthcare and Public Health, Food and Agriculture, Nuclear Reactors, Transportation, and Water and Wastewater Systems.

On the same day PPD-21 was released, President Obama also signed Executive Order 13636 for “Improving Critical Infrastructure Cybersecurity.” The Executive Order directs NIST (National Institute of Standards and Technology) to develop a framework for “reducing cyber risks to critical infrastructure,” for which they have issued an RFI and plan a workshop in late May.

And on March 26, the BSI (Bundesamt für Sicherheit in der Informationstechnik, the German Federal Office for Information Security) published the Protection Profile for the Gateway of a Smart Metering System. Such devices will securely collect, process, and store information from smart meters, adding security to smart electricity distribution grids. The protection profile notes that the threat from a remote cyberattack is much higher than that from a local physical attack, since the attacker in network has the potential to compromise not just one, but many components of the infrastructure, or even the corresponding grid.

These developments highlight the focus on improving critical infrastructure security as attacks from cyber-terrorism have increased over the last decade and, alarmingly, in the past year on power, water, and nuclear systems. A recent report states that, indeed, most cyber-attacks now target critical infrastructure, moving “away from hacking and financially motivated crime” to attacks to “deny, disrupt, and destroy” service. For most of us, even the most destructive cyber-attacks like Stuxnet are fairly remote and don’t impact us; but if critical infrastructure services are denied, disrupted, or destroyed, cyber-attacks could become devastatingly personal.

Critical infrastructure systems often use distributed control systems (DCS), industrial control systems (ICS), and supervisory control and data acquisition (SCADA) systems for process monitoring and control. Usually networked and often connected to the public Internet, these DCS, ICS, and SCADA systems are potentially vulnerable to cyber-attacks. Developing more secure DCS, ICS, SCADA systems, and other components of critical infrastructure using the MILS (Multiple Independent Levels of Security) architecture can help improve the overall security of such infrastructure: I explain how below.

The MILS architecture enables security architects to configure the system following the principle of least privilege, which requires that each system component be granted access only to the resources needed to complete its functions. This enables the development of devices and systems that are more resilient against attacks, and better at mitigating potential damage from defective or malicious software. Also, the MILS architecture uses a separation kernel to provide time and space partitioning, information flow control, and fault containment. By providing these capabilities, security-critical components (such as a data guard or process controller) can be separated and protected from less secure components (such as an Internet gateway or network interface) when these components run on the same hardware platform to reduce size, weight, and power (SWaP) requirements. And by reducing SWaP, MILS allows devices and systems to be more cost effective to develop, deploy, operate, and maintain.

Underscoring Wind River’s commitment to delivering trusted systems with built-in security capabilities, we have just launched VxWorks MILS Platform 3.0, which implements the MILS architecture with a secure, hypervisor-based separation kernel compliant to the U.S. Government Protection Profile for Separation Kernels in Environments Requiring High Robustness (SKPP), version 1.03. Although NIAP has sunset the SKPP as the basis of a component-level certification process, NSA continues to recommend the use of separation kernels for security-critical systems, making VxWorks MILS Platform an appropriate choice for use in critical infrastructure sub-systems. And to support a wide range of potential evaluation activities, VxWorks MILS Platform provides a complete set of artifacts to support a system-level evaluation process, based on the internationally recognized Common Criteria.

VxWorks MILS Platform 3.0 is an ideal foundation for building secure, cost-effective, and evaluatable DCS, ICS, SCADA, and other security-critical systems. And it’s available today to help secure national critical infrastructure.

 

For additional information from Wind River, visit us on Facebook. 

Let’s Talk About Securing the Device

By AJ Shipley

In my previous blog post, I touched on the key variables influencing how we approach device security.  In this blog post, I’ll focus the discussion on securing the device.  Before I do, I want to touch briefly on what was a key take away for me from last month’s RSA conference in San Francisco.  This year, the focus was more on big data, the collection of data from connected devices, and analysis of that data to identify malicious or unusual activity.  This is absolutely the correct approach to pro-actively and pre-emptively identify security threats, but it is important to remember that if the device that is providing the data is not secure, you cannot trust the data the device is providing, and most importantly, you cannot trust the device to carry out the actions that the data analysis indicates is required.

At a very high level, I approach security, and security decisions, from two different points of view.  You can either secure the network infrastructure, or you can secure the devices that attach to that infrastructure and communicate with each other.  While nobody would argue that great security requires securing both the infrastructure and the devices, there are different considerations that come with both approaches. 

Infrastructure security has a number of tried and true approaches, and a very mature market full of various products, that provide confidentiality, integrity, and assurance of the data that is traversing it.  Products like firewalls and other security gateway devices provide controls on what traffic is allowed to traverse and what is not.  SIEM’s provide identification of suspicious traffic flows and seek to correlate those flows with contextual information.  Traffic shaping, and other quality of service type constructs, ensure the timely delivery and availability of data necessary for good security.

What’s important to point out though, is that there are a whole host of security concerns and potential vulnerabilities that are exposed before a device ever gets close to communicating with another device over the network infrastructure.  Device security, and the protection of the data at rest, in use, and in motion, that originate from the devices, must be addressed with multiple layers of security features on the device.  Those security features must start from the time that power is applied to the device to the time that it is retired from service and ultimately destroyed or disposed of.

Secure devices involve building a chain of trust across the device stack, and anchoring that chain of trust with a root of trust that is immutable, or cannot change.  The following diagram is a an architecture agnostic view of a secure device, and what is important to remember is that regardless of the underlying hardware architecture, or the associated operating system architecture, the point is that a secure device requires multiple layers that extend the trust anchor from the hardware, into the operating system, across the middleware and communication stacks, and into the application space.  And we can’t forget the importance of both a secure development process, and secure development tools that are critical in building a secure device, as well as the need to test for security throughout the development lifecycle and prior to deployment.

I’ll conclude by saying that the operating system holds the key to delivering a secure platform.  Whether you want to take advantage of hardware security capabilities such as secure boot, hardware based key-stores, or anti-tamper technologies; or you need operating system security constructs such as access control and least privilege; or as you move up the device stack to include secure middleware, such as host based intrusion prevention systems and firewalls, or secure communication stacks like IPSec, SSL/TLS, or SSH, or application security features including application sandboxing, whitelisting, or verification of signed applications – the list goes on, but in all of these instances, the common denominator  is the need for a robust and reliable operating system. 

In my next post, I’ll dive into some of the more technical aspects of device security…more to come.

For additional information from Wind River, visit us on Facebook.

The CWE/SANS Top 25 Most Dangerous Software Errors: What it means for embedded developers

By Bill Graham

The CWE/Sans Top 25 is fairly well known among security experts but might be overlooked by embedded developers since the list covers all types of systems and programming languages. Developers are fully aware of the quality impacts of many of these errors however they may be less knowledgeable of the security implications. The classic example is the buffer overflow error – all programmers know this is a bad thing and can cause a program to crash or become unresponsive. However, many developers fail to realize that an attacker can trigger these errors to execute code, reveal data or cause a denial of service attack.

The Top 25 list is a “who’s who” of dangerous errors that are the most commonly reported security vulnerabilities. This year’s RSA conference theme was ‘Security in Knowledge,’ and Wind River couldn’t agree more -- mitigating the risk of these errors is the first step to improving your device’s security. In this post I will point out what the 10 most important errors are from the top 25 list that embedded developers need to be aware of. In a subsequent post I’ll discuss the mitigation strategies and the role of automated tools in detecting and removing these errors.

The Big 10 Coding Errors and Impact for Embedded Developers

Some of the Top 25 are more applicable to embedded developers than others and arguably have a different priority. Also, some of the errors are from coding errors while others are configuration errors (or a combination of both.) In this case we’ve identified Wind River’s choice for the vulnerabilities that are most likely to impact embedded developers from this list. The “Big 10” errors that embedded developers are likely to encounter are as follows.

CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

The buffer overflow is the most common coding error that embedded developers are likely to run into and can have serious security consequences if exploited. By definition, a buffer overflow is causing a runtime error where the index of a buffer accesses memory outside the bounds of the buffer, array, string, etc. Embedded developers need to be particularly aware of buffer overflow errors since much of their coding is in done in C or assembler where such errors are commonplace because there are not any strict boundary checking mechanisms. Also, embedded developers may not be in the habit of checking input data (even from within the system, from disk or flash storage, for example) to ensure it isn’t out of bounds.

CWE-250: Execution with Unnecessary Privileges

A typical Linux/Unix problem, tasks, threads or processes running at high privilege levels (e.g. root in Linux) have access to any file and can execute any command or system API. If such a process is compromised for example, to execute injected code, runs at the highest system privilege level. Only essential code should be running at the high privilege level (or kernel level in an RTOS) – vulnerabilities at this level would do the most damage.

CWE-311: Missing Encryption of Sensitive Data 

Critical data in your system should never be stored or transmitted in clear text. Any data stored in files, on flash memory or transmitted over the network should be encrypted. Private user information, system control and sensitive data need to be encrypted. Embedded systems have, in the past, relied on their isolation from a public network and relative obscurity to keep data safe. This is no longer acceptable; any device that can potentially store sensitive information should use encryption. For example, home medical devices should store all patient data in encrypted form. Any transmission of this data over a mobile or home network should be encrypted.

CWE-807: Reliance on Untrusted Inputs in a Security Decision

Any input from outside the system must be considered untrusted. Using this input data as input into critical functions can have serious security ramifications. If this input is used in security decisions within the code, it can be exploited. Although embedded systems may not have human input directly, any data from files, networks or peripheral devices is untrusted and needs be validated before use.

CWE-306: Missing Authentication for Critical Function

Authentication should be required for critical functions in the system. Creating or updating sensitive information should be done on behalf of an authenticated user, for example.  Also, any function that has critical system impact or possibly consume a large amount of system resources should be authenticated. Embedded systems may not have authentication in place per se, but if critical functions are being performed on the behalf of user input (e.g. from an HMI) then that user should be authenticated.

CWE-494: Download of Code Without Integrity Check

Embedded systems are likely to need patching and upgrades out in the field. Applying patches should only be done with validated code from the manufacturer. Without proper integrity checks of upgrades or downloaded applications, it’s possible to insert malware into the system. To combat this, downloaded applications and code could be encrypted and signed by the manufacturer.

CWE-798: Use of Hard-coded Credentials

This is, unfortunately, a commonplace problem in embedded systems – relying on hard-coded credentials to access a system’s user interface or network-based shell. These are often manufacturer back door access methods for a device. Unless a manufacturer or system integrator changes the defaults (or forces initialization), these hard-coded credentials end up in the field. Manufacturers must configure embedded systems to avoid hard-coded credential especially when devices are deployed.

CWE-327: use of a broken or risky cryptographic algorithm

There are factors inhibiting modern encryption in embedded systems; processing power to encrypt/decrypt data especially in real-time, OS support for up-to-date cryptographic algorithms, and long product life spans where outdated techniques are still used. Cryptographic libraries in embedded systems need to be kept up to date as technology changes, and devices need to be configured to use the strongest yet computationally efficient encryption possible. Also, embedded system processing power has increased significantly even in low power devices making the overhead of cryptography less onerous.

CWE-30: Improper Restriction of Excessive Authentication Attempts

Although not unique to embedded systems, it can be particularly dangerous to not limit the number of authentication attempts (e.g. user login attempts for a controller user interface.) A combination of hard-coded credentials and weak encryption means that brute force authentication attacks are feasible on embedded devices. Limiting the number of attempts is a simple way to thwart or at least slow down brute force attacks.   

CWE-22: Path Traversal

If user, file, or network input data is used to construct a path name, it is possible to traverse the device’s directory structure if proper input checks are not performed. This vulnerability can allow for the leaking of private and sensitive information, the replacement of libraries and executables with malware, or corrupt system settings. As with any external data to the system – it must be validated before use.

Mitigating the Risk

Although the CWE/SANS top 25 and our Big Ten list here can be daunting, there is plenty that can be done to mitigate the risk of these dangerous software errors to your embedded device. Performing a threat assessment, using specific software tools, following coding best practices and the right runtime technologies can go a long way to improving system security. It’s essential that security be viewed as an entire device lifecycle issue and it must be built in from the beginning. “Bolting on” security after a product is nearly ready for production is a recipe for disaster. In subsequent posts, I’ll be discussing mitigation strategies and software tool automation to make the Big 10 much less of a risk.

For additional information from Wind River, visit us on Facebook.

Top Five Variables Influencing the Approach to Device Security

By AJ Shipley

In my previous blog post, I covered the importance of having security built in and not bolted on.  In this blog post, I’ll outline the top five key variables that are influencing how we approach device security -- a topic particularly top of mind as I spend this week at the RSA Conference.

1. Connectivity to the enterprise and cloud.  Historically, embedded devices, while network connected, operated on proprietary protocols and dedicated networks.  A “great wall” so to speak, existed between the networks that powered our critical infrastructure, for example, and the networks that powered our enterprises.  However, due to the pervasive nature of Ethernet there is a desire now to leverage all of the security expertise that we have gained over the past 20 years deploying commercial grade enterprise networks and apply it to our embedded systems -- and then extend this when connecting to the cloud.  Herein lays the potential for huge productivity gains by leveraging the same infrastructure to collect data, analyze it, manage and update our devices, etc.  Along with the potential productivity gains comes the reality that we are now exposing our embedded devices to threats that they have never had to deal with before and probably aren’t suited to handle in the same manner that our enterprise infrastructure is.

2. Vertical integration.  We’ve seen Apple do this masterfully for years by controlling both the hardware and the software of their devices, and this same trend is now taking place across multiple industries.  Microsoft is getting into the game with its new “Surface” tablet and other operating systems designed to function on more mobile devices.  You also have traditional “hardware” or “silicon” vendors who are reaching up into the software stack and building more complex “software” features into the hardware.  So you have an environment where the lines between hardware, software, and application are blurring significantly.  Effective security, which requires multiple layers that are built in to the device, must now take into account the tighter relationship between hardware, software, applications, and infrastructure.

3. Complex regulatory environment.  It’s no secret that we are operating under an increasingly complex regulatory environment.  Typically each industry has its own set of regulations that products must meet prior to operation.  The interesting thing is that functionally, the majorities of these requirements are the same and can be met with similar approaches, however, identifying what specific regulation that a particular product or industry is governed by, and keeping pace with the changes is adding additional stresses to embedded device security.

4. Secure supply chain challenges.  Supply chain challenges are not new, but securing the supply chain is often times an afterthought.  The location of manufacturer, depending on the industry that you are operating in, can have significant repercussions on how and what security mechanisms must be in place.  Furthermore, the potential to impact the end devices or infrastructure by attacking non-manufacturing supply chain partners, like certificate authorities, domain name servers, or security vendors is a threat vector that is often times overlooked.

5. Safety and security.  Finally, from an embedded perspective, for a number of years the primary concern was the safety of the systems and making sure that we were protected from them in the event of a failure.  Now security has come to the forefront, which shouldn’t be a surprise because safety and security are really just different sides of the same coin.  Safety is about protecting the world from the devices, and security is about protecting the devices from the world. 

The organization that can assimilate, process, and make sense of these disparate factors, and understand the inherent security tradeoffs that must be made to be successful as a commercial entity will leapfrog their competition while at the same time staying off the front page because of a security lapse.

In my next blog post, I’ll discuss the two points of view from which I approach security and security decisions – the secure platform vs. the secure infrastructure, as well as touch on key takeaways from RSA...stay tuned.

For additional information from Wind River, visit us on Facebook.

Security Must be Built In…Or Else

By AJ Shipley

Security cannot be bolted on, it must be built in.  This statement proves to be especially true when considering the recent hack of the New York Times, where during a four-month long cyberattack by Chinese hackers, the company's antivirus system from Symantec missed 44 of the 45 pieces of malware installed by attackers on the network.  Cases like this highlight the danger of relying on a single security product to keep you safe from hackers.  According to a written statement by Symantec, "Advanced attacks like the ones the New York Times described underscore how important it is for companies, countries and consumers to make sure they are using the full capability of security solutions. Antivirus software alone is not enough." 

As evidenced with incidents like this, products need to be developed that combine multiple layers of security to keep the “bad guys” out of customer systems, and to also minimize the danger and exposure to device resources and data if they do get in. 

Products like the Wind River Intelligent Device Platform (IDP), a software platform built for developing next-generation smart systems, are a perfect example of what I mean by building security into the product. IDP provides multiple layers of security that are all highly configurable and customizable.  Security policies are developed that match the specific deployment scenario with the correct level of access control and integrity monitoring, providing a true architectural, defense in depth approach to securing embedded devices and machine-to-machine applications. 

Specifically, IDP includes Secure Remote Management (SRM), which ensures the integrity of the system with boot time security using Trusted Platform Modules (TPM) and Trusted Software Stacks (TSS).  Advanced security features like address space layout randomization (ASLR) and non-executable memory pages make it exceedingly difficult to penetrate IDP.  Run time security and integrity is monitored with the built in integrity measurement architecture which immediately detects when system files have been tampered with.  SRM provides a robust access control infrastructure for limiting access to system resources based on the privilege levels of specific users or groups of users ensuring that if a bad guy gets in they can’t access any of the critical resources or information.  Finally, secure package management remotely deployed over secure communication channels ensure that software updates are intact and trusted prior to installation. 

Anti-malware products, like the one deployed at the New York Times, are an important component of an overall security strategy, but are nowhere near sufficient to protect systems, resources, and information from the advanced persistent threats that are on the rise.  We can no longer assume that we can successfully keep the bad guys out of our systems.  A good security strategy must first understand the multiple attack vectors and then deploy solutions that provide multiple layers of defense to deter, detect, and defend our critical resources. 

For additional information from Wind River, visit us on Facebook.

 

The Role of Tools in Improving Embedded Software Security / Part 3: Mapping the Tools to Activities

By Bill Graham

In the previous posts in this series, Part 1: Automation is the Key and Part 2: Security Improvement and the Software Development Lifecycle, I talked about the connection between the typical embedded device development process and the 5+1 improvement framework for embedded security.  Figure 1 is an illustration of this connection (and discussed in more detail in a previous post).

Figure 1: Mapping the security improvement framework and the device software lifecycle

In this post, I’m going to map out the tools that can help improve security and where they fit in the development lifecycle. Tools have different parts to play at each phase of the lifecycle, in some cases they are used throughout, and in others, their role is key in one phase and less so in others. In terms of security improvement, many of the tools and processes mentioned are not unique. In fact, the ideal situation is where security is considered a first class citizen in the priorities of a project.  In this respect, tools for requirements, modeling and change management are meant to be used in the same fashion and don’t represent unique capabilities required in the 5+1 improvement framework. Again, the better the requirements and risk management, the better the security solution (assuming that security is given the right priority.)

Figure 2 illustrates roughly where each class of tool plays a role in the embedded device lifecycle. In each case, the unique capabilities required for improving security are called out but these don’t preclude the tools used in other areas.

Figure 2: The mapping of major tools categories in the software lifecycle

The Tools

System Simulation

High fidelity, system-wide, comprehensive simulation is an invaluable software development too. State of the art simulators are more than just processor emulators, today they provide full networked system, board, peripheral and processor simulation. The key benefit of system simulation is pulling in your integration and test cycles much early than previously possible. Secure design and system vulnerability can be tested earlier and more often. In addition, simulators offer unique features that real hardware can’t do and the ability to arbitrarily inject faults at any part of the system. An example of a system simulation tool is Wind River’s Simics product.

Integrated Development Environment

The Integrated Development Environment (IDE) is the developer’s desktop. Most developers’ tools integrate into the IDE in order to be visible and usable from this desktop. All of the tools discussed here are integrated with the IDE. IDE’s also provide many tools that are useful in improving security. For example, memory (runtime) analysis tools are critical for finding buffer overflow errors that are the root cause of many security vulnerabilities. System behavior and analysis tools are critical for tracing complex defects – essential for detecting and debugging security issues. An example of an IDE is Wind River Workbench.

Static Analysis

Static analysis tools analyze source (and sometimes binary) code to find defects, security vulnerabilities and other programming issues. These tools can work on existing code bases and on new source as it is written by the developer. The key advantage of using static analysis is that security vulnerabilities are found as soon as the code is written – the cheapest and least riskiest time to find and fix them. In addition, vulnerabilities can be found in “hidden” parts of the code – code that is not executed during traditional testing. Static analysis tools can be run individually within each developer’s IDE and singularly on the project build providing a distributed and centralized analysis capability. Examples of static analysis tools include Coverity’s Security Advisor, Klocwork’s Insight, Programming Research’s QA-C/C++,  and Grammatech’s Codesonar products.

Build and Continuous Integration Tools

Modern iterative and agile development methods require more frequent build and test cycles. Proper tools support for high frequency build and test in order for the productivity and quality gains of new methods to pay off. These tools provide the same benefits for security assessment and testing – security vulnerabilities can be found, fixed and test in a short cycle. As development methods evolve to include secure development, the return on investment for state of the art build and integration tools increases. An example in this area of tools would Electric Cloud’s ElectricAccelerator and ElectricCommander products.

Test Automation and Management Tools

Increased testing effort of developing an embedded device is the largest factor in its schedule and cost impact of improving security. Typically, testing for security vulnerabilities requires additional testing that differs from functional testing in that is attempting to break the system. Most functional testing is looking at most common usage patterns of the device. Security testing is often looking at edge cases, erroneous input, and misuse. In addition, test automation tools are required to improve test efficiency and effectiveness. Security testing will add risk, cost and effort to the testing effort for an embedded device. However, innovation in testing tools has made this impact significantly smaller. An example tool in this category would be Wind River Test Management.

Robustness and Fuzz Testing Tools

Due to the nature of security testing – often requiring out of range and erroneous data - new tools are required. Fuzz testing tools are designed to send malformed data to the device to induce errors. These tools use knowledge of various communication protocols (including specialized embedded control protocols) to create incorrectly formed packets, bad data and various extreme cases. Often this data is enough to induce runtime errors in the device – exposing potential vulnerabilities. These vulnerabilities are previously unknown (so called zero-day vulnerabilities) are especially critical to find and fix. Fuzz testing can be applied well before the device is in final form. Leveraging system simulation, fuzz testing can used in a simulated environment as effectively as it is in the lab.  An example of a fuzz testing product is the security content package for Wind River Test Management (with technology licenses from Codenomicon).

Risk and Threat Management Tools

It’s likely that few embedded development projects are currently using automated risk and threat management tools. These tools are often used in highly safety critical projects where risk management processes are stringent and detailed traceability is required. However, these tools can prove valuable to any team that needs to maintain detailed information about their risk and security threat management plan. Automating the management security threats from early threat assessments all the way through the device lifecycle is important as a way to organize and retain the details, record the threat analysis, drive security test and fix priority, and end-to-end traceability. In addition, as security requirements start to become part of various industrial standards, threat management tools become increasingly essential. An example of this would be RSA Archer Threat Management.

Application Lifecycle Management Tools

Application Lifecycle Management (ALM) tools cover a wide variety of tools that are aimed at improving software development productivity and quality while managing and limiting schedule and budget risk. Requirements and change management, modeling and analysis tools, test management, product portfolio management and more. These tools are important for productivity, quality, compliance and security. Although not specific to security, incorporating security requirement management, secure design and security testing into the ALM scope is critical. In other words, the tools manage the security design lifecycle as they do the mainstream software development lifecycle. Examples of the ALM tools would be the IBM Rational suite of tools.

Summary

Tools are key to developer productivity and critical in improving security in embedded devices. In this age of increased scrutiny of security (and certainly other quality characteristics) and increased pressure for more features and tight schedules and budgets, the need for tools is greater now then ever. In this post I’ve mapped the tools to the embedded device development lifecycle and to the 5+1 step security improvement framework and what role each class of tool plays in the security improvement framework. I’d like to hear if there are other classes I’ve missed in the list and what tools you’ve found to be the most useful for improving your product security.

 

For additional information from Wind River, visit us on Facebook.

Medical Device Security

By Jeff Fortin

A recent study published by GAO caused quite a bit of uproar over medical device security. The GAO declared in its report [read more] that the FDA has not put enough oversight in the premarket approval (PMA) of certain medical devices that are susceptible to threats. In the report the GEO referred to an experiment described in the 2008 IEEE Symposium on Security and Privacy. The experiment was conducted by a number of experts in security, medicine and engineering. They demonstrated the potential for a hacker to expose patient information as well as interfere with the correct operation of a medical device. The FDA has agreed to the GAOs insights – however pointed out that there have been no real world threats that have been reported to date.  According to the FDA, it did consider unintentional threats for information security, but did not consider information security risks from intentional threats until recently. In summary, the HHS – governing body for the FDA, concurred with the GAO recommendations and have initiated activity in this direction.  Medical device manufacturers must take the threat of security seriously.

Of all medical devices, devices that are implantable, portable or used in a home health scenario represent a growing concern for security and information privacy. I refer to these classes of devices as embedded medical devices. Developers and manufacturers of embedded medical devices are increasingly exposed to security risks as these devices become more complex and also connected to open networks. The good news is that in responding to this threat they need not operate in a vacuum nor do they need to re-invent the wheel. Best practices exist in other industries that can be leveraged by medical device manufactures. Of them the most straightforward is to design your products with security in mind. In other words, design for security. Here are a few things to think about when you design your medical devices.

 Pre-market: Design for safety and security

Step 1: conduct an end to end threat assessment. Identify the threats, evaluate the impact of the test not only from the point of view of the manufacturer but also the end user and the ecosystem in which the device gets deployed.

Step 2: Develop an advanced system design for security. This may involve defining the workflows, partitioning the safety-critical function from non-critical functions, keeping the basic functionality alive in case of an emergency et al.

Step 3: Select the proper run time platform: Leverage technology such as a secure OS, embedded virtualization, and interoperable middleware. Also be sure to follow best practices regarding run-time and network configuration to improve the integrity of your design.

Step 4: Select proper tools and testing infrastructure for securing the systems

• Create a software development plan following an established software development methodology (examples: IEC 62304, IEEE/EIA 12207)
• Requirements analysis and traceablility
  • Requirements should include
    • Security manual including Standard Operating Procedures with a  method for updating
    • Risk mitigation requirements as identified in the End to End Threat Assessment
• Test Plan and Test Case Repository (Wind River Test Management)
  • Include vulnerability testing to validate risk mitigation requirements
• Identify data needed from the test results to support 3^rd party reporting
• Test Framework to help identify potentially malicious code
• Test mechanism to simulate hacker attacks
• Industry standard Fuzz testing to ensure protocol robustness

Production: Validate the system and ensure the right software is loaded into the system with no malware.

• Validation and authentication is a relatively new domain for certain medical devices. Methods used in the IT space tend to assume a reliable, cheap and nearly permanent connection to the end device. Such assumptions are not always possible for medical devices that are either implantable, portable or used in a home health scenario. But there is technology available that could help here. Authentication services for access to the device as well as secure updates and secure boot technology are available for these types of devices. For instance in the upcoming release of IDP 1.0, Wind River will be including a Secure Boot feature that will leverage the root of trust and the Trusted Platform Module (TPM) to ensure that the software on the device is authorized by the manufacturer.

Post-Market:

• Secure your applications. Lock down your applications to prevent unintended data access or  denial of service. McAfee provides excellent guidance as to how to qualify the applications that run on your product so as to prevent intrusion.
• Adopt a comprehensive life-cycle support process. Security is a constantly evolving problem. Include security updates in the lifecycle management of your device. The current published practices on this topic such as IEC 80001-1:2010 generally only address enterprise applications but Wind River has been helping companies deploy secure embedded devices for decades and can help your company do the same.

Waiting for the adverse event to happen and reacting to security afterwards may be very costly. Think Stuxnet and how it is changed the way the energy sector looks at security. We can be proactive and design for security in medical devices. While designing security consider both the enterprise and the embedded aspects of security. The embedded security part is often overlooked and can seriously undermine the efforts in locking enterprise security at the back office and servers. After all, information (data) originates at the embedded devices and the integrity of this data determines all the workflows that follow it.

 

For additional information from Wind River, visit us on Facebook.

First Line of Defense

By Ka Kay Achacoso

Designing security into a device requires an understanding of the nature of the attacker.  The cost of security implementation, including  acquiring the technology carrying out the processes, scales up with attacker sophistication.  A rule of thumb is to make the device tampering cost higher than the benefits gained from a security breach.   

Wind River’s VxWorks real-time operating system platforms come with a set of simple security measures that protect the VxWorks applications against some clever hackers.  At the Intel Developers Forum (IDF) in San Francisco next week, we will be demonstrating several layers of protection that come with the operating system (booth No. 400).

In this blog post I will outline a few simple security measures, already available in the VxWorks platform, that deter attacks on the VxWorks system. 

For networked devices, remote access to a device can be protected by implementing a network firewall.  Certain security functions can be limited to be locally accessible only.  Wind River Firewall for VxWorks is already part of the market-specific platforms like Platform for Industrial Devices.   Security processes around firewall configuration access can be implemented.  For example, opening a port in the firewall requires authentication with username and password, or the administrator needs to be physically present to make changes.

Encryption can be applied to all messages passed through the network ports.  For example, Wind River Firewall can block all traffic, but open a window into an SSH shell. 

For additional security against VxWorks experts, it can be ensured that all software modules loaded are from a reliable source and unmodified.  For any modules loaded, including VxWorks kernel images, downloadable kernel modules (DKM), and real-time processes (RTP), attach a digital signature to it and make the loader verify that signature.    At IDF, our demonstration will show an example of our engineering team’s implementation of binary authentication to protect our devices from loading unauthorized software.

For those attackers who try to inject fault into a system in order to bring the whole device down, VxWorks kernel hardening features implements a series of measures to contain the fault to the rogue software and cleanly remove the faulty tasks without affecting the rest of the system.  As an example, these features will detect and report any attempts to write into the text section, preventing an attacker from changing program execution.

It may be possible that some or all of these security measures will sufficiently meet the required security needs.  Beyond these measures, if protection from highly sophisticated, heavily funded and organized attackers is required, there are other products and services from Wind River and our partners that can bolster your security.

 

For additional information from Wind River, visit us on Facebook.

The Role of Tools in Improving Embedded Software Security / Part 2: Security Improvement and the Software Development Lifecycle

By Bill Graham

In many of my previous posts, I’ve discussed Wind River's 5+1 step improvement framework for embedded device security. By design, it’s meant to complement the software development lifecycle (SDLC) that our customers are using – the stages or phases how they define them and the processes they follow. It’s important for a discussion on tools to put them in the context of the SDLC to see where they apply and how they are useful beyond just the coding stage.

Figure 1 shows the relationship between the SDLC and our security improvement framework. The phase names and number of phases may change from customer to customer but the general idea remains the same. It’s important to note that the improvement framework is equally compatible with Microsoft’s Secure Design Lifecycle that is gaining traction amongst embedded developers too.

SDLC and 5+1 improvement framework diagram

Figure 1: Relationship between software development lifecycle phases and the security improvement framework.

Security-Related Activities at Each Phase of Development

The activities the development team needs to perform at each stage of development to increase system security is outlined in Figure 2. This is representative rather than exhaustive but provides a good outline of what needs to be done.  As I discussed in a previous post, many of these activities are new and now part of the project plan where they likely weren’t in previous products. Assisting with these activities with tools and services is where a vendor like Wind River can make the difference in meeting your project and security goals.

Figure 2: Various security-related activities in relation to the software development lifecycle.

The details about the phases and names of the development lifecycle (and the processes used such as Agile development) are interchangeable. This Development, system simulation and testing tools play a big part in automating these activities, and in my next post, I’ll discuss how Wind River’s and our partner’s tools fit into this framework.

 

For additional information from Wind River, visit us on Facebook.

The Role of Tools in Improving Embedded Software Security / Part 1: Automation is the Key

By Bill Graham

Security Vulnerabilities are Expensive

Shipping security vulnerabilities in a finished product and having them discovered or worse, exploited, is a very expensive proposition for embedded device vendors. As I’ve discussed in an earlier post, security defects are much more expensive to patch and fix the later they are discovered. If you’re lucky to catch a vulnerability during development, you can likely save your company and project thousands if not hundreds of thousands of dollars. So, security vulnerabilities are expensive and costly not only in dollars but in reputation and customer satisfaction.

On average, a vendor loses around 0.6 percent value in stock price when a vulnerability is reported. This is equivalent to a loss in market capitalization values of $0.86 billion per vulnerability announcement.  --Telang & Wattal 2007

Security needs to be designed into a product rather than tacked on late in development, or after it has shipped. With this in mind, it’s critical to look at software tools as productivity enhancers for the entire software development lifecycle. Moreover, security has quickly become a critical requirement for many embedded devices that might not have addressed security as closely in the past. In other words, security has quickly become the new and important developer “pain in the neck.” In order to effectively deal with security, tools bring automation that make improving embedded device security more practical. After all, your product still needs to be shipped on time, within budget and with the features and quality your customers expect from your brand.

Automation Increases Productivity

Tools play a role in all parts of the embedded device development lifecycle (I’ll elaborate in more detail in a future post how the tools fit with the software lifecycle and Wind River’s 5+1 step security improvement framework). New security requirements for embedded devices introduce new design, development and testing workload for device development which conflict with the same needs for the actual device functions (i.e. “your regular job”). Also, security often requires looking at the design from a different perspective – as an attacker to the system – and often testing the system in ways it wasn’t meant to be used.

Discovering possible threats to your system is a significant effort. However, finding vulnerabilities you haven’t thought of is nearly impossible. Tools such as fuzz testing and static analysis can do just that. Performing subsystem testing on a virtual simulated environment well before you normally would, will save you time and money. Leveraging your existing application lifecycle tools (or adding them if you don’t have them) can help you manage security requirements, design and defect analysis more efficiently than manual techniques.

Improving security in embedded devices will certainly add more work for your development team, but there are tools and processes available and ready to be used to decrease the risk and costs associated with this new reality.

 

For additional information from Wind River, visit us on Facebook.