Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Creating a secure embedded dev't process

Posted: 12 Jul 2013 ?? ?Print Version ?Bookmark and Share

Keywords:embedded systems? high-assurance web server? HAWS? safety-critical? CPU?

For critical safety- and security-enforcing components, the software development process must meet a much higher level of assurance than is used for general-purpose components. The embedded systems developer unfamiliar with the secure development process should study proven high-assurance development standards that are used to certify critical embedded systems.

Two noteworthy standards are DO-178B Level A (a standard for ensuring the safety of flight-critical systems in commercial aircraft) and ISO/IEC 15408 (Common Criteria) EAL6/7 or equivalent. A high-assurance development process will cover numerous controls, including configuration management, coding standards, testing, formal design, formal proof of critical functionality, and so on.

Let's consider a case in which a rogue programmer has the capability of installing into aircraft engine software a condition such that the engine will shut down at a certain time and date. This software may reside in all the engines for a particular class of aircraft. One aspect of a secure development process is having separate system and software teams developing the redundant aircraft engine control systems. In this way, systemic or rogue errors created by one team are mitigated by the entirely distinct development paths.

Independence of systems, software, and testing teams in accordance with standards also contributes to this secure development process.

Change management
An extremely important aspect of maintaining secure software over the long term is to utilise an effective change management regimen.

A software project may be robust and reliable at the time of its first release, only to endure change rot over ensuing years as new features, not part of the original design, are hacked in, causing the code to become difficult to understand, maintain, and test. Time-to-market demands exacerbate the problem, influencing developers to make hasty changes to the detriment of reliability.

Peer reviews
A critical aspect of effective change management is the use of peer code reviews. A common peer code review sequence consists of the code author developing a presentation describing the code change followed by a face-to-face meeting with one or more developers and development managers involved in the project.

The developer presents the software design in question, and the others try to poke holes in the code. These meetings can be extremely painful and time consuming. Audience members sometimes feel compelled to nitpick every line of code to demonstrate their prowess.

Tip: Use asynchronous code reviews with e-mail correspondence or carefully controlled live meetings.

Recording the reviewer's identification in the configuration management system also provides an electronic paper trail for security certification auditors. Another advantage of partitioning is the ability to minimise process requirements across the system. In any large software project, there is a continuum of criticality among the various pieces of code.

By way of example, let's consider an excimer laser system used in semiconductor manufacturing. The laser itself is controlled by a highly critical, real-time software application. If this application faults, the laser in turn may fail, destroying the semiconductor.

In addition, the system contains a communications application that uses CORBA over TCP/IP to receive commands and to send diagnostic data over a network. If the communications application fails, then the system may become unavailable or diagnostic data may be lost, but there is no possibility for the laser to malfunction.

If both applications were built into a single, monolithic system in which all code executes in the same memory space, then the entire software content must be developed at the highest levels of quality and reliability. If the applications are partitioned, however, the non-critical communications application development can be subjected to a lower level of rigor, saving time to market and development cost.

Obviously, we do not advocate a free-for-all on components that are not considered critical; management should use judgement regarding which controls to apply to various software teams. When the process controls in non-critical applications are reduced, time to market for the overall system can be improved without jeopardizing reliability where it counts.

Tip: Apply a level of process rigor, including code reviews and other controls, that is commensurate with the criticality level of the component.

Security-oriented peer review
Most peer reviews are spent looking for coding bugs, design flaws, and violations of coding standards. While these activities contribute to more reliable and hence secure software, most embedded software organisations do not perform reviews based specifically on security analysis. When a developer presents a new design or piece of software, the reviewers should consider security-relevant characteristics. For example:

Least privilege: Can the software be refactored such that the least critical components are provided the least amount of privilege in terms of access to resources? Reducing privilege of a component decreases its attack surface and reduces its assurance requirements, improving efficiency in development and certification (if applicable).

1???2???3?Next Page?Last Page

Article Comments - Creating a secure embedded dev't pro...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top