SECURITY ISSUES IN HIGH LEVEL ARCHITECTURE BASED DISTRIBUTED SIMULATION

1
SECURITY ISSUESIN HIGH LEVEL ARCHITECTUREBASED
DISTRIBUTED SIMULATION

• Asa Elkins
• Jeffery W. Wilson
• Denis Gracanin

2
A Paper Presentation byRebekah BlackonApril
17, 2003Taken from the 2001Winter Simulation
Conference
3
Outline

• HLA
• Information Assurance
• Scenarios
• Filsinger and Lubbes Approach
• Bieber et al. Approach
• IPSec Protocol
• Results

4
Why Simulate?

• Support development and conduct of operator
  training
• Explore ways in which emerging systems can better
  work together
• Early detection and correction of deficiencies

5
High Level Architecture

• Purpose to substantially improve software
  interoperability or reuse among DoD simulations
• Combines simulations into a logical grouping,
  called a federation

6
Information Assurance

• Simulation may involve national security or
  proprietary interests
• Need to guard simulation details against
  unauthorized access
• Goal to obtain adequate performance from the RTI
  while using standard Internet protocols

7
Scenario 1 Distributed Development
8
Scenario 2 Distributed Test and Evaluation
Different levels of classification Need-to-know
access Releasibility
9
Scenario 3 Commercial Industrial Security
10
Filsinger and Lubbes Approach

• HLA must allow processing of Multi-Level Secure
  (MLS) data among federates with users that do not
  have all the appropriate security clearances
• Information must be prevented from leaking from
  high level to low level of security
• HLA must support processes that are capable of
  protecting information within a security
  classification and support processes that can be
  trusted to downgrade (sanitize) data
• HLA must support security mechanisms to allow
  object ownership and object attributes to be
  safely read or updated by any simulation with a
  federation
• HLA must support enforcement of mandatory
  confidentiality, integrity, and need-to-know
  policies
• Simulations must be reusable at different
  security levels at different times in different
  federations

11
Solutions

• Single security level
• (does NOT support multiple security principles or
  domains or different classification levels)
• Multiple single security levels with security
  guards and trusted agents
• (requires proper cryptographic protections)
• Multiple MLS security domains
• (requires MLS hosts and an MLS supported RTI)

12
Bieber et al. Approach

• Focus on application of security to HLA RTI in a
  commercial sense and deals with confidentiality
  of technology

13
3 Potential Threats

• Communications between local RTIA (Ambassador)
  processes and the RTIG (Group)
• Leak of sensitive object properties via supported
  RTI processes, i.e. broadcasting too widely the
  values of the sensitive object properties
• Direct request of sensitive object properties by
  unauthorized, but supported, federate processes

14
Solutions

• Network isolation -gt cryptography
• RTI isolation -gt security filter
• Require the federates in the same security domain
  to be hosted by the same machine

15
Internet Protocol Security Protocol (IPSec)

• Interoperable with both IPv4 and IPv6
• Provides data privacy, integrity, and
  authenticity for network traffic
• Uses an on-demand security negotiation and key
  management service defined as Internet Key
  Exchange (IKE)

16
IPSec

• Communications between simulations and the RTI
  need to be protected at a level commensurate with
  the security level of the data.
• Requests for data require a check of the
  requester against the data.

17
Experimental Results

• RTI can support IPSec
• Minimal negative impact on performance
• (increase of simulation time lt10)

18
(No Transcript)
19
Results
20
(No Transcript)
21
(No Transcript)
22
Limitations of IPSec

• Does not ensure physical security of host machine
• Relies on external authentication and encryption
  protocols
• Affects performance as federation size increases
• Multiple security levels within machines allows
  classification sharing

23
THE END.