MILS - Multiple Independent Levels of Security

Software Architecture that Can Assure Security at Provable Levels of Assurance and Allow for Different Levels of Access


Standard commercial operating systems were not built for security. Most commercial computer security architectures are a reactive result of problems that have resulted from insecure operating system and communications architectures. This fail-first, patch-later approach is inappropriate for the communications infrastructure supporting mission-critical aerospace, defense, data communications, telecommunications, utilities, transportation, financial, and similar mission-critical systems.

Systems and application software is only as good as the foundation it is built upon. A Multiple Independent Levels of Security/Safety (MILS) architecture enables protection against malicious software, internal mistakes and failure. If malicious software can successfully attack the system's foundation, it can render almost any form of system or application security useless.

Foundational threats include:

  • Bypass—Malicious software circumvents the system‘s protection. If critical security software can be bypassed there is no assurance that application programs using security services are safe.
  • Compromise—Malicious software can read private data of other programs. If invasive software, like the spyware so common in today's Internet environment, can monitor the data of other programs then entire system security is suspect.
  • Tamper—Malicious software modifies the sensitive data of other programs. If tamper is possible then no application is safe from viruses, worms, etc.
  • Cascade—Malicious software causes failures to cascade from one system component to another. If a failure of one application can cause failure of another application it may be possible for much greater system failure. A notable example of unintentional failure cascade is a Navy cook who entered zero into a window that asked for a number one to ten. The application divided by zero. This caused other applications to fail. Eventually the O/S failed. The hard drive got screwed up. The system would not reboot. The ship was towed to shore.
  • Covert Channel—Malicious software that can leak information through a communication channel that is a side effect of the primary communication intent. For example, by detecting the presence or absence of a message an observer can derive information as to the activity of the communicating parties. If there are covert channels available a malicious communicating party can leak any information to the observing party by creating intentional timing messages in an arranged pattern.
  • Virus—Malicious software that runs at privileged levels so that it can infect all parts of the system and other systems. What is necessary is an architecture that enforces and manages the concept of least privilege. Then when a compromise occurs it damage is local, its damage can be detected, and recovered from. A big part of countering the computer virus problem is kicking device drivers and applications out of privilege mode.
  • Subversion—Malicious software is loaded by a user who thinks the software is legitimate. All code needs to be signed or it does not even load. The source of all software must be traceable to the original author. Software authors should follow good software engineering practices. Preventing subversion is everyone's responsibility.

What is MILS?

MILS (Multiple Independent Levels of Security/Safety) represents a relatively new (10 years) approach to building secure systems in contrast to the older Bell and LaPadula theories on secure systems that represent the foundational theories of the DoD Orange Book.

MILS makes mathematical verification possible for the core systems software by reducing the security functionality to four key security policies:

  1. Information Flow: Between partitions both internally toa RTOS and end-to-end between partitions in different computing platforms, this requires authentication and integrity for end-to-end protection.
  2. Data Isolation: Private data remains private, this may require encryption for end-to-end protection.
  3. Periods Processing: The microprocessor itself will not be a covert channel to leak classified data to unclassified processes as the processor move from partition to partition within a partitioning RTOS, to close covert channels on a communication link may require full period encryption, dummy traffic generators, etc.
  4. Damage Limitation: A failure in one partition will not cascade to another partition, failures will be detected, contained, and recovered from locally.

The MILS architecture was developed to resolve the difficulty of certification of high assurance systems, by separating out the security mechanisms and concerns into manageable components. A MILS system isolates processes into partitions, which define a collection of data objects, code and system resources. These individual partitions can be evaluated separately, if the MILS architecture is implemented correctly. This divide and conquer approach exponentially reduces the proof effort for secure systems. To support these partitions the MILS architecture is divided into three layers:


  • Separation Kernel —A very small (5,000 lines of code or less) mathematically verified piece of software trusted to guarantee separation of time and space partitioning.
  • Middleware Services —Most of the traditional operating system functionality including device drivers and a Partitioning Communications System to extend the scope of the separation provided by the Separation Kernel to inter-system communication, and
  • Applications —Responsible for enforcing application layer security policies.

