November 13, 2002 1 Deeply Embedded High Assurance (Multiple Independent Levels of Security/Safety)...

November 13, 2002 1

Deeply EmbeddedHigh Assurance

(Multiple Independent Levels of Security/Safety)MILS Architecture

Dr. Ben A. Calloni, P.E.Lockheed Martin Aeronautics Company

[email protected]

Jahn A. Luke Air Force Research Laboratory Luke Jahn A Civ AFRL/IFTA

W. Mark VanfleetDepartment of Defence

[email protected]

Lee MacLearnBoeing

[email protected]

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.

Dipak PatelRockwell Collins

[email protected]

Matthew M. Wilding, PhDRockwell Collins

[email protected]

November 13, 2002 2

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 3

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 areNon-Bypassable,

Always Invoked,

Tamper-proof, and

Evaluatable

November 13, 2002 4

MILS Security Architecture Definitions● Multiple Independent Levels of Security (MILS)

➔ 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● System High

➔ Valid Clearance for all Information➔ Valid Need To Know for some Information

● Multi-Level Security (MLS)➔ Multiple Clearance Levels for Information➔ Bell and LaPadula➔ Tagging of Data and System Objects

November 13, 2002 5

Relationship between System Modes and Assurance Levels

Common Criteria➔EAL3 (C-2 LOT)➔EAL4 (B-1 LOT)

➔EAL5 (B-2 LOT) *➔EAL6 (B-3 LOT) *➔EAL7 (A-1 LOT) *

➢MILS/MLS Accreditation➢System High➢System High w/ Type Separation

(SECRET NOFORN / SECRET NATO)➢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 MonitorAssuming a Secure Development Environment

November 13, 2002 6

MILS Security Policy Application Example

D1

D2

D3

BSRV

RPM

E1

E2

E3

RS BV

BPM

Red Data Black Data

November 13, 2002 7

MILS Security Policy Application ExampleMILS Provides: Information Flow Data Isolation Periods Processing Damage Limitation

D1

D2

D3

BSRV

RPM

E1

E2

E3

RS BV

BPM

Red Data Black Data

November 13, 2002 8

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 9

MILS Separation Kernel Architecture(Information Flow Paradigm)

●MILS Architecture utilizes a Layered Approach to Security●Software Decomposed into 3 Distinct Layers (John Rushby, PhD):

➔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 10

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


Medium AssuranceSeparation Kernel

VM1

Processor

VM2 VMN

Supervisor Mode

MMU, Exceptions

Interrupts

...Application

Partitions

RTOS Monolithic Kernel

User Mode


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➔ TimersAnd nothing else!!!

● 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


S,TS

(MLS)

TS

(MSL)

S

(MSL)

CORBA

Middleware

(MILS)

High Assurance MILS Architecture

Processor

User M

ode

...Application

Partitions

CORBA

Middleware

(MILS)

CORBA /

Middleware

(MILS)

RTOS Micro Kernel (MILS)

Supervisor ModeMMU, Inter-Partition

CommunicationsInterrupts

MILS - Multiple Independent

Levels of Security

MSL - Multi Single Level

MLS - Multi Level Secure ?


Why CORBA Security Is Not Used

● Commercially available CORBA security implementations place CORBASEC with the ORB

● 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


Application Creation

HMISysCntl

GuardInit

SecMgr

CompA

CompB

ReqtAppl Load Appl Comp A

Create Comp AACK Comp A (ObjRef A)

ACK Comp A (ObjRef A)

Load Appl Comp BCreate Comp B

ACK Comp B (ObjRef B)ACK Comp B (ObjRef B)

Load Appl ACL

Load Local ACL


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

➔Routing read only➔Data shared by process

and transport stack

High AssuranceSeparation Kernel

Me

diu

mA

ss

ura

nc

eK

ern

el

Tra

ns

po

rtS

tac

k

Socket

ApplComp

A

Me

diu

mA

ss

ura

nc

eK

ern

el

Tra

ns

po

rtS

tac

k

Socket

ApplComp

B

Lo

ca

lS

ec

uri

tyM

an

ag

er

VM

Pa

rtit

ion

Sc

he

du

ler

VMbVM0 VMa

● 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


MLS Transition●Support Bell and LaPadula security policy (write-

ups 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


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


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


MILS RoadmapSingle Channel Legacy Systems

Modem

Modem

Modem

Modem

Channel A(Top Secret)

Red Processor

Channel C(Confidential)

Red Processor

Channel D(Unclassified)

Red Processor

Channel B(Secret)

Red Processor

Crypto Engine

Crypto Engine

Crypto Engine

Crypto Engie


MILS Roadmap Supports MILS via Physical Separation

Modem

Modem

Modem

Modem

Channel A(Top Secret)

Red Processor

Channel C(Confidential)

Red Processor

Channel D(Unclassified)

Red Processor

Channel B(Secret)

Red Processor

Crypto Engine

Crypto Engine

Crypto Engine

Crypto Engie

Need MILS SolutionHere!

Need MILS SolutionHere!

AND


MILS Roadmap MILS Crypto Engine and Embedded OE

Modem

Modem

Modem

Modem

TS Channel

S Channel

C Channel

U Channel

MLSCrypto Apps

MILSMiddleware

MILSRTOS

Microprocessor

MILSCryptoEngine

BLACK

RED


MILS Roadmap

Partition Clearance

P1P2P3

TSSU

App. Label Partition Buffer

ABCFDG…

P1P2P3…

&AB&CF&DG…

ASM Input ControlApp. Label Partition Buffer

HJTGKE…

P1P2P3…

&HJ&TG&KE…

ASM Output Control

TS PartitionAS2

AS3AS1

S PartitionAS4AS5AS1

U PartitionAS6AS7AS1 ASM

ASM

ASM

NIUTS/S/U

DG

AB

CF

AB CF DGTS S U

. . .HJ TG KE

TS S U

ASM MILS Control

. . .

KE

HJ

TG

P1

P1

P3


Partners

●Hardware Based Kernel➔AAMP7 Rockwell-Collins

●Software Based Kernel➔Integrity-178 Green Hills Software➔LynuxOS LynuxWorks➔VxWorks WindRiver

➔Middleware➔ORBexpress Objective Interface


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)


Certification Documentation - Part 2

● Maintenance of Assurance Plan➔NOFORN Access to CM System, RTOS Kernel, CORBA Manager➔CMM Level 3, DO-178B

● 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)


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)


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 1 Deeply Embedded High Assurance (Multiple Independent Levels of Security/Safety)...

Documents

Transcript of November 13, 2002 1 Deeply Embedded High Assurance (Multiple Independent Levels of Security/Safety)...