An Integration Framework for MILS Multiple Independent Levels of Security (MILS) Technology for High...

An Integration Framework for MILSAn Integration Framework for MILS

Multiple Independent Levels of Security (MILS) TechnologyMultiple Independent Levels of Security (MILS) Technologyfor High Confidence Systemsfor High Confidence Systems

High Assurance Security ArchitectureHigh Assurance Security Architecturefor Embedded Systems for Embedded Systems

19 June 2007 19 June 2007

Tod ReinhartAFRL

Rance DeLongLynuxWorks

John RushbySRI International

Carolyn Boettcher

Raytheon

2 Space and Airborne Systems

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 mean the ever increasing need for Safe/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

Processor R1

App

Processor C1

App

Top Secret

Secret

Processor R2

App

Processor Rn

App

Processor B2

App

Processor Bn

App

App

Processor B1

Processor C2

App

Unclassified

SneakerNET

Processor R1

App

Processor C1

AppApp

Top Secret

Secret

Processor R2

App

Processor Rn

App

Processor B2

App

Processor Bn

App

AppApp

Processor B1

Processor C2

AppApp

Unclassified

SneakerNETSneakerNET

• 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 affordably certify and field MLS/MSLS

solutions on their systems and platforms?


High Assurance Security Architecture for Embedded Systems

MILS ArchitectureEnabling technology providing 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)

MILS Activity AFRL/IFTA led cost share effort to provide affordable and near term obtainable 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

Processor

RTOS Micro Kernel (Separation Kernel)

Memory Manage Unit, Inter PartitionCommunicationsInterrupts

Application Partitions

RT-CORBA /DDS

Guest OS /Run-TimeLibraries

S

(SL)

RT-CORBA/ DDS

MinimumRun-Time

Library

S, TS

(MLS)

RT-CORBA /DDS


TS

(SL)

NetworkInterface

Unit

(MSL / MLS)

PCS

(MLS)

File SystemDriver

(MSL / MLS)

DisplayManager

(MSL)

TokenServiceDriver

(MSL)

MSL - Multi-Single LevelMLS - Multi-Level SecureSL - Single LevelCORBA - Client / ServerDDS - Publish / SubscribePCS - Partitioning Communications

System

User Mode

Privilege Mode

TrustedPath


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

Processor

RTOS Micro Kernel (MILS Separation Kernel)

Supervisor ModeMMU, Inter PartitionCommunicationsInterrupts

Application (User Mode) Partitions

RT CORBADDS


S

(SL)

RT CORBADDS

MinimumRun-Time

Library

S, TS

(MLS)

RT CORBADDS


TS

(SL)

NetworkInterface

Unit

(MSL)

Trusted PathPartitionCommService

(MLS)

File Sys.

Driver

(MSL)

ConsoleManager

(MSL)

TokenServiceDriver

(MSL)

MILS - Multiple Independent

Levels of Security

MSL - Multi Single Level

MLS - Multi Level Secure

SL - Single LevelCORBA - Client / ServerDDS - Publish / Subscribe


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

separation kernel

partitioningfilesystem

TSE

• 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


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 of properties 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 are concerned 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 are concerned 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 composability of 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 security is 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 are properties then 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 on arguments that purport to justify certain claims, based on documented evidence

• 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-claims structure is called an assurance 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

AssuredApplications

AssuredMiddleware

AssuredRTOS

• 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


Acronyms

• 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

An Integration Framework for MILS Multiple Independent Levels of Security (MILS) Technology for High...

Documents

Transcript of An Integration Framework for MILS Multiple Independent Levels of Security (MILS) Technology for High...