Deeply Embedded High Assurance Multiple Independent Levels of

Deeply Embedded High Assurance (Multiple Independent Levels of Security/Safety) MILS Architecture Dipak Patel Rockwell Collins dppatel@collins. rockwell. com Department of Defence wvanflee@restarea. ncsc. mil Dr. Ben A. Calloni, P. E. Lockheed Martin Aeronautics Company ben. a. calloni@lmco. com Matthew M. Wilding, Ph. D Rockwell Collins mmwildin@collins. rockwell. com Lee Mac. Learn Boeing lee. s. maclaren@f 22. boeing. com Jahn A. Luke Air Force Research Laboratory Luke Jahn A Civ AFRL/IFTA W. Mark Vanfleet This presentation represents joint research between Air Force, Boeing, Lockheed-Martin, Rockwell Collins and the National Security Agency Note: Each slide includes a TEXT window for off line reading. November 13, 2002 1

Objective What? Enable the Application Layer Entities to Enforce, Manage, and Control their own Application Level Security Policies in such a manner that the Application Level Security Policies are Non-Bypassable, Always-Invoked, Tamper-proof, and Evaluatable. We want an architecture that allows the Security Kernel to share the RESPONSIBILITY of Security with the Application. November 13, 2002 2

Objective How? Enforce an Information Flow, Data Isolation, Periods Processing, and Damage Limitation Security Policy between multiple address spaces: First, in a Microprocessor Centric Manner, i. e. , MILS RTOS Kernel, Second, in a Network Centric Manner, i. e. , MILS Middleware, in such a manner that the lower layer Security Policies are Non-Bypassable, Always Invoked, Tamper-proof, and Evaluatable November 13, 2002 3

MILS Security Architecture Definitions ● Multiple Independent Levels of Security (MILS) ➔ ➔ ● System High ➔ ➔ ● Preemptive Time and Space Partitioner (Separation Kernel) Each Partition (Address Space) Operates with either ➢ a Unique Clearance or Multi Single Level - MSL ➢ A Set of Clearances Multi Level Secure – MLS ➢ Information Flow between partitions is controlled by Separation Kernel and/or by Middleware FIREWALL Valid Clearance for all Information Valid Need To Know for some Information Multi-Level Security (MLS) ➔ ➔ ➔ Multiple Clearance Levels for Information Bell and La. Padula Tagging of Data and System Objects November 13, 2002 4

Relationship between System Modes and Assurance Levels Common Criteria ➔ ➔ EAL 3 (C-2 LOT) EAL 4 (B-1 LOT) ➢ MILS/MLS Accreditation ➢ ➢ System High w/ Type Separation (SECRET NOFORN / SECRET NATO) ➔ ➔ ➔ EAL 5 (B-2 LOT) * EAL 6 (B-3 LOT) * EAL 7 (A-1 LOT) * ➢ ➢ ➢ 1 Level Separation (TS/S; S/C; C/U) 2 Level Separation (TS/S/C; S/C/U) 3 Level Separation (TS/S/C/U) * - RM: Reference Monitor Assuming a Secure Development Environment November 13, 2002 5

MILS Security Policy Application Example E 1 RS E 2 BV E 3 Red Data Black Data RPM BPM D 1 RV D 2 BS D 3 November 13, 2002 6

MILS Security Policy Application Example MILS Provides: Information Flow Data Isolation Periods Processing Damage Limitation E 1 RS E 2 BV E 3 Red Data Black Data RPM BPM D 1 RV D 2 BS D 3 November 13, 2002 7

Monolithic Security Kernels (BLP TCB Paradigm) ● ● All security policy enforcement was performed by the security kernel As security policy became more complex: ➔ ➔ ➔ Code grew in security kernel Certification efforts become unmanageable Evaluatability of kernel decreased Maintainability of kernel code decreased Policy decisions were based upon incomplete/unauthenticated information High-cost, Protracted Developments November 13, 2002 8

