Presentation is loading. Please wait.

Presentation is loading. Please wait.

An Integration Framework for MILS Multiple Independent Levels of Security (MILS) Technology for High Confidence Systems High Assurance Security Architecture.

Similar presentations


Presentation on theme: "An Integration Framework for MILS Multiple Independent Levels of Security (MILS) Technology for High Confidence Systems High Assurance Security Architecture."— Presentation transcript:

1 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 Rance DeLong LynuxWorks John Rushby SRI International Carolyn Boettcher Raytheon

2 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 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

3 3 Space and Airborne Systems 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

4 4 Space and Airborne Systems Our Challenge How can the USAF, other DoD services and agencies affordably certify and field MLS/MSLS solutions on their systems and platforms?

5 5 Space and Airborne Systems High Assurance Security Architecture for Embedded Systems 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) 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

6 6 Space and Airborne Systems 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

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

8 8 Space and Airborne Systems 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

9 9 Space and Airborne Systems 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

10 10 Space and Airborne Systems 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

11 11 Space and Airborne Systems 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

12 12 Space and Airborne Systems 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

13 13 Space and Airborne Systems 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

14 14 Space and Airborne Systems The MILS Idea separation kernel partitioning filesystem 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

15 15 Space and Airborne Systems 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)

16 16 Space and Airborne Systems 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

17 17 Space and Airborne Systems 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

18 18 Space and Airborne Systems 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

19 19 Space and Airborne Systems 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

20 20 Space and Airborne Systems 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

21 21 Space and Airborne Systems 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

22 22 Space and Airborne Systems 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)

23 23 Space and Airborne Systems 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

24 24 Space and Airborne Systems 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

25 25 Space and Airborne Systems 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

26 26 Space and Airborne Systems 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.

27 27 Space and Airborne Systems 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

28 28 Space and Airborne Systems 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

29 29 Space and Airborne Systems 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

30 30 Space and Airborne Systems 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

31 31 Space and Airborne Systems 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

32 32 Space and Airborne Systems 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


Download ppt "An Integration Framework for MILS Multiple Independent Levels of Security (MILS) Technology for High Confidence Systems High Assurance Security Architecture."

Similar presentations


Ads by Google