november 13, 2002 1 deeply embedded high assurance (multiple independent levels of security/safety)...
TRANSCRIPT
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
Jahn A. Luke Air Force Research Laboratory Luke Jahn A Civ AFRL/IFTA
W. Mark VanfleetDepartment of Defence
Lee MacLearnBoeing
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
Matthew M. Wilding, PhDRockwell Collins
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
November 13, 2002 11
Medium AssuranceSeparation Kernel
VM1
Processor
VM2 VMN
Supervisor Mode
MMU, Exceptions
Interrupts
...Application
Partitions
RTOS Monolithic Kernel
User Mode
November 13, 2002 12
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
November 13, 2002 13
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 ?
November 13, 2002 14
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
November 13, 2002 15
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
November 13, 2002 16
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
November 13, 2002 17
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
November 13, 2002 18
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 19
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 20
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
November 13, 2002 21
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
November 13, 2002 22
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
November 13, 2002 23
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
November 13, 2002 24
Partners
●Hardware Based Kernel➔AAMP7 Rockwell-Collins
●Software Based Kernel➔Integrity-178 Green Hills Software➔LynuxOS LynuxWorks➔VxWorks WindRiver
➔Middleware➔ORBexpress Objective Interface
November 13, 2002 25
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 26
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)
November 13, 2002 27
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 28
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?