Design Article
MILS architecture simplifies design of high assurance systems – Part 1
Paul Parkinson and Arlen Baker, Wind River
8/11/2011 12:36 AM EDT
In Part 1 of this two-part story, we’ll review multiple independent levels of security (MILS) architecture, which provides an effective approach to creating and validating an operating system for multi-level secure systems. In Part 2, we’ll discuss how that can be used to host applications.
Traditionally, multi-level secure systems have been built using multiple physically separated computers, networks, and displays, which require expensive equipment that occupies a large footprint in terms of size, weight, and power. Although there have been efforts to address the requirement for multi-level secure systems through the development of monolithic secure operating systems running on a single platform, the implementation and certification could take 10 or more years. The MILS was originally proposed by John Rushby in 1984 to overcome these problems, but it is only in recent years that we’ve reached an inflexion point where need and feasibility have converged.1
The need can span from a single-level secure system, in which one security domain processes information; to a multi-single level secure (MSLS) system, in which two or more security domains are being processed but are always separated in time or space; to a multi-level secure (MLS) system, in which two or more security domains are processed within the same time and space. The complexities of fighting a modern war require that data from coalition operations be brought together with multiple secure government communications without reduction of domain separation. Here, a Cross-Domain Solution (CDS) provides the user with the ability to access or transfer information between two or more security domains.2
In the United States, government policy and legislation led to the National Security Telecommunications and Information Systems Security Policy (NSTISSP) from the National Security Agency (NSA) Information Assurance Directorate.3 This policy mandates information assurance for any system entering, processing, storing, displaying, or transmitting national security information. It also requires commercial off-the-shelf (COTS) components of such systems to demonstrate sufficient information assurance by evaluation and validation, using an approved method. One of these methods is the Common Criteria, which includes provisions for international mutual recognition.4 At higher evaluation levels, it also requires the use of a formal mathematical methodology to specify security requirements and to evaluate the design and performance of any information technology systems against those requirements.
To help vendors apply Common Criteria to COTS products, the U.S. National Information Assurance Partnership (NIAP) created the Common Criteria Evaluation and Validation Scheme (CCEVS). NIAP developed the U.S. Government Protection Profile for Separation Kernels in Environments Requiring High Robustness (SKPP), which includes requirements for a MILS separation kernel that will meet the information assurance requirements intended by the MILS architecture. The SKPP provides guidance to vendors developing COTS MILS operating systems, which can be used to build a multi-level secure system.
As far as the feasibility of using the MILS architecture, that has been enabled by continuing advances in modern processors. These processors now provide sufficient performance and capability to run multiple applications in completely separate domains on the same platform, with hardware security features that provide effective isolation. The result is that the proper implementation of MILS-based systems is now not only technically possible but also economically viable.
MILS architecture
The fundamental problem of a monolithic multi-level secure architecture is that all of the code needs to be scrutinized to the level required for the highest-assurance components. As the functionality and size of the system increase, the development and security evaluation effort involved also rise dramatically, which can make them prohibitively expensive. The scrutiny includes infiltration, exfiltration, and mediation.5 The MILS architecture streamlines these tasks with a divide-and-conquer approach by reducing the amount of security-critical code and increasing the scrutiny of that code. This is achieved via separation, composition, and layered assurance. The layered assurance principle states that a component or layer cannot be more secure than the component or layer beneath it in the stack. An application, for example, cannot be securely isolated from another application unless the underlying kernel and hardware perform the isolation correctly and in a secure manner.
The MILS divide-and-conquer approach is implemented in four layers: trusted hardware, separation kernel, middleware, and applications (see figure 1). The separation kernel is built on four fundamental security policies:
Traditionally, multi-level secure systems have been built using multiple physically separated computers, networks, and displays, which require expensive equipment that occupies a large footprint in terms of size, weight, and power. Although there have been efforts to address the requirement for multi-level secure systems through the development of monolithic secure operating systems running on a single platform, the implementation and certification could take 10 or more years. The MILS was originally proposed by John Rushby in 1984 to overcome these problems, but it is only in recent years that we’ve reached an inflexion point where need and feasibility have converged.1
The need can span from a single-level secure system, in which one security domain processes information; to a multi-single level secure (MSLS) system, in which two or more security domains are being processed but are always separated in time or space; to a multi-level secure (MLS) system, in which two or more security domains are processed within the same time and space. The complexities of fighting a modern war require that data from coalition operations be brought together with multiple secure government communications without reduction of domain separation. Here, a Cross-Domain Solution (CDS) provides the user with the ability to access or transfer information between two or more security domains.2
In the United States, government policy and legislation led to the National Security Telecommunications and Information Systems Security Policy (NSTISSP) from the National Security Agency (NSA) Information Assurance Directorate.3 This policy mandates information assurance for any system entering, processing, storing, displaying, or transmitting national security information. It also requires commercial off-the-shelf (COTS) components of such systems to demonstrate sufficient information assurance by evaluation and validation, using an approved method. One of these methods is the Common Criteria, which includes provisions for international mutual recognition.4 At higher evaluation levels, it also requires the use of a formal mathematical methodology to specify security requirements and to evaluate the design and performance of any information technology systems against those requirements.
To help vendors apply Common Criteria to COTS products, the U.S. National Information Assurance Partnership (NIAP) created the Common Criteria Evaluation and Validation Scheme (CCEVS). NIAP developed the U.S. Government Protection Profile for Separation Kernels in Environments Requiring High Robustness (SKPP), which includes requirements for a MILS separation kernel that will meet the information assurance requirements intended by the MILS architecture. The SKPP provides guidance to vendors developing COTS MILS operating systems, which can be used to build a multi-level secure system.
As far as the feasibility of using the MILS architecture, that has been enabled by continuing advances in modern processors. These processors now provide sufficient performance and capability to run multiple applications in completely separate domains on the same platform, with hardware security features that provide effective isolation. The result is that the proper implementation of MILS-based systems is now not only technically possible but also economically viable.
MILS architecture
The fundamental problem of a monolithic multi-level secure architecture is that all of the code needs to be scrutinized to the level required for the highest-assurance components. As the functionality and size of the system increase, the development and security evaluation effort involved also rise dramatically, which can make them prohibitively expensive. The scrutiny includes infiltration, exfiltration, and mediation.5 The MILS architecture streamlines these tasks with a divide-and-conquer approach by reducing the amount of security-critical code and increasing the scrutiny of that code. This is achieved via separation, composition, and layered assurance. The layered assurance principle states that a component or layer cannot be more secure than the component or layer beneath it in the stack. An application, for example, cannot be securely isolated from another application unless the underlying kernel and hardware perform the isolation correctly and in a secure manner.
The MILS divide-and-conquer approach is implemented in four layers: trusted hardware, separation kernel, middleware, and applications (see figure 1). The separation kernel is built on four fundamental security policies:
• Data isolation, which ensures that a partition cannot access resources in other partitions.These four policies create an architecture that allows creation of additional components that are non-bypassable, evaluatable, always invoked, and tamperproof, which is known as NEAT.6
• Periods processing, which ensures that applications within partitions execute for the specified duration in the system schedule.
• Information flow, which defines the permitted information flow between partitions.
• Fault isolation, which means that a failure in one partition does not impact any other partition within the system.
Figure 1: The MILS architecture streamlines validation using separation, composition, and layered assurance. The MILS divide-and-conquer approach is implemented in four layers: trusted hardware, separation kernel, middleware, and applications. (Courtesy of Wind River Services)
|
|
|
|
|
Navigate to related information
EREBUS
8/18/2011 4:00 PM EDT
Hi Paul,
I agree, multilevel security will only work if you maintain rigid partitions. I also think that data encryption should be a normal process. The data owner should encrypt the data being sent to the server and the server should establish who other than the owner can have access. Whenever the data is used or accessed withing the server, it is never decrypted except by owner designated processes, which should already possess the acess code.
With this approach, anyone who manages to download the data must still have the decrypt key before the data can be used. No one can just tap the line for the data, because all they will see is encrypted data.
Most of these issues should be transparent to the owner once their account is established and anyone trying to crack the server can immediately generate alerts if they try to access anything for which they have not been give access to.
Thanks
Sign in to Reply