Improving Embedded Device Security: Adopt Comprehensive Lifecycle Support

By Bill Graham

Bill GrahamSecurity is constantly evolving as threats change over time. As a device becomes popular (Stuxnet targeted the market-leading PLC) or exists in the market longer, it becomes more susceptible to attack. Many devices in the past were not designed to be field programmable or accept updates without significant modifications. Those days are gone. Devices today must be field upgradeable to not only change and improve functionality, but to deal with bugs and security issues. Including security planning in the life cycle management of your device is critical. Moreover, it’s important that your organization deal with security vulnerabilities as they arise with high priority and rapid response times. Equally important is that you can rely on your COTS vendors to do the same; these components are an integral part of the lifecycle support plan. Steps to consider include (but are not limited to) the following:

  1. Plan for lifecycle support early: Security is an ongoing concern and it is important to plan for a product lifetime of security analysis, support, and patches.
  2. Architect for change: Security updates to field products require the ability to be patched and modified over time. Designing in patching and update support is critical.
  3. Design and test for security: Security vulnerabilities are a class of software defects –in design or implementation – and the earlier in the development lifecycle we catch them, the less costly it is to fix them and harden our system against attack. However, security testing differs from traditional requirements-driven functional testing, which is positive testing, designed to see how well the product meets the specified requirements. Security testing is a type of negative testing focused on finding where the actual exhibits behavior not found in the specifications. Security testing must be done with a different mindset –you need to think and act like a hacker. Techniques such as fuzz testing or pinpoint penetration testing, which simulates the attack vectors used by malicious hackers, are effective tools. Given the need to balance security needs with market demands, management and automation of security testing, as well as simulation tools greatly increase embedded development productivity.
  4. Assign high priority to security vulnerabilities and defects: Security needs to be considered a high priority in design, but also during support and maintenance. Vulnerabilities, when discovered by the security community, become public knowledge within a relatively small amount of time. Companies are given this grace period to respond and potentially patch their products.
  5. Create a security response team: This is needed to address vulnerabilities, draft a response, communicate internally and externally, and plan for potential product updates and the delivery of changes. A security response team is usually cross functional, for example, including software and hardware development, customer support, product management, and technical publications.

Security threats to embedded systems are on the rise, but awareness of the problem is also increasing. Designing secure embedded systems is a necessity, but it impacts the bottom line due to increased design and development effort. This blog series has hopefully provided you with tangible steps to increase device security while reducing risk and costs of the additional development that may be required. Assigning a high priority to security considerations early in a product’s lifecycle, along with the commitment to support the system throughout its lifecycle, is key to improving security in embedded systems.

 

For additional information from Wind River, visit http://www.facebook.com/WindRiverSystems.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>