Tod Reinhart AFRL

An Integration Framework for MILSMultiple Independent Levels of Security (MILS) Technologyfor High Confidence SystemsHigh Assurance Security Architecturefor Embedded Systems 19 June 2007 Tod Reinhart AFRL John Rushby SRI International Carolyn Boettcher Raytheon Rance DeLong LynuxWorks

Introduction • Net-Centric Operations (NCO) is characterized by the sharing of information at all levels (TS/SCI through Unclassified) between new and legacy systems within the Global Information Grid (GIG) • The architecture of existing legacy systems must be modernized to interoperate with new systems such as Unmanned Air Vehicles (UAVs) in order to achieve the NCO vision (Net-Enabled) • Information that is passed between and within these systems must be shared securely and to protect the warfighter and not compromise the mission • Information needs to be sharedbetween U.S. & Coalition Partners involving - • Multiple levels (MLS/MSLS) • Smart Push / Smart Pull • Web Services • New capabilities and information sharing meanthe ever increasing need forSafe/Secure components for Cross Domain Solutions (CDS) and platform mixed criticality

CDS / Multi-Level Data • Current measures used to handle multilevel data • “System High” Operation • Physical Separation by Level / Domain and by Community of Interest (COI) • Multiple servers in data centers • Multiple networks connecting the same endpoints • Multiple workstations on a single desk • Information sharing via the “SneakerNet” requiring significant human intervention • Current CDS and MLS/MSLS capabilities • Difficult to implement and certify • Costly to maintain and reconfigure • A problem to extend and to interconnect

Our Challenge How can the USAF, other DoD services and agencies affordablycertify and field MLS/MSLS solutions on their systems and platforms?

High Assurance Security Architecture for Embedded Systems MILS Activity • AFRL/IFTA led cost share effort to provide affordableandnear termobtainable solutions to achieve a high assurance architecture for use in DoD mission-critical embedded systems and workstations, comprised of RTOS and middleware products and support tools to aid in development, test, and evaluation • Teamed with NSA, Open Systems Joint Task Force (OSD-ATL), DoD program offices, system integrators, commercial vendors, and academia • Initiated under an earlier Air Force RDT&E task to meet the security challenges of embedded platforms such as the F-22A and F-35 MILS Architecture Enabling technologyproviding a foundational infrastructure for Cross Domain Solutions and mixed criticality (Safety/Security), supporting MLS & MSLS and applicable to: • Weapon Systems • Communication Systems / Facilities • Command and Control (C2) Platforms Enabling secure, dependable GIG Information Assurance (IA)

AF/NSA MILS Vision Fusing the best from the Safety and Security technologies • Safety • RTCA DO-178B Level A • ARINC-653 • Security • Common Criteria • High Robustness • DCID 6/3 Separation to ENABLE provision of MSLS/MLS Computing, Web, and Network Services to • Weapons Systems • Communications Facilities • Command & ControlPlatforms

MILS Architecture MILS - Multiple Independent Levels of Security MSL - Multi Single Level MLS - Multi Level Secure SL - Single Level CORBA - Client / Server DDS - Publish / Subscribe File Sys. Driver (MSL) RTOS Micro Kernel (MILS Separation Kernel) Supervisor Mode MMU, Inter Partition Communications Interrupts Processor Application (User Mode) Partitions S (SL) TS (SL) S, TS (MLS) Trusted Path RT CORBA DDS RT CORBA DDS RT CORBA DDS Network Interface Unit (MSL) Console Manager (MSL) Token Service Driver (MSL) Partition Comm Service (MLS) Guest OS / Run-TimeLibraries Minimum Run-TimeLibrary Guest OS / Run-TimeLibraries

The New Systems Challenge • Affordability and rapid pace of change creates a desire to use COTS components, which are medium robustness (at best) • But medium robustness doesn’t measure up to the security required in many applications • We need a COTS marketplace for high robustness components • But we also need a way to put high robustness components together to create high robustness systems • That is, an architecture: MILS • But security is about assurance as well as mechanisms, so we also need a way to put the assurance arguments together • That is, compositional assurance: MIPP

Security Assurance Background • The framework for evaluation of secure systems (mechanisms & assurance) is provided by the Common Criteria (CC) • Evaluation Assurance Levels (EAL) go from 1 (low) to 7 (high) • Levels up to 4 are recognized internationally • Medium robustness corresponds to EAL 4 • High robustness is around EAL 7 (but has differences) • The CC are specialized to classes of systems/components through Protection Profiles (PP) to Security Targets (ST) to Targets of Evaluation (TOE) • PPs are developed by a public process, but need to be approved by the Government for DoD use • Components are evaluated to a PP or ST/TOE by an independent (NIAP) lab

