The research and development work within the CITADEL project is focused on extending MILS for use in protecting critical infrastructures. The MILS architectural approach has emerged as a new strategy for the cost effective construction of systems requiring dependability with high assurance. MILS is popularly characterized as the use of a separation kernel to run applications belonging to diverse security domains (or safety criticalities) on the same processor. Key concepts of the MILS architectural approach include separation, component integration, policy architecture and physical resource sharing. The MILS idea has evolved beyond this first simple characterization.
The MILS approach has two aspects, or phases: 1) the development of a policy architecture that accomplishes a desired goal, and, 2) the implementation of that policy architecture upon a platform that manages shared resources in a way that the fundamental assumptions of any policy architecture are satisfied.
Figure 1: Policy Architecture Diagram
The architectural aspect of the MILS approach starts with a vigorous decomposition of a desired function into an abstract policy architecture. A “good” policy architecture decomposition is one that results in components that exhibit simplicity and singleness of purpose, and that embodies the principle of least privilege, permitting only the necessary interactions among components within the architecture. Figure 1 illustrates a simple policy architecture consisting of five components and their permitted interaction paths. One of the components, F1, is a trusted subject.
The implementation aspect of the MILS approach depends on the use of a separation kernel and a set of standardized MILS foundational components that compose with the separation kernel to form the MILS platform. This platform forms a “substrate,” analogous to an FPGA, that can be configured to realize the policy architecture, and that subsequently enforces the policy architecture. It accomplishes the latter by enforcing two primitive properties: isolation and information flow control. The system implementation activity refines architectural components and connectors down to a configuration that determines the resources exported by the MILS platform and the permitted interactions among them. The initialized configuration of the MILS platform establishes and preserves the correspondence of the abstract policy architecture to the concrete implementation. Figure 2 depicts the policy architecture of Figure 1 (a) and its straightforward realization (b) as a configuration of a separation kernel.
Figure 2: Policy architecture realized using a separation kernel
A policy architecture is made up of operational components joined by interactions. The absence of an interaction is as important to the architecture as the presence of one. Some operational components have strict behavioral or property requirements specified by the architect because they are required in order for the architecture to fulfill its purpose. We call these requirements local policies, and say that the implementations of those components are “trusted” to enforce the specified local policies. Local policies may relate to any kind of local action of an operational component that the architect deems important. Some trusted components may be recognizable as conventional security enforcement mechanisms, but all enforce some policy, and are treated in MILS as policy-enforcing components.
The policy architecture establishes the maximal information flow (or causality) to be permitted in the system. Important properties of the resulting system may thus be supported by the architecture itself. The trusted operational components act to restrict the actual information flow (or causality) of the system. The joint action of these trusted components together with the (policy) architecture combine to create the (emergent) security property (or properties) of the system. Security or safety is typically an emergent property, not a property that the system has as a result of being composed of components that each have that property.
A “system security policy” is not identical to the policy architecture of a system. The security policy of a system arises from the combination of the local policies of the operational components, the structure of their composition (policy architecture), and the enforcement of that structure. Only in the very simplest of (degenerate) cases (when there are no “trusted” operational components) does the security policy of the system reduce to the MILS policy architecture.
The separation kernel exports subjects and other resources that are constructed from physical system memory and raw devices. The foundational components, when composed with a separation kernel, export instances of additional resource types constructed from the physical resources provided by devices, such as files and directories from mass storage device resources, network connections from network interface devices, and windows and user input events from user interface devices. As each foundational component is added, the vocabulary of resource types available in the MILS platform to express a policy architecture is increased. The composition of MILS foundational components with the separation kernel in the foundational plane produces the MILS platform to support the operational and monitoring planes. The policy architecture from our previous example is implemented in the operational plane. The configuration plane represents languages, representations, tools and procedures for preparing and initializing the other MILS planes with the configuration data.
