Security Considerations for Embedded Operating SystemsSecurity requirements, traditionally relegated to military aircraft and weapons, are now being promulgated into everyday embedded systems such as automobiles, medical systems, radios, and household appliances. The embedded operating system must satisfy specific assurance and functionality requirements in order to help achieve the highest levels of security.
The increasing complexity of software controlling these systems, use of the internet, and risk of cyberterrorism are forcing embedded systems designers to rethink their software acquisition strategies to cope with this security challenge. The embedded operating system, because it controls the critical resources of the embedded computer, must satisfy specific assurance and functionality requirements in order to help achieve the highest levels of security.
Common Criteria is an internationally conceived and accepted standard for performing security evaluations. Sponsoring nations include Canada, France, Germany, Netherlands, United Kingdom, and United States. Prior to Common Criteria, nations had independent, disparate methodologies for security evaluation; the U.S. DOD utilized the Trusted Computer System Evaluation Criteria, known informally as the Orange Book.
The Orange Book calls out levels of increasing assurance and protection via classes D through A, with subclass A1 being the most stringent. A major drawback of Orange Book was its lack of generality; Orange Book's focus on sensitivity labels, access controls, and authentication made it applicable only to some classes of secure operating systems.
On the other hand, typical "security kernels" would contain more security features than may be needed by any particular system; such systems would nevertheless be forced to accept the associated large footprint and assurance burden. The functional requirements were too extensive to make it practical for a variety of commercial products to achieve the high assurance designated in the A1 subclass. Evaluation criteria used in other nations suffered from similar problems.
Common Criteria uses a more flexible approach. Common Criteria provides a pool of security functional and assurance requirements from which a specific profile, suitable for a specific type of product (such as a real-time kernel, firewall, or file system) can be selected. The functional requirements specify what security features the product must have.
For example, a traffic-filter firewall profile may include the requirement that all attempts to change the security policies (e.g. the traffic filtering rules) be recorded in an audit log for examination by security personnel. The assurance requirements provide evaluators with the confidence that the product satisfies the claimed functional requirements. These items may include high level and low level design documents, configuration management plans, covert channel analyses, testing plans and results, and proof of secure delivery to end users.
Common Criteria Evaluated Assurance
In addition to the assurance artifacts, Common Criteria specifies levels of assurance and applies these levels to each assurance component. The increasing levels of assurance range from EAL1 to EAL7. The general meanings of the levels are shown in the following Table 1 below:
To understand how the assurance levels apply to the assurance requirements families and components, let's look at an example component: ADV_HLD, "High-level Design". According to Common Criteria, "The high-level design requirements are intended to provide assurance that the TOE [target of evaluation] provides an architecture appropriate to implement the TOE security functional requirements." If a Protection Profile includes this assurance requirement (most do), then the rigor of the requirement increases with assurance level, as shown in the Table 2 below:
The ADV_HLD component is further divided into elements which are the individual descriptive requirements. With each increasing level, elements are added to the requirements inherited from the preceding level. For example, an EAL5 Protection Profile will include the element ADV_HLD.3.9C:
"The high-level design shall describe the separation of the TOE into TSP [TOE Security Policy]-enforcing and other subsystems."
Using our firewall example, this means that the high-level design must point out the subsystems which enforce the traffic filtering rules. For an EAL6 Protection Profile, this requirement is augmented to ADV_HLD.4.10C:
"The high-level design shall justify that the identified means of achieving separation, including any protection mechanisms, are sufficient to ensure a clear and effective separation of TSP-enforcing from non-TSP-enforcing functions."
In other words, evaluators will expect the vendor to provide high-level design evidence that demonstrates that the traffic filtering subsystems are protected from corruption, subversion, etc. by other subsystems.
For an EAL7 Protection Profile, this requirement is further augmented to ADV_HLD.5.10C which is the same as ADV_HLD.4.10C, except that the presentation, or justification, must be formal: "A formal specification is written in a notation based upon well-established mathematical concepts."
These mathematical concepts are used to define the syntax and semantics of the notation and the proof rules that support logical reasoning. The syntactic and semantic rules supporting a formal notation should define how to recognize constructs unambiguously and determine their meaning. There needs to be evidence that it is impossible to derive contradictions, and all rules supporting the notation need to be defined or referenced."
Why High Assurance?
Government security organizations, such as the U.S. National Security Agency, are of the opinion that high assurance is required to protect and control sensitive information and critical infrastructure. In December, 2003, the NSA published a letter concerning U.S. DOD information technology certification and accreditation processes, stating:
"For systems that must maintain separation of information at different levels of classification, high assurance security design (specified by NSA or the International Common Criteria at a minimum Evaluated Assurance Level greater than 4)" is required.
According to Common Criteria (v2.1 Part 3: Security Assurance Requirements, section 6.2.4): "EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line." Windows XP has been evaluated at EAL4. At a recent technology conference, an NSA speaker was asked what level of assurance consumers should expect from this. The speaker responded, with a smile, that "the operating system is secure as long as nothing is connected to it."
As of this writing, there are no operating systems evaluated at higher than EAL5, although operating systems vendors are actively pursuing this. For example, Green Hills Software is under contract to obtain an EAL6+ (EAL6 augmented and extended with additional requirements) evaluation for its INTEGRITY real-time operating system that is used in high reliability applications including avionics, industrial control, medical systems, automotive telematics, and consumer electronics (see http://niap.nist.gov/cc-scheme/in_evaluation#i). Other operating system vendors have voiced their intent to pursue the same evaluation.
Security organizations are intent on levying high assurance requirements (e.g. EAL6 or EAL7) in the civil sector whenever appropriate. An example would be SCADA systems computer systems used to monitor and control a plant or equipment in industries such as water and waste control, energy, and oil refining. Many of these systems are running Microsoft Windows.
In 2000, a disgruntled ex-employee broke into a SCADA system and caused millions of gallons of untreated sewage to be released. We can easily imagine other possible results if the perpetrator had been a determined terrorist.
According to the Federal Technical Support Working Group (see http://www.tswg.gov/tswg/ip/SustainableSecurity.pdf), "The present state of security for SCADA is not commensurate with the threat or potential consequences. The industry has generated a large base of relatively insecure systems, with chronic and pervasive vulnerabilities that have been observed during security assessments. Arbitrary applications of technology, informal security, and the fluid vulnerability environment lead to unacceptable risk."
Clearly, better security is needed across a wide range of industries and types of embedded systems. The separation kernel is the foundation of a new methodology intended to achieve this goal.
The Separation Kernel
The aforementioned EAL6+ evaluation efforts being pursued by operating system vendors are targeting a Protection Profile known in the industry as the "Separation Kernel Protection Profile". The separation kernel forms the foundation of a secure system by providing a fundamental security feature: separation (also known as partitioning).
A partition typically corresponds to a single user application (although it could correspond to more than one). The separation kernel enforces information flow policies between partitions and ensures that two independent (non-communicating) partitions running on the same computer cannot affect each other in any way. The information and flow and separation policies are enforced via the following mechanisms: Memory Protection, Memory Partitioning, Periods Processing, Mandatory Access Control, and Time Partitioning
Memory Protection. The computer's memory protection hardware is configured by the separation kernel to prevent any read or write access between partitions. The kernel runs in its own partition and is also protected from any other user application. Not only does this mean that a rogue application cannot corrupt another application by writing into its address space, but it also means that a rogue application cannot read sensitive information from the kernel or another application.
|Figure 1 " central memory store is a security risk|
Memory Partitioning. Another way a rogue application can affect another application is by gobbling up all of the memory in the system, causing other applications to fail (see Figure 1 above ). Most operating systems employ a central store for memory that is doled out to applications as they request new threads, dynamic memory allocations, or other resources. The separation kernel must thwart this denial of service attack. One method is to allocate a fixed quota of physical memory to each application. If an application exhausts its quota, it can fail, but it cannot possibly affect the memory usage of other applications (see Figure 2 below).
|Figure 2 " separation kernel uses quotas to guarantee memory availability|
When switching from execution of one partitioned application to another, no latent information (such as data on the stack or in registers) from the old partition is permitted to be read by the new partition; in other words, the kernel must scrub any resources of information before they can be reused. This requirement is aimed at computer systems that manipulate data at multiple security levels (e.g. top secret and unclassified).
If the separation does not implement periods processing, then an insecure, subverted partition (e.g. with internet access) may be able to gain access to classified information left over from a top secret partition's earlier execution. This information could then be sent over the internet for collection and use by hostile entities.
Mandatory Access Control. A secure operating system must control access to critical system resources, such as files and I/O devices, in order to prevent compromise of those resources by rogue applications.
Mandatory access control (MAC) policies are enforced by the operating system and cannot be modified by user applications. The separation kernel should provide mandatory access control over kernel objects such as I/O devices, semaphores, and threads.
Similarly, inter-partition communication policies are implemented and enforced by capabilities to communication objects. Ideally, the system designer should be able to specify object ownership at build time using a configuration file that is then input into the build process where it is incorporated into the separation kernel.
At boot time, the separation kernel reads the configuration data and implements the access control policy. A more dynamic access control mechanism can be built on top of the separation kernel's static policy quite easily (more on building higher-level security policies later).
Figure 3, below shows an example configuration depicted graphically. In this example, the system consists of three partitions. The top_secret partition has been provided access to the ClassifiedNetworkDevice; neither the secret nor unclassified partitions have access to this device, and there is no way they can obtain access during run-time.
|Figure 3 " mandatory access control by partition|
Time Partitioning. Another important feature of the separation kernel is to guarantee CPU execution time to partitions. A simple denial of service attack to which insecure operating systems are vulnerable entails a rogue application spawning multiple copies of itself or another application, with each "confederate" process soaking up an increasing share of the system CPU time.
Critical applications are unable to execute, causing system-level failures. Most operating system schedulers have no provision for guaranteeing execution time at the partition level. Many real-time operating systems schedule threads by priority, without regard to the applications in which the threads reside.
Therefore, bugs or design errors can cause threads running in a critical partition to be starved of execution time by threads running in unrelated, non-critical partitions. Desktop operating systems often use fairness-based heuristic scheduling algorithms that also fail to provide any execution time guarantees.
The separation kernel can provide guaranteed execution time to partitions by scheduling at the partition level. One such algorithm is defined by ARINC-653, a standard for operating system execution widely adopted in the avionics industry. The ARINC-653 partition scheduler schedules partitions in a repeating timeline (see Figure 4, below).
Partitions are allocated slots within the timeline; when a partition's slot is running, only threads within that partition can run. There is nothing any other partition can do to steal CPU cycles away from the active partition.
|Figure 4 " partition scheduling|
The separation kernel does not address network security. Ideally, a high assurance network servicing infrastructure is used on top of the separation kernel. However, even if there are flaws in higher-level security policies, the partitioning capabilities of the separation kernel can limit damage from security infiltrations and effectively thwart hackers.
Consider a SCADA system that has a networked administrator interface and safety critical applications such as a health monitor. Authorized technicians use a PDA to wirelessly connect to the system to control its operation and configuration. The SCADA system has low assurance network security but a high assurance separation kernel controlling the SCADA computer.
Due to a flaw in the computer's low assurance web server, a cyberterrorist is able to use the network interface to load a virus onto the computer. The virus duplicates itself, but eventually it will exhaust its memory quota and further duplication efforts will fail. Memory use within the critical applications is unaffected.
Suppose the duplicated virus processes attempt to raise their priorities and spin, soaking up as much execution time as they can. Once again, the time partitioning enforced by the separation kernel ensures that the virus cannot steal CPU cycles from the preloaded critical applications.
Finally, because of memory protection enforced by the separation kernel, the virus is unable to access beyond the loading partition to read from or write to the kernel or critical applications.
Multiple Independent Levels of Security and Safety (MILS) is a joint research effort between academia, industry, and government to develop and implement a high assurance, real-time architecture for embedded systems. The goal of the MILS architecture is to ensure that all system security policies are non-bypassable, evaluatable, always-invoked, and tamper-proof.
The aforementioned separation policies, and the formal assurance of these policies, makes the separation kernel a perfect fit to provide the foundation of the MILS system. In fact, the term "MILS Separation Kernel" is often used. Another key aspect of the MILS vision is to enable security policies to be enforced at hierarchical levels, depending on the requirements of the overall system. For example, instead of incorporating an MLS (Multi-level Security) control flow policy into the separation kernel, MILS promotes the concept of building an MLS policy at the application level by utilizing the underlying separation policies of the kernel.
Because high assurance components are built as application programs running on top of the separation kernel, they are, by definition, optional. If a system requires a single shared network connection for multiple levels of data, then the PCSExpress component can be added. If each level of data has a private network connection, then PCSexpress can be omitted. This maximizes flexibility and performance while reducing cost on many fronts.
In order to elucidate how domain-specific security policies can be efficiently built on top of separation policies, consider how the MLS window manager works. Each window running at a different security level is provided a virtual frame buffer. The separation kernel's access control policies prevent any of the windows from gaining direct access to the graphics card's physical frame buffer.
Only the high assurance window manager has direct access to the hardware. Applications write to their virtual screens whenever they are scheduled, according to the separation kernel-enforced time partitioning policy. Independently, the high assurance window manager periodically (again, according to the scheduling policy) takes data from the virtual screen buffers and splashes them on the physical device.
None of the applications can directly read into screen real-estate of other applications running at different security levels (this is enforced via the mandatory access controls/capabilities). And the applications are unable to detect when other levels are writing to the screen, thereby preventing a covert (yet obvious) timing channel.
It is because of its partitioning features and its lean, evaluatable design, that the separation kernel is the foundation of a secure system. High assurance is required for the embedded operating systems that control today's, and tomorrow's, safety and security critical systems. The security policies of operating system components must not fail; high assurance is the only path to this goal.
Using the MILS architecture, we can create hierarchical building blocks of secure components, each of which is independently evaluatable, to compose even the most complex security systems (such as secure workstations and servers), and do it in a manner that is cost-effective relative to legacy security kernel architectures. The "cookbook" approach of Common Criteria, which enables evaluations to be performed on arbitrary classes of components, makes it an ideal fit for the MILS architecture.
David N. Kleidermacher is Vice President of Engineering at Green Hills Software, Inc.
This article is excerpted from a
paper of the same name presented at the Embedded Systems Conference
Silicon Valley 2006. Used with permission of the Embedded Systems
Conference. For more information, please visit www.embedded.com/esc/sv.