With most operating systems it is very difficult to prove that these requirements are being met. Recently, however, the MILS architecture has emerged in which a micro kernel is responsible for partitioning the computer into separate address spaces and scheduling intervals, guaranteeing isolation of the partitions, and supporting carefully controlled communications among them.

MILS requires that the Separation Kernel and the trusted components of Middleware Services are implemented so that the security capabilities have the following characteristics:

  • Non-bypassable (the security functions cannot be circumvented).
  • Evaluatable (the security functions small enough and simple enough to be mathematically verified and evaluated).
  • Always invoked (the security functions are invoked each and every time).
  • Tamperproof (subversive code cannot alter the function of the security functions by exhausting resources, overrunning buffers, or other forms of making the security software fail).

    A convenient acronym for these characteristics is NEAT.

Separation Kernel

If we want to run a security function on the same computer as our application programs, where should it reside? In order to be tamper-proof, it must be in a separate address space from any un-trusted application code. And in order to be non-bypassable, it must be part of every input or output service request issued by an application. The natural solution, then, seems to be to put it in the operating system.

But mixing security functions and other code in the operating system's privileged kernel address space is less than optimal for two reasons: the security functions are often application-specific. And while many RTOSs are designed to allow some user customization, it would really be better not to have to make changes in the most sensitive part of the system.

Since any code in the same address space as a security function could potentially interfere with the kernel's enforcement of security, the entire kernel must be analyzed for weaknesses and malicious code.

Enter the Separation Kernel. This is actually not new technology. John Rushby was describing the basic concepts at least as early as 1981. But it is new to the commercial RTOS world, where performance traditionally has trumped all other concerns.

Any operating system that supports multiple address spaces supports the concept of partitions and provides some measure of isolation, both between partitions, and between any partition and the OS. A partition requests an OS service by “trapping” to the kernel, i.e. by executing a special instruction that causes an interrupt. This puts the computer in kernel mode, which allows the OS to do whatever it needs to do, including reading or writing I/O control registers or even modifying the memory map. From here, the most efficient way for the OS to provide the service is to execute all of the service code in kernel mode. This saves context switches, but it places a lot of code in the kernel that could perhaps reside elsewhere.

What Rushby proposed was for the kernel to support carefully controlled communications between non-kernel partitions. The communication channels allow one partition to provide a service to another with minimal intervention by the kernel. RTOS services can thus be moved into non-privileged or partially privileged partitions, leaving behind only those functions that must execute in kernel mode. Isolated partitions communicate through kernel-mediated channels. These channels are established statically when the partitions are created.

Middleware Services

The middleware services layer provides for an extended scope of the separation concepts introduced by the partitioner. Middleware services are concerned about end-to-end data processing, and not just the single microprocessor data processing of the Separation Kernel. At the middleware layer, we begin to enforce the more traditional concepts of information flow. Each partition/address space in the system, no matter which microprocessor it is resident on, has a unique security label/classification. The system architect uses these labels to define the authorized communication between components. The labeling of the partitions and communication channels is used to satisfy the security policy. The middleware level is responsible for ensuring end-to-end security, through the following:

  1. Labeling - The middleware layer must ensure that messages sent between individual partitions are correctly labeled with the sender's security classification.
  2. Filtering - The middleware layer is responsible for filtering out any messages that are not appropriately labeled before delivering them to the recipient.
  3. Maintaining Information Flow Controls - The system architect designs the system with specific authorized information flow restrictions, and it is these restrictions that the middleware layer enforces.

At the middleware layer we can introduce the concept of authorized information flow. If the system architect designs the system so that two partitions can communicate, then information flow between these partitions is authorized. A system can be designed to be a collection of isolated enclaves, where partitions exist within a single enclave and there is no information flow between enclaves. The MILS architecture will now allow the use of computer security measures to build systems and achieve the same assurance levels as these “physically isolated component” systems.