MILS Separation Kernel Architecture (Information Flow Paradigm) ● ● MILS Architecture utilizes a Layered Approach to Security Software Decomposed into 3 Distinct Layers (John Rushby, Ph. D): The Micro (Separation) kernel ➔ The Middleware (e. g. ORB, System Control) ➔ The (User) Application Software ➔ ● ● ● Separation Kernel creates separate process spaces (Partitions) and provides secure transfer of control between processes (Pipes) Middleware Security Policy Enforcement provides for Application Component Creation and Secure Inter-Object Message Flow Applications provide Application specific Security Functions (e. g. , Firewalls, Crypto Services) November 13, 2002 9

Separation Kernel Architecture Attributes ● Micro Kernel / Middleware / Application Security Policy Enforcement Mechanisms are: ➔ ➔ ● ● ● Non-bypassable Always invoked Tamper-Proof Evaluatable Each layer enables the next higher layer security services Simplifies the security argument that untrusted code cannot tamper/bypass security enforcement mechanisms Security Policy Components: Information Flow, Data Isolation, Periods Processing, Damage Limitation November 13, 2002 10

Medium Assurance Separation Kernel Application Partitions Supervisor Mode VM 1 VM 2 . . . VMN User Mode RTOS Monolithic Kernel MMU, Exceptions Interrupts November 13, 2002 Processor 11

MILS Separation Kernel Security (High Assurance) ● High Assurance Kernel ➔ ➔ ● ● Remove non-essential services, e. g. , Device Drivers Develop Formal Methods Artifacts Separation Kernel Functionality Time and Space Partitioning ➔ Data Isolation, via, MMU ➔ Intra-processor Information Flow ➔ Periods Processing ➔ Minimum interrupt servicing ➔ Semaphores ➔ Timers And nothing else!!! ➔ November 13, 2002 ● Middleware Functionality ➔ Inter-processor Information Flow ➔ Virtual Device Drivers ➔ Marshalling and Proxy Service ➔ Network QOS, e. g. , TCP / UDP Middleware Security Policy ➔ End to End Information Flow ➢ e. g. , Rule Based BLP ➔ End to End Data Isolation ➢ e. g. , IPSEC/SSL Encryption ➔ End to End Periods Processing ➔ End to End Damage Limitation 12

High Assurance MILS Architecture Application Partitions S TS S, TS. . . (MSL) (MLS) CORBA / MSL - Multi Single Level Middleware MLS - Multi Level Secure (MILS) MILS - Multiple Independent Levels of Security RTOS Micro Kernel (MILS) User Mode ? Supervisor Mode MMU, Inter-Partition Communications Interrupts November 13, 2002 Processor 13

Why CORBA Security Is Not Used ● ● ● ● Commercially available CORBA security implementations place CORBASEC with the ORBs reside within the application components’ process spaces Security mechanisms easily modified by other software objects within process space (e. g. application) Security mechanisms easily bypassable, security becomes an application option Security services more of a collection of security objects than a security architecture CORBASEC implementations too large to evaluate Non-security issues related to message latency November 13, 2002 14

Application Creation Sys Cntl HMI Reqt Appl Guard Init Sec Mgr Comp A Comp B Load Appl Comp A ACK Comp A (Obj. Ref A) Load Appl Comp B Create Comp A ACK Comp A (Obj. Ref A) Create Comp B ACK Comp B (Obj. Ref B) Load Appl ACL Load Local ACL November 13, 2002 15

Inter-Partition Flow Control Kernel under control of Node Security Manager Intra-partition flow control under the control of Separation Kernel ● ● ➔ ➔ ➔ Process requests a socket Kernel validates request Kernel creates 2 -part socket ➢ ➢ ➔ ➔ Data Routing read only Data shared by process and transport stack ● ● November 13, 2002 Kernel checks permissions with Security Manager from both from client side and server side upon connect request Kernel writes routing to socket (Transport Guard) after permission check 16

MLS Transition ● ● ● Support Bell and La. Padula security policy (writeups and TRUSTED write-downs permitted) Implicit Address Space Labels / Explicit PDU Labels Full MLS uses the same architecture as MILS, but requires multi-level: User Ports ➔ Transports ➔ Trusted Applications ➔ ● Each system object/subject must support a range of security levels November 13, 2002 17

