RTC Magazine

Complex systems are designed and implemented in layers. In secure systems, trust is distributed among those layers. When security components are first assembled into layers, their resulting security properties can be determined and those layers then constructed into systems. This is an important element of the certification and accreditation process needed for secure systems. The Multiple Independent Levels of Security (MILS) architecture was designed to preserve the integrity of the layers in a complex system and to tightly control interaction among them.

This architecture has three layers: the separation kernel, the middleware and the applications. The separation kernel is very small and it’s simple to make it robust and evaluatable. It is also well understood in the MILS community. In contrast, the MILS middleware layer is extensive and much more complex, especially in distributed systems. The purpose of this article is to explore that layer. MILS middleware functions for distributed systems can be grouped into three categories:

• Operating system (OS) services

• Partitioning communications system

• Network middleware

Operating System Services

In traditional architectures with monolithic kernels, system services such as device drivers, memory management, I/O primitives, file systems and network protocol stacks are part of the kernel and run in privileged (supervisor) mode. These services are not part of a MILS separation kernel—they are moved to the middleware layer where they run in unprivileged (user) mode.

This difference is important. When OS service code runs in privileged mode, there is no restriction on what it can do. Privileged code can potentially violate the security policy. Therefore, rigorous examination and testing are required to verify that the code does not violate the policy, even indirectly. The level of effort required to perform this verification escalates rapidly as code size and complexity grow. The MILS separation kernel rigorously enforces four fundamental security policies: data separation, control of information flow, periods processing and damage limitation. Because MILS OS services run in user mode, code that was previously able to violate these policies is now strictly subject to them. Evaluation and certification are more straightforward and effective.

MILS OS services can be implemented in a number of useful ways. They can become part of guest operating systems, reside in dedicated partitions, or be organized as minimal libraries. A system can use all of these implementations simultaneously.

The industry paradigm of “reuse, don’t reinvent,” makes it probable that the application code in a MILS partition was originally developed for another OS such as Windows, Linux, or VxWorks. An adaptation to their hardware abstraction layer (HAL) can cause these operating systems to “see” the separation kernel as the processor, becoming the separation kernel’s “guest.” A guest OS runs in user mode MILS partition, working only with the memory and constrained to the CPU time budgets that have been configured for that partition. This symbiotic relationship between the minimal MILS separation kernel and a fully featured guest OS has several benefits:

• Protects investment in existing software

• Familiar API and development environment for new applications

• Enables unit testing on commodity hardware

A guest OS is larger and more complex than the MILS separation kernel. To manage schedule risk and reduce evaluation cost, partitions that include a guest OS should process a single level (e.g., secret vs. top-secret) of classified data. If a single CPU processes both secret and top-secret data, then one partition should contain the secret data and another partition should contain the top-secret data. Each partition is then “system high.” Evaluations of the secret and the top-secret partitions are independent because the high robustness MILS separation kernel can be trusted to keep them separate. A medium robustness evaluation for each application partition is appropriate. Medium robustness is approximately Common Criteria Evaluation and Assurance Level 4 (EAL4). Evaluation at this level is practical and achievable for large code bodies.

In the MILS architecture, a network protocol stack is middleware. Network protocol stacks often require their own execution context. Isolating network protocols into their own private partitions has several advantages:

• Facilitates use of the stack by multiple applications

• Protects the applications and the stack from each other

• Makes stack evaluation independent of application evaluation.

Existing distributed application code bases can be most effectively leveraged if the network API, such as the socket() interface, is not changed. When the socket API and the network protocol stack reside in the same partition, send() nominally copies outbound data to network buffers and then passes control to the stack’s lower layers. A MILS socket library, illustrated in Figure 1, uses the separation kernel’s facility for controlled information flow to send outbound data to the network protocol stack in its own partition. Inbound data is handled similarly but in the opposite direction.

Some partitions may contain multi-level applications or security functions such as downgraders or guards. High robustness evaluations, approximately EAL6, are appropriate for these partitions. If any code in a partition must be evaluated at high robustness levels, then all code in that partition must be evaluated at high robustness. Cost and risk management dictate that these partitions contain the absolute minimum amount of code possible. A reasonable approach is to organize OS services into a minimal library to be used in multi-level security (MLS) partitions.

Distributed System Threats

Communication exposes data to significant threats to confidentiality, integrity and availability. The sources of these threats are vulnerabilities in the network components that connect computers: protocol stacks, interface drivers, switches, routers, etc. Procurement policy mandates the use of COTS network components, creating a paradox. If these components provide any protection at all, it has typically been implemented as a fail-first/patch-later afterthought, fraught with well-known vulnerabilities. We are required to place data in the custody of network components that were designed to transport data, not to protect it.

Network protocol stacks such as TCP/IP are large and complex. They can be attacked in many ways. CERT lists hundreds of vulnerabilities in TCP/IP that are child’s play to a motivated attacker. The typical reaction to stack vulnerabilities is to apply encryption at the link level. This is not always effective. Application or stack vulnerabilities can cause encryption to be bypassed. Even when applied, encryption suffers from key management issues that limit its effectiveness. While it is a necessary first step, encryption is not enough to completely protect data while it is in transit.

