Over the past five years market forces have coalesced to support a dramatically simpler foundational architecture, called “MILS,” for building high-assurance systems that must survive high-threat environments. Multiple Independent Levels of Security (MILS) is a departure from operating system architectures that were designed prior to the Internet, when there was little threat of network attacks. As a result, these early systems did not incorporate security as a design requirement. In response to inevitable failures and intrusions, patches were developed over time to plug specific security holes. This “fail first, patch later” approach is unacceptable for any mission-critical system.

The central idea behind MILS is to partition a system in such a way that: 1) the failure or corruption of any single partition cannot affect any other part of the system or network, or, 2) each partition can be security-evaluated and certified separately, so no partition requires evaluation at a higher level than necessary for that function. For the first time, developers can base their applications on secure, high-assurance foundations.

Multiple Levels of Security for Multifunctional Systems

In the early 1980s, the DoD issued the “Orange Book,” a set of criteria used for evaluating the security features of computer systems. It became widely used in the IT industry as a benchmark for security standards. However, Orange Book security fell short in two areas. First, higher assurance levels required both mathematical verification of trusted system components, as well as significant security functionality in those trusted system components. The code size made mathematical verification almost impossible. Secondly, intersystem communication was not addressed by the Orange Book. Trusted components and device drivers ran in privileged mode for performance reasons. Security-critical application code also ran in privileged mode. This was a nightmare to evaluate, and typical evaluations cost on the order of $100 million.

As a result, implementing Orange Book standards became expensive and problematic, mainly because of the limitations of microprocessors in the 1980s. The tremendous increase in microprocessor performance has enabled new paradigms of security. Often, one system has the job of performing several different functions, especially as processors increase in performance. If such a multifunctional system must meet different levels of safety or security criteria for each of its functions, there must be some guarantee that lower-security functions cannot interfere with higher-level functions—under any circumstances.

Such systems require Multiple Independent Levels of Security, or MILS, as the NSA designates them. MILS system designers must guarantee that unintended interactions are not possible. Otherwise, systems integrators would have to integrate each function individually on a separate processor, which would increase costs and system complexity. In some applications, such as fighter aircraft, separate processors would also add weight, take up space, and consume power—a serious design drawback. MILS implementation on a single processor is both cost-effective and possible with today’s technology. MILS is not a revolution of new ideas over old, but old ideas coming of age—now that technology has caught up.

One Size Does Not Fit All

MILS combines the best of the safety and security worlds to create a better solution than either could have devised alone. It draws upon FAA DO-178B Level A Safety technology and Common Criteria EAL7 Security technology to enable MILS Web and network services for mission-critical embedded and real-time systems, including high-assurance weapons, training and communications systems and C4I platforms.

MILS is founded on the understanding that security is not a one-size-fits-all proposition, and that the security level should be appropriate to the application. The Common Criteria’s Evaluation Assurance Levels range from EAL1, the very basic level, to EAL7, the highest level of assurance. Various military systems require EAL assurance levels according to the value of their data and the threat that they encounter. A set of assurance requirements between EAL6 and EAL7, called “High Robustness,” is required when top secret, secret, confidential and unclassified data reside on the same node.

Military command centers derive information from a variety of sources, from weather forecasting systems to fighter jets to commanders and allied forces in the field. Users within intelligence agencies and the DoD wrestle with information on multiple computers handling information at varying security levels.

An operating system that can simultaneously support ubiquitous commercial applications running on Windows or Linux, along with a variety of mission-critical or high-assurance applications, is the holy grail of computing. Without such a capability, system designers need to use multiple hardware devices to meet varying security requirements. This type of hardware separation is costly and awkward. An architecture that can support secure partitioning, commercial or legacy applications, multilevel communication, secure user authentication and trusted path, and secure cross-domain information transfer—in a single processor—is the promise of MILS.

Minimum Code Equals Affordable Cost

MILS architecture separates security mechanisms into manageable components. Processes are isolated into partitions that comprise a collection of data objects, code and system resources. These individual partitions can be evaluated separately. This approach substantially reduces the proof effort for secure systems.

To support these partitions, the MILS architecture is divided into three layers: separation kernel; middleware, including the Partitioning Communications System (PCS); and applications. Figure 1 is a basic architecture diagram of MILS. While those terms have been used since the days of the PDP-11, what is different is the assignment of functions to these layers.

Separation Kernel. The MILS separation kernel divides the computer into separate address spaces and scheduling intervals, guarantees isolation of the partitions and supports carefully controlled communications among them. Because the separation kernel performs these functions and only these functions, the source code can be small—roughly 4,000 lines of C language code. This makes it fast and practical to verify using formal analysis methods (mathematical verification) and to do the exhaustive testing and comprehensive documentation required for the highest-level certifications. The separation kernel requires the highest level of authentication, and is the only piece of software that runs in privileged mode. Therefore, no other code, not even device drivers, has the ability to affect the processor’s protection mechanisms. Everything else, including all middleware, runs in user mode. The small size of the separation kernel is a manifestation of the most important MILS design objective. It is because of this rigorous inspection and evaluation that the MILS separation kernel can be trusted.