MILS Activity • MILS is a component-based security architecture • Multiple Independent Levels of Security • Endorsed by NSA, history going back 25 years, adopted for F22 and other modern platforms • COTS marketplace stimulated by development of component PPs (many AF-funded) for high robustness • E.g., separation kernel (SKPP), console subsystem, partitioning communication system, network subsystems, file system, data distribution service • The SKPP and the first high robustness separation kernel are nearing completion of evaluation • More PP approvals and component evaluations to follow

MIPP and CCAE • The bottom-up activity is thriving, but what about top-down? • We need a way to derive system-level properties from evaluated components • MIPP: MILS Integration Protection Profile is developing the science (for compositional certification) and deducing constraints on PPs so that they work together to deliver system-level security • CCAE: Common Criteria Authoring Environment provides automated assistance in development of coherent PPs (like an integrated development environment for PPs) • The rest of this talk gives technical (but nonspecialist) background on MILS and MIPP

Intuitive Security Architecture • Almost all system designs are portrayedin diagrams using circles and arrows • But in security, these have a particular (often unconscious) force and interpretation • Arrows indicate interfaces • Implicitly, absence of an arrow means absence of component interaction • Circles indicate encapsulated data, information, control, etc. • The only things that happen inside a circle are consequences of things in that circle and the incoming arrows, and the only things that change are the internal state of the circle and its outgoing arrows

Good Intuitive Security Architecture • Try to arrange the circles and arrows so that security depends on only a few trusted circles • And those are trusted to do only relatively simple things • Split big circles up if necessary to achieve these

The MILS Idea • The structure of the system implementation should directly reflect the circles and arrows picture • We can afford to have lots of circles and arrows, and should use this to reduce and simplify the trusted circles separation kernel TSE partitioningfilesystem

The MILS Architecture • The MILS Architecture is a combination of the idea and the technology • Deconstruct functions so the trusted components are as simple as possible • These trusted components are called operational • Allow operational and untrusted components to share resources • The components that do the secure sharing (separation kernel, etc.) are called foundational • We need protection profiles for these classes of components • Assurance specialization goes from Common Criteria (CC) to Protection Profile (PP) to Security Target (ST) to Target of Evaluation (TOE)

Advantages of the MILS Architecture • The foundational and operational security concerns are kept separate • Separate kinds of components • Separate kinds of PPs • Cf. traditional security kernels, where one component partitioned many kinds of resources (complex implementation), and either enforced a single operational security property (too rigid to be useful) or several (too complicated to be credible) • MILS is feasible today because we know how to do fine grain partitioning (e.g., paravirtualization), have better hardware support, and can afford the overhead

MILS Integration Protection Profile • Security is a system property • Existing MILS protection profiles (PPs) are for components • How do we know that a system composed of evaluated components is secure? • And how is the evaluation of the system constructed from the evaluations of its components? • This is what the MILS Integration PP (MIPP) is about • It is an instance of compositional certification • A bold vision that pushes the state of the art

Compositional Certification • Because safety, security, etc. are system properties,traditional certification regimes consider only complete systems(or major components) • E.g., the FAA certifies only airplanes, engines, propellers • Even when component already evaluated as part of another system, certifiers reserve right to look inside (cf. RSC) • But modern business practices (outsourcing, COTS) make this increasingly untenable, even in first use of a component • System integrator, let alone system certifier, may have little visibility into the component • They merely define its requirements • The component should be evaluated separately • Evaluation is in terms ofproperties delivered at interfaces • System certification is then built on these interfaces and properties,with no looking inside

Compositional Certification for MILS • Feasibility of compositional certification depends on the architecture • Because compositional certification is all about properties delivered at interfaces, we need • Known interfaces (the paths for component interaction) • There must be no paths for component interaction outside the known interfaces, even in the presence of faults, or of malice in untrusted components • Meaningful properties • Must be meaningful at interfaces • So they can be evaluated locally • Must be meaningful in combination • So they compose to yield evaluable system properties • MILS is an architecture that promotes these characteristics

Two Kinds of Components, Two Kinds of PPs • The foundational and operational levels of the MILS architecture have different concerns and are realized by different kinds of components having different kinds of PPs • Operational level:components that provide or enforce application-specific security functionality • Examples: downgrading, authentication, MLS flow • Their PPs areconcerned with the specific security function that they provide • Foundational level:components that securely share physical resources among logical entities • Examples: separation kernel, partitioning communication system, console, file system, network stack • Their PPs areconcerned with partitioning / separation / secure sharing

Two Kinds of Components,Three Kinds of Composition We need to consider three kinds of component compositions operational / operational: need compositionality foundational / operational: need composability foundational / foundational: need additivity Consider these in turn