The Partitioned Communications System

The previously defined paradox has a solution. The separation kernel’s security policy enforcement can be leveraged to interpose a trustworthy protection function. This protection function is the Partitioning Communications System (PCS), MILS middleware that is on the road toward a high robustness evaluation. The PCS is interposed between the application and the network protocol stack as illustrated in Figure 2.

A straightforward way to understand the PCS is to view it as a super virtual private network (VPN) that enforces security policies on transmissions between MILS nodes. The PCS encrypts the data before it reaches the protocol stack. The separation kernel’s guaranteed control of information flow ensures that encryption can’t be bypassed. Unencrypted (“red”) data that could have been diverted to an unauthorized recipient by a vulnerable protocol stack is now safe. The data is encrypted (“black”) before it was ever put into the custody of code that is not as trustworthy as the PCS.

An attacker can still gain control over the other end of a circuit. IP and MAC addresses can easily be forged. A related attack is to kidnap the TCP port number. When this happens, we could be blindly sending classified data to the wrong program just because it is running in the right computer. The PCS counters these threats by strongly identifying the other computer, application and application instance before allowing data to flow.

The PCS keeps data with multiple security levels and Communities of Interest (COIs) robustly separated. DoD networks often have multiple physical links connecting the same endpoints. Each link is dedicated to a unique classification level or COI to effect separation. These “air gaps” work, but they are costly and awkward. Human intervention is required to downgrade data and manually move it between networks. When the PCS is interposed in the data path, the separation of data with multiple levels and COIs on a single link is trustworthy. It is no longer necessary to have multiple links just to guarantee data separation. Automated downgraders can move data between levels. When human downgrading or verification is required, data flows faster because single COI networks can be physically interconnected without introducing additional threats.

In addition to separation, the PCS enforces bandwidth allocation among the applications sharing a physical channel. Use of the channel by one application can’t affect the availability of that channel to any other application, guaranteeing Quality of Service, a requirement for robust distributed systems.

Evil intentions can be accomplished by blocking communications. Flooding a network with packets implements a Denial of Service (DOS) attack, equivalent to jamming radio frequencies. The PCS limits the amount of traffic that can be sent to an application to what is configured in the security policy, reducing a DOS attack’s damage potential.

Unauthorized use of authorized channels can leak sensitive data. By controlling message length and/or timing, a subverted application can signal information completely unrelated to what is being transmitted. These unintended data paths through the system are called Covert Channels. The PCS can be configured to make all message fragments the same size and to occur at constant time intervals, countering that threat.

The PCS is responsible for loading and running dynamically invoked applications. Before loading, the PCS verifies that the code comes from an authorized source and hasn’t been modified. This validation blocks viruses, worms, Trojan horses and other subversions. The PCS also constrains the applications that it loads to budgets for memory, CPU time, kernel object allocations and inter-process connection privileges.

The initial crack in a distributed system’s defenses can often be caused by forcing error conditions that cause nodes in the system to run with different versions of the overall security policy. Each node is correctly enforcing its local policy, but inconsistencies or incompatibilities between two or more nodes can lead to system-wide security compromise. The PCS verifies that security policy configurations are consistent before data is exchanged. This protection is provided for both centralized and federated policy distributions.

Network Middleware

The conversion path to MILS for CORBA, DDS and Web Services is straightforward. Guest operating systems and the MILS socket library facilitate porting from the platforms where these distributed application foundations are currently supported. Typical implementation is a library to be linked with the application code. Therefore, application code and the libraries that it uses reside in the same partition.

These application foundations all have some security features dealing mostly with authentication and access control. They all have the same weakness: the application and the middleware security functions reside in the same partition. Because they are in the same address space, the security functions can’t be protected from an errant or malicious application.

Even with this weakness, applications using these foundations and their security features on a MILS platform with the PCS are more secure than on a traditional Operating System platform. The middleware security functions operate as they did in their original environments. The MILS platform counters additional threats that CORBA, DDS, or Web Services security functions do not even consider. Protecting CORBA, DDS, or Web Services security functions from the applications that use them is a topic for further research.

The key benefit of MILS, dramatically reducing the amount of security-critical code so that we can dramatically increase the scrutiny of that code, is just as relevant to middleware as it is to the separation kernel. By leveraging the separation kernel’s guarantees of data isolation and control of information flow, the total complement of software required to implement a distributed system can be divided into a set of independent components. These components are protected from each other, resulting in a more robust system.

The key benefit of MILS also applies to end-to-end security policy enforcement for distributed systems as implemented by the PCS. The amount of security policy enforcing code is dramatically reduced. Systems are more robust and resilient to attack. The MILS architecture also reduces distributed system project cost and schedule risk for component evaluations and certifications as well as for accreditation of the system as a whole.

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