Cyber security robustness of an embedded computing system with trusted computing measures built-in
By Richard Jaenicke
and Steve Edwards
Systems designers who are considering creating a trusted computing platform able to host cross-domains solutions (CDS) and other multi-level security (MLS) applications have some decisions to make about software and hardware concerns. First, the designer needs to understand the levels of security functionality and assurance that a robust trusted-computing solution needs.
The international standard for security evaluation of an information technology (IT) product or technology is the Common Criteria for Information Technology Security Evaluation (ISO/IEC 15408) -- simply referred to as the Common Criteria (CC).
The Common Criteria provides common requirements for computer security and for assurance measures applied to those IT products during a security evaluation. Evaluations can be done to different levels of depth and rigor, called Evaluation Assurance Levels (EAL). Each EAL defines security-assurance requirements: EAL 1 is the least rigorous and EAL 7 is the most rigorous (Figure 1).
Figure 1: Range of evaluation assurance levels
By definition, an EAL addresses only assurance requirements and not functional requirements of a security solution. This can lead to applying rigorous evaluation methods to very lax security functionality. The Common Criteria explicitly acknowledges this up front:
“The CC is intentionally flexible, enabling a range of evaluation methods for a range of security in IT products. Therefore users of the standard are cautioned to exercise care that this flexibility is not misused. For example, using the CC in conjunction with unsuitable evaluation methods, irrelevant security properties, or inappropriate IT products, may result in meaningless evaluation results.”
Protection profiles
The Common Criteria does not define packages for cyber security functional requirements corresponding to the EALs. Nevertheless, groupings of security functional requirements and security assurance requirements can be defined in a protection profile (PP).
It is only when a high EAL pairs with a demanding protection profile that the highest security is achieved. The best way to ensure a meaningful evaluation is to use a government-defined protection profile directly applicable to that type of product, also known as a Target of Evaluation (TOE). Having security functional requirements defined to meet the security objectives is critical in providing a robust security solution.
In the U.S., the National Information Assurance Partnership (NIAP) defines protection profiles and manages the Common Criteria Evaluation and Validation Scheme (CCEVS) validation body. When the evaluation is at EAL 5 or higher, the U.S. National Security Agency (NSA) participates in the evaluation.
Those protection profiles can specify a security robustness level based on the target of evaluation’s ability to protect itself, its data, and its resources. Robustness levels are characterized as basic, medium, or high. The level of robustness required for a target of evaluation is characterized as a function of the value of the data that it protects and the threats identified for the environment in which it is deployed.
Security robustness levels
Basic robustness environments are defined as those that encounter threats introduced by inadvertent errors or casually mischievous users. In general, best commercial practice is sufficient to protect information in a basic robustness environment.
Medium robustness environments are sufficient where the motivation of an attacker has at least a moderate level of resources or expertise. In general, medium robustness is appropriate for an assumed non-hostile and well-managed user community requiring protection against threats of inadvertent or casual attempts to breach the system security.
A high robustness target of evaluation is required for environments where sophisticated threats and high-value resources both are present, resulting in a high likelihood of an attempted security compromise. High robustness requires EAL 6 or higher and is appropriate for protecting systems from extremely sophisticated and well-funded threats, such as attacks from nation-states and national laboratories.
Related: Trusted computing: an overview
Medium and high robustness environments generally require that certain hardware components of a product be evaluated as part of a target of evaluation. This provides confidence that the product is less likely to be compromised and that the security policy is always invoked.
Example high robustness solution
In 2007, the NSA Information Assurance Directorate issued the only government-defined operating system protection profile ever designed for high robustness or EAL 6 and above, namely the “U.S. Government protection profile for Separation Kernels in Environments Requiring High Robustness” (SKPP).
A separation kernel is the minimum operating system functionality necessary to enforce four foundational security policies: data isolation, control of information flow, resource sanitization, and fault isolation.
As part of meeting those security policies, a separation kernel divides memory into partitions using a hardware-based memory management unit (MMU) and allows only carefully controlled communications among non-kernel partitions.
Other OS services, such as networking stacks, file systems, and most device drivers, execute in a user-mode partition instead of in the kernel in privileged mode to keep the kernel as small and secure as possible (Figure 2). Processing network data, for example, in least-privileged user mode eliminates a vulnerability that is a common avenue of attack, such as the URGENT/11 zero-day vulnerabilities.
Figure 2: With the INTEGRITY-178 tuMP, the file system, network stack, and virtualization layer run in user space, leaving only the base security functionality in kernel space.
In 2008, NIAP certified the INTEGRITY-178 RTOS from Green Hills Software against the SKPP to high robustness and EAL 6+, and an updated version of INTEGRITY-178 with additional features was certified against the SKPP in 2011.
No other operating system achieved SKPP certification. As part of certification to the SKPP, INTEGRITY-178 underwent independent vulnerability analysis and penetration testing by NSA to demonstrate that it resists attackers with high attack potential and that it does not allow attackers with high attack potential to violate security policies. Extending that security design to multicore processors, INTEGRITY-178 tuMP continues to meet the SKPP’s rigorous set of functional and assurance requirements.
In 2011, NSA ceased authoring protection profiles and ceased certifying products. Instead, NSA left NIAP to author protection profiles of basic robustness at EAL 1 or 2. For higher level robustness, the NSA would help programs select security requirements to meet specific program needs, and it would certify products only as part of a solution for the program. In essence, this is similar to airborne safety, where the FAA does not certify COTS products like operating systems but instead certifies higher-level systems that use operating systems.
Currently the only active U.S. government-defined protection profile for operating systems is the general-purpose OS protection profile at basic robustness. As a result, programs of record that require high robustness continue to specify security requirements based on the SKPP, and Green Hills continues to meet those requirements for INTEGRITY-178 single-core and INTEGRITY-178 tuMP multicore solutions.
Richard Jaenicke is director of marketing for Green Hills Software in Santa Barbara, Calif. His email address is [email protected]. Steve Edwards, director of secure embedded solutions at the Curtiss-Wright Corp. Defense Solutions division in Ashburn, Va. His email address is [email protected].