Middleware. In the MILS architecture, middleware has a broader meaning that just traditional middleware. Most of the traditional operating system functions have been moved from the operating system to “middleware services,” e.g., file systems, device drivers, trusted path, etc. Middleware services include a Partitioning Communications System (PCS) to extend the scope of the separation kernel to intersystem communication. It also includes traditional middleware like CORBA (Common Object Request Broker Architecture), DDS (Data Distribution Service) and Web services. Middleware resides in the same kind of partition as the application that it supports, either co-resident with the application or in a partition by itself. Middleware runs in unprivileged (user) mode, making these services subject to separation kernel policy enforcement. The services that previously ran in privileged mode as part of the operating system, such as memory allocation, device drivers, I/O primitives, file systems and network stacks, now run in user mode in the MILS middleware layer. Some middleware components don’t need to be certified at the highest level, and because they can be confined to one partition, they can be evaluated and certified at the appropriate level at much less cost. For example, if a component such as real-time CORBA is running in a classified partition and another instance of it is running in an unclassified partition, only the classified instance of CORBA needs to be certified.

Applications. The application level entities manage, control and enforce their own application-level security policies, such as firewalls, crypto services and guards. Instead of the “fail first, patch later” approach, trusted components are mathematically verified so that they are: Nonbypassable, Evaluatable, Always invoked and Tamperproof. Taken together, these form the acronym NEAT. In order to be effective, all system protection must be NEAT.

To satisfy the High Robustness requirements of EAL6/7, engineers must design the system with security in mind from the start and must make it possible to decompose every system function into successively smaller subsets, down to a simple, provable module, each step demonstrating that mechanisms are “NEAT.” This formal proof requires extensive analysis, documentation and review. It is economically infeasible to achieve High Robustness unless the system is designed from the inception to be “provable.” This cannot be added on after the fact.

When a distributed system configuration is created, we would like it to be as safe or secure as if it were just a single processor. That’s accomplished by implementing end-to-end enforcement of the basic MILS separation kernel policies. The Partitioning Communications System (PCS) is the enforcement mechanism. The collection of MILS nodes in a distributed system is called an enclave, and the PCS is present in each node in the enclave. The PCS (Figure 2) fits between the applications and the partitions implementing network protocols.

The secure separation kernels developed by companies such as Green Hills, Wind River and LynuxWorks provides the ability to separate multiple address spaces. In one millisecond, the system may perform a safety-critical task, the next millisecond, not; the non-safety-critical and safety-critical won’t interfere with each other.

The separation kernel is microprocessor-centric. On this microprocessor, one can build a firewall that separates applications—top-secret from not, safety-critical from not—and guarantee that those applications won’t talk to each other without an application-centric firewall. The separation kernel makes decisions about what goes on at the microprocessor level, but it knows nothing of the network. It just secures this one node.

The PCS takes this secure environment in the separation kernel and extends it to an enclave of computers—2, 100 or 10,000 computers. There will still be an application-centric firewall that separates applications, but it must be NEAT. Partitions are no longer restricted to being on the same processor. There could be hundreds of microprocessors, but one can still guarantee the firewall is tamperproof and nonbypassable. The MILS architecture makes it possible to secure tens of thousands of computers in a global information grid—on fighter aircraft, tanks, aircraft carriers and destroyers.

MILS enables protection against malicious software, internal mistakes and failure. Malicious software can successfully attack the system’s hardware or software foundations and render any form of security useless. Security “patches” that do not address security at the foundation level are vulnerable to a variety of forms of attack, as shown in Table 1.

Simple Means Secure

Past efforts at making software truly secure usually added complexity and high cost. Layers of protection were added on top of the operating systems, middleware and applications. Sometimes these layers interfered with each other, had unintended side affects or were not completely consistent with each other, giving both bugs and attackers the initial crack in the wall they needed to inflict damage.

The MILS approach is precisely the opposite. Systems are made more secure by making the protection simpler. Because it is simpler, it can be trusted to work under all conditions. The processor, via the MILS separation kernel, is tightly controlled. All protections built into the system will be composable—that is, the components will work the way they were designed to work and information will flow between them only the way that it should. The PCS provides the same assurances for distributed systems.

In collaboration with its partners, including the U.S. National Security Agency, U.S. Air Force Research Laboratory, the University of Idaho, Lockheed Martin, Raytheon, Boeing and Rockwell Collins, Objective Interface is working to integrate several MILS security separation kernels with Objective Interface’s high-performance implementation of the PCS architecture, PCSexpress. Objective Interface is developing PCSexpress as well as real-time MILS versions of its signature products, ORBexpress and DDSexpress.

The MILS Separation Kernel Protection Profile (SKPP) is under final review by members of The Open Group. Once evaluated and endorsed by The Open Group, the SKPP will be officially evaluated and endorsed by the National Information Assurance Partnership (NIAP) as a validated protection profile, probably during the end of 2005. Developers can use the draft SKPP to plan MILS-based systems. The draft is available for download from www.niap.nist.gov/pp/draft_pps.

The MILS architecture is being applied today and will continue to be important in the most demanding applications where failure is unthinkable: airborne software and national security systems. Because it is both secure and affordable, it will be practical to use this architecture in commercial applications and anywhere system failure or unauthorized access will have significant or even life-threatening consequences. For more information about MILS and current news of MILS developments, visit http://mils.ois.com.

Objective Interface Systems
Herndon, VA.
(703) 295-6500.
[www.ois.com].