Secure Middleware

Architecture

Dr. Jim Alves-Foss

Paul Oman
Carol Taylor
University of Idaho
University of Idaho Tasks
♦ Support development of minimal subset of
CORBA to support secure MILS
architecture (MILS-CORBA)
♦ Conduct threat analysis for MILS-CORBA
♦ Support development of protection profile
for MILS CORBA
Intent of MILS-CORBA Protection
Profile
♦ We need to protect our computer systems
from faults and malicious attacks
♦ We need to reduce the design and
verification efforts for secure systems
♦ We need a standard against which we can
measure security/safety of system
Wrong Button!!
Protection Profile Will
♦ Discuss Threats
♦ Discuss Environmental Assumptions
♦ Discuss Required Services of Underlying
Layer
♦ Discuss
Embedded Systems and CORBA
♦ We see three main objectives related to
MILS-CORBA
– Management of communication over the
system bus/network
– Management of communication between
partitions running at different security
classifications.
– Process migration and any other dynamic
changes to the mapping of processes to
partitions and partitions to devices.
 MILS - Multiple Independent Levels of Security
High Assurance MSL - Multi Single Level
MILS Architecture MLS - Multi Level Secure

Application
Partitions S TS S,TS
...
(MSL) (MSL) (MLS)

CORBA CORBA CORBA /

Middleware Middleware
?
Middleware

User Mode
(MILS) (MILS) (MILS)
RTOS RTOS RTOS RTOS
Services Services Services Services

RTOS Micro Kernel (MILS)

Supervisor Mode
MMU, Inter-Partition
Communications Processor
Interrupts
Management on inter-device
communication
♦ There is a need for a Trusted Network
Interface Unit. (TNIU)
– Labels messages correctly
– Accepts and transmits only authorized
messages from the host device
– Filters out messages to the host device to those
that satisfy the security policy
– Can be implemented in a number of ways and
proven secure.
Approaches to MLS System
Architectures
♦ There are three approaches to an MLS
systems architecture
– High-water mark – not true MLS, and
unacceptable
– Enclave approach
– Communicating Enclaves
The Enclave Approach
•Each enclave operates at
Enclave 2
Enclave 1 a single level of security.
•No communication
permitted between
enclaves
•Each enclave could
support independent
Enclave 3 Enclave 4 CORBA system
Communicating Enclaves
•Each enclave operates at
Enclave 2
Enclave 1 a single level of security.
•Limited communication
MLS permitted between
enclaves
•Each enclave could
support independent
Enclave 3 Enclave 4 CORBA system
•Communication between
enclaves must be
managed securely.
•There may be true MLS
partitions not within any
enclave.
Inter-enclave communication
♦ We envision three approaches to inter-enclave
communication
– Independent guards/gateways
• There exists a CORBA buffer for every partition/object that
receives information from a lower-level partition. The buffer
will ensure one-way information flow.
– Enclave sentries/firewalls
• There exists a limited set of “trusted” partitions within an
enclave. These act as proxy servers for the actual partitions
within the enclave. They strictly enforce the information flow
policy.
– True MLS
• The true MLS object/partition must be trusted to process and
label information correctly. A ORB interface for such a
process must maintain that labeling.