Transcript An Integration Framework for MILS

An Integration Framework for MILS
Multiple Independent Levels of Security (MILS) Technology
for High Confidence Systems
High Assurance Security Architecture
for 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 shared
between 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
Space and Airborne Systems
2
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
Processor R1
Unclassified
App
App
Processor Rn
App
Top Secret
App
SneakerNET
Processor C1
App
Secret
Processor C2
App
Processor B1
Space and Airborne Systems
Processor R2
App
Processor B2
App
Processor Bn
3
Our Challenge
How can the USAF, other DoD services and
agencies affordably certify and field MLS/MSLS
solutions on their systems and platforms?
Space and Airborne Systems
4
High Assurance Security Architecture
for Embedded Systems
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
MILS Architecture
Enabling 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)
Space and Airborne Systems
5
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 & Control
Platforms
Space and Airborne Systems
6
MILS Architecture
MILS - Multiple Independent
Application (User Mode) Partitions
Levels of Security
MSL - Multi Single Level
MLS - Multi Level Secure
SL - Single Level
CORBA - Client / Server
DDS
- Publish / Subscribe
S
TS
S, TS
(SL)
(SL)
(MLS)
RT CORBA
DDS
Guest OS /
Run-Time
Libraries
RT CORBA
DDS
Guest OS /
Run-Time
Libraries
RT CORBA
DDS
Minimum
Run-Time
Library
Trusted Path
Console
Manager
Token
Service
Driver
File
Sys.
Driver
(MSL)
(MSL)
(MSL)
Network
Interface
Unit
Partition
Comm
Service
(MSL)
(MLS)
RTOS Micro Kernel (MILS Separation Kernel)
Supervisor Mode
MMU, Inter Partition
Communications
Interrupts
Space and Airborne Systems
Processor
7
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
Space and Airborne Systems
8
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
Space and Airborne Systems
9
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
Space and Airborne Systems
10
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
Space and Airborne Systems
11
Intuitive Security Architecture
• Almost all system designs are portrayed
in 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
Space and Airborne Systems
12
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
Space and Airborne Systems
13
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
partitioning
filesystem
Space and Airborne Systems
TSE
14
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)
Space and Airborne Systems
15
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
Space and Airborne Systems
16
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
Space and Airborne Systems
17
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
Space and Airborne Systems
18
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
Space and Airborne Systems
19
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 applicationspecific 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
Space and Airborne Systems
20
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
Space and Airborne Systems
21
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)
Space and Airborne Systems
22
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
Space and Airborne Systems
23
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
Space and Airborne Systems
24
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
Space and Airborne Systems
25
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.
Space and Airborne Systems
26
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
Space and Airborne Systems
27
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
Space and Airborne Systems
28
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
Space and Airborne Systems
29
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
Space and Airborne Systems
30
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 interoperability 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
•
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
Space and Airborne Systems
Assured
Applications
Assured
Middleware
Assured
RTOS
31
Acronyms
•
AFRL/IFTA - Air Force
Research Laboratory’s
Embedded Information
Systems Engineering Branch
•
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
•
NCO - Net-Centric Operations
•
GIG - Global Information Grid
•
UAV - Unmanned Air Vehicle
•
CDS - Cross-Domain
Solutions
•
CC - Common Criteria
•
COI = Community of Interest
•
PP - Protection Profile
•
IA - Information Assurance
•
ST - Security Target
•
TOE - Target of Evaluation
Space and Airborne Systems
32