In the MILS architecture, all O/S code not necessary for performing Separation Kernel functions was moved out of privileged mode. Thus, by default, O/S service code (e.g. device drivers, file system, POSIX) has moved into the middleware layer. This is done to prevent various software and network attacks from elevating a processes privilege to an unauthorized level. Each enclave's partition can be configured to utilize a single set of O/S services code with it evaluated according to the enclave's requirements.

Application Layer

MILS empowers the application layer to protect itself. And the application layer is responsible for enforcing application security policies. It is at this layer that the system provides for application-specific security policies. Any partition that processes data from more than one secure application realms must be considered a privileged partition.

Partitioning Communication System

The Partitioning Communication System is a portion of MILS Middleware responsible for all communication between MILS nodes.

The purpose of the PCS is to extend the protected environment of MILS kernel to multiple nodes. The PCS was developed with a similar minimalist philosophy to MILS Separation Kernel.


The PCS extends the four MILS policies to include end-to-end versions of these policies, but only these policies.

  • End-to-End Information Flow
  • End-to-End Data Isolation
  • End-to-End Periods Processing
  • End-to-End Damage Limitation

Thus, the PCS Leverages the MILS Separation Kernel to enable the application layer entities to enforce, manage, and control their own application level security policies in such a manner that the application level security policies are non-bypassable, evaluatable, always-invoked, and tamper-proof.

The result is a communications architecture that allows the security kernel and the PCS to share the responsibility of security with the application. PCS must provide the following capabilities:

  • Strong identity of nodes within enclave.
  • Cryptographic separation of levels.
  • Cryptographic separation of communities of interest.
  • Bandwidth provisioning & partitioning.
  • Secure configuration of all nodes in enclave.
  • Secure application instantiation.
  • Secure clock synchronization.
  • Signed partition images.
  • Elimination of covert channels (both storage and timing).

Real-time MILS CORBA

The synthesis of MILS and Real-time CORBA yield an unexpected benefit. The flexibility of Real-time CORBA allows easier realization of MILS protection.

The MILS architecture is all about location awareness. A properly designed secure system built with MILS will by intent separate appropriate functions into separate partitions to take advantage of the MILS partitioning protection.

Real-time CORBA is all about location transparency. The application code of a properly designed distributed system built with Real-time CORBA will not be aware of the location of the different parts of the system. This great flexibility can be used to optimize performance by rearranging what partitions each system object executes in. Mistakes in system layout can be corrected late in the development cycle.

The combination of MILS with Real-time CORBA allows system engineers to rearrange the location of system functions in order to better take advantage of the MILS partitioning protection.

MILS can Handle MLS

While a MILS Separation Kernel is quite ignorant of the traditional Multi-Level Security (MLS) required for military and intelligence systems MILS is quite capable of supporting MLS systems. MILS can be used to construct such systems because of the strong separation guarantees the MILS architecture and certification process.

Benefits of Using MILS

What, then, are the concrete, bottom-line benefits to using a MILS architecture?

  • Reduction in physical hardware. For systems which require separation of top secret and unclassified information in communications, you no longer need separate boxes to manage and enforce data separation. This provides weight, space and power savings for the war fighter.
  • Easier control and management of information among various communities of interest.
  • Cheaper development of highly secure systems, as well as a faster time-to-market. Using COTS EAL-7 certified software will reduce development costs and efforts, as expensive, time-consuming custom-built solutions will no longer be necessary.
  • Overall increase in safety. EAL-7 certified software solutions will enhance the safety and reliability of secure systems.
  • Less need for re-architecting systems to meet security standards. Systems built with COTS RTOS and middleware components which will be upgraded to MILS will require less re-architecting.

Learn more about OIS's definitive implementation of the PCS technology, PCSexpress, and how you can use it to transparently build high-assurance network communications regardless of the types of communications architecture you use for your applications.