Compliance with safety-critical requirements for software has become the foundation upon which compliance with security requirements is based. Development and certification of software for airborne safety-critical applications is typically done following a guidance document called RTCA/DO-178B. Parallels exist between compliance with RTCA/DO-178B and information technology (IT) security requirements defined in ISO 14508.
More commonly known as the Common Criteria, ISO 14508 defines functional and assurance requirements for security in IT products. Compliance with RTCA/DO-178B provides a basis for meeting both medium and high assurance requirements of the Common Criteria. To fully understand the parallels between these two standards, it is useful to explore each standard independently.
The RTCA/DO-178B Guidance Document
RTCA/DO-178B, commonly known as DO-178B, is a process-oriented document used for the development of safety-critical software. It describes a planning process, a development process, a verification process, a configuration management process, a quality assurance process and a certification liaison process.
The objectives of DO-178B are mapped to these processes. The development process uses a set of objectives for requirements, design, and coding and integration. The verification process contains objectives to review requirements, design and code as well as to produce test cases and perform structural coverage analysis. These engineering-related processes are accompanied by specific objectives for configuration management and software quality assurance. The number of these objectives depends on the software’s role in system safety: the higher the level, the more objectives are required.
For example, software that controls an aircraft automatic pilot in landing an airplane has a critical role in the safety of the aircraft, whereas software that controls a passenger entertainment unit has no impact on the aircraft’s safety. Obviously, failure of the software controlling the entertainment system will have only a minor effect on aircraft operation, possibly altering crew workload slightly. In contrast, a software failure of the autopilot could have a catastrophic outcome, potentially leading to the loss of life.
For this reason, DO-178B prescribes five levels of software criticality. Each level relates to the failure condition that could result from a latent software defect. Typically, a system safety assessment is done to determine the required software level in a given application. Level A is defined as the most safety-critical software level and Level E is defined as the least safety-critical software level (Table 1).
Most of the DO-178B process objectives are similar to the objectives found in the Common Criteria.
The Common Criteria
The Common Criteria, ISO 14508, comprise an international standard that defines IT security requirements. This standard draws some of its heritage from the Trusted Computer System Evaluation Criteria, the so-called “Orange Book.” The Common Criteria define two classes of security requirements: functional and assurance. The objectives of these two classes vary depending upon the security classification level.
Security functional requirements include audit, communications, cryptography, data protection, authentication, security management, privacy, protection of TOEs, resource utilization, TOE access and trusted paths.
They focus on what the IT product is supposed to do in order to meet security objectives. This implementation-independent method of identifying security functionality provides a common basis for evaluating the security capabilities of software products, including operating systems. Other federal standards requiring compliance with certain classes of functional requirements, such as cryptography or communications, may come into play.
Security assurance requirements define the following classes of assurance processes for a software product. They include configuration, management, maintenance of assurance, development, life cycle support, tests, delivery & operation, protection profile evaluation, guidance documents, security target evaluation and vulnerability assessment.
These classes of security assurance processes indicate the software development methodology and processes required to ensure an appropriate level of rigor for a product’s security level. It is these classes of processes that have commonality with DO-178B processes. Before examining this commonality, it is useful to discuss other Common Criteria terminology.
The definition of specific security functional and assurance requirements is done through the “Protection Profile” and “Security Target” documents. The Protection Profile is an implementation-independent definition of the security functionality and assurance requirements for a particular category of products. The Security Target is an implementation-specific document for a Target of Evaluation (TOE) that claims support for one or more protection profiles and forms the basis for evaluation of the software on the Security Target.
There are several protection profiles that have currently been defined for embedded operating systems. The four main profiles are the protection profile for single-level operating systems in environments requiring medium robustness; the protection profile for multi-level operating systems in environments requiring medium robustness; the partitioning kernel protection profile; and the separation kernel protection profile.
The evaluation of security software through the Common Criteria standard defines seven evaluation assurance levels (EAL 1-7) that indicate the process rigor associated with the development of an IT product (Table 2).
The level of assurance rigor increases from EAL 1, the lowest, to EAL 7, the highest. Assurance to EAL 7 involves formal verification of the software product using mathematical models and theorem proving.
Finally, the software product developed according to a specific protection profile must be certified to a specific EAL level by a U.S. government-approved Common Criteria Testing Lab (CCTL).
Commonality Between the Common Criteria and RTCA/DO-178B
The Common Criteria view security certification of hardware and software monolithically, whereas DO-178B focuses on software verification independent of hardware platforms. Moreover, compliance with security requirements in the Common Criteria may be vastly different for applications at the same level of security.
This is because security, by its very nature, is closely linked to the design of the product. In contrast, compliance with a specific level of DO-178B is generally the same for all applications regardless of hardware platform, although additional effort is naturally required for larger applications. However, there are common threads between DO-178B objectives and the Common Criteria, to the point where use of DO-178B processes are a natural foundation for compliance with some security assurance requirements (Figure 1).
The common areas are configuration management, quality assurance, development and, to some extent, planning. Areas where additional effort may be required to satisfy DO-178B requirements include delivery and operation, guidance documents and vulnerability assessment. DO-178B does not require a vulnerability assessment, per se, for software. This is usually included in an overall system safety assessment. An updated version of DO-178, DO-178C, will likely require a vulnerability assessment for software.
Since compliance with the Common Criteria security objectives forces a look at both hardware and software, use of DO-178B processes for software can help with meeting the Common Criteria objectives. Augmentation of these software life cycle processes with hardware-specific objectives targeted toward the Common Criteria can help organizations avoid expensive, time-consuming retraining efforts dedicated to the Common Criteria objectives. Conventional wisdom states that compliance with DO-178B, Level A equates roughly to between Common Criteria EAL 4 and 5.
Compliance with higher levels of assurance (EAL 5-7) in the Common Criteria requires specialized resources that are familiar with formal methods of evaluation. Here again, the DO-178B objectives can serve as a foundation for meeting these higher levels of security.
LynuxWorks
San Jose, CA.
(408) 979-3900.
[www.lynuxworks.com].