Compositionality Operational components combine in a way that ensures compositionality • There’s some way to calculate the properties of interacting operational components from the properties of the components (with no need to look inside), e.g.: • Component A guarantees P if environment ensures Q • Component B guarantees Q if environment ensures P • Conclude that A  B guarantees P and Q • Assumes components interact only through explicit computational mechanisms (e.g., shared variables)

Composability Foundational components ensure composabilityof operational components • Properties of a collection of interacting operational components are preserved when they are placed (suitably) in the environment provided by a collection of foundational components • Hence foundational components do not get in the way • And the combination is itself composable • Hence operational components cannot interfere with each other nor with the foundational ones

Additivity Foundational components compose with each other additively • e.g., partitioning(kernel) + partitioning(network)provides partitioning(kernel + network) We now need to ensure compositionality, composability, and additivity Theory: developing/applying the computer science to understand and achieve them Application: interpreting and formulating the science in a manner consistent, as far as possible, with the CC and existing PPs

Operational PPs and Compositionality • We might like to specify required properties of operational components in terms of information flow • Well-known that many flow properties do not compose • e.g., noninterference • Much of this is because flow securityis not a property • A property is a subset of possible traces (behaviors) • In practice, we enforce flow security by requiring something stronger that is a property (e.g., unwinding) • Suspect that if operational PPs specify claims that arepropertiesthen we can use CS-style compositional reasoning • E.g., assume-guarantee (seen earlier) • Impact on PPs: metarequirement

Foundational PPs • All these deliver the claim of separation / partitioning • No interaction among entities (circles) except through specified channels (arrows) • But specialized to the kind of entities considered Processor partitions: separation kernel (SKPP) Screen real estate: console subsystem (MCSPP) Files: file system (MFSPP) TCP/IP networks: protocol stack (MNSPP) etc.

Foundational PPs and Composability • This is what separation (as in separation kernel) is about • Separation must have as its essence the guarantee of composability for operational components • This follows when the foundational components guarantee the integrity of the interfaces of their clients • It’s not yet clear whether this constrains the operational PPs and their claims to have a certain form

Foundational PPs and Additivity • We can get additivity of foundational components if all their PPs subscribe to a common notion of separation / partitioning • And a common security environment • Common set of foundational threats (Mark Vanfleet) • Common assumptions and organizational policies • But respecting (all and only) the essential differences among the different components • e.g., computation vs. storage vs. communication • Impact on PPs: harmonization

The Essence of Certification • All certification is based onarguments that purport to justify certainclaims, based on documentedevidence • In some regimes (e.g., security), deployment decisions (i.e., judgments about the value of the claims) are separate from judgment of the credibility of the claims; in others (e.g., civil aircraft) they are combined • Evidence may be measured facts about a system (e.g., static analysis, tests, peer review, operational history of similar systems), or claims about subsystems (supported by lower level certification) • The evidence-arguments-claimsstructure is called anassurance case • Two approaches to certification: implicit(standards based), and explicit

Assurance Cases, The CC and PPs • The CC predated the emergence of explicit assurance cases • But has many of their characteristics • Tells you what to think about, not what to do • PPs specialize the CC requirements toward specific classes of system and component so that the developers of STs and specific TOEs have clear guidelines to follow • Each PP should provide the framework for an explicit assurance case • Provides the claims • Specifies evidence to produce (and methods to follow) • Provides the argument linking evidence to claims It becomes a complete assurance case when the TOE developer supplies the evidence • Need to engage the CC process to ensure consistency

Summary • The defense and intelligence community has a critical need for high assurance software • Development of high assurance, interoperable, commercially available components is desirable • International standards are needed to enable inter-operability and certifiability • Development cost and schedule risk for assured, certifiable software is too high • New tools incorporating formal methods could help with cost and schedule • There is a critical need for engineers trained in IA methods and theory Assured Applications Assured Middleware Assured RTOS • The MIPP is developing an approach to integrating multiple MILS components into a certifiable system • Many areas (e.g., aviation) need compositional certification of safety and security, so the MIPP success could have a large impact. • AFRL is actively supporting these exciting opportunities

MILS - Multiple Independent Levels of security MLS - Multilevel Security MSLS Multiple Single Levels of Security MIPP - MILS Integration Protection Profile CCAE - Common Criteria Authoring Environment CC - Common Criteria PP - Protection Profile ST - Security Target TOE - Target of Evaluation AFRL/IFTA - Air Force Research Laboratory’s Embedded Information Systems Engineering Branch NCO - Net-Centric Operations GIG - Global Information Grid UAV - Unmanned Air Vehicle CDS - Cross-Domain Solutions COI = Community of Interest IA - Information Assurance Acronyms

Tod Reinhart AFRL