Confines Malicious Code ● With MILS Separation Kernel Architecture we know ➔ ➔ ➔ ● ● Where inputs came from for each object Where outputs are going for each object Data for each object remains private Impossible to TEST security system for all possible user applications In addition to testing, high-assurance kernel requires ➔ ➔ ➔ Rigorous design methods Proven software engineering process methods ➢ CMM Level 3 Rigorous use of mathematics November 13, 2002 18

Other Advantages of MILS ● ● Each layer may be evaluated separately without impact to the evaluation of the other layers. Higher assurance kernels may be incorporated without impact to evaluation of other layers Supports new security enforcement mechanisms at the application level without impacting other enforcement mechanisms High Assurance Applications: ➔ ➔ ➔ Can be developed and maintained Can be evaluated Become a FULL Partner in Enforcing Complex Security Policies November 13, 2002 19

MILS Roadmap Single Channel Legacy Systems November 13, 2002 20

MILS Roadmap Supports MILS via Physical Separation November 13, 2002 21

MILS Roadmap MILS Crypto Engine and Embedded OE BLACK Modem MILS Crypto Engine Modem MLS Crypto Apps TS Channel MILS Middleware S Channel MILS RTOS C Channel Microprocessor U Channel RED November 13, 2002 22

TS Partition AS 2 HJ P 1 AS 3 AB AS 1 ASM MILS Roadmap S Partition TS/S/U AS 4 TG P 1 AS 5 CF AS 1 ASM NIU TS S U AB CF DG HJ TG KE TS S U . . . U Partition AS 6 DG P 3 AS 7 KE AS 1 ASM MILS Control Partition Clearance P 1 P 2 P 3 November 13, 2002 TS S U ASM Input Control App. Label Partition Buffer AB CF DG … P 1 P 2 P 3 … &AB &CF &DG … ASM Output Control App. Label Partition Buffer &HJ P 1 HJ &TG P 2 TG &KE P 3 KE … … … 23

Partners ● ● ➔ Hardware Based Kernel ➔ AAMP 7 Rockwell-Collins Software Based Kernel ➔ Integrity-178 ➔ Lynux. OS ➔ Vx. Works Middleware ➔ ORBexpress November 13, 2002 Green Hills Software Lynux. Works Wind. River Objective Interface 24

Certification Documentation - Part 1 (MILS Artifacts) ● ● Protection Profile / Security Target Descriptive and Formal Security Policy Model ➔ ● ● Information Flow / Data Isolation / Periods Processing / Damage Limitation Descriptive and Formal Top Level Model / Specification Descriptive and Formal Low Level Model / Specification Descriptive and Formal Correspondence Report ➔ (Policy <---> Top <---> Low) Validation Report (Code to Specification) ➔ (Low Level Model <---> Implementation) November 13, 2002 25

Certification Documentation - Part 2 ● Maintenance of Assurance Plan ➔ ➔ ● ● ● ● NOFORN Access to CM System, RTOS Kernel, CORBA Manager CMM Level 3, DO-178 B Architectural Description Configuration Management Plan Covert Channel Analysis Report Security Features User Guide Philosophy of Protection Reliability Test Plan and Report Vulnerability Report (Classified, hopefully empty) November 13, 2002 26

Additional Certification Issues ● ● ● ➔ ➔ ➔ Trusted Distribution (Software Signature Verification) Trusted Initialization (RT Software Signature Verification, . . . ) Counter High Assurance Threat ➔ (1 insider & multiple outsiders) Software Signature (Deeply Embedded Public Key) Trusted Path (Authenticated HMI) Elimination of Super User (Software Issue) Controlled Interfaces Fail Safe, Damage Limitation (see also Trusted Initialization) November 13, 2002 27

Summary ● ● High assurance, multi-level systems are needed by the war-fighter DOD desires Multi-Level Systems in the Near-Future for the War-Fighter The separation kernel provides the lowest risk, quickest development time to provide high assurance MILS systems What can we do to make this happen? November 13, 2002 28