Download - Cross domain security reference architecture
Cross-Domain Security Reference Architecture
Foundation for Cross Domain Security Protocols
Wen Zhu, Dr. Lowell Vizenor Dr. Avinash Srinivasan
Agenda Survey of Current CDS Solutions Example Use Case CDS Reference Architecture CDS Security Ontology CDS Protocol
[1] Source: http://yellowhouseassociates.net/download/YHA_CDAA_WP.pdf
Survey of Current Cross Domain Security Solutions (CDS) From the perspective of mission applications design [1]:
Require mission application programs to design and implement their own individual solutions Unavoidable vendor lock-in
Limit CDS use to simple cases without workflows or full-duplex architectures Lack of flexibility required by the business
From the perspective of enterprise security infrastructure CDS is commonly associated with the links between domains, instead of
individual domains Require the highest security level, contrary to best practice Implies same security terminology for both domains, which is not always practical Failed to scale as the number of security domains increase as in interagency cases (n
square problem) CDS vendors define the mission application interfaces [1]
Limited configurability and API Lack of protocol for coordination among guards
Unavoidable vendor lock-in
From the perspective of effectiveness and performance Lack of a standard and flexible framework for describing information
Require excessive amount of human intervention
[1] Source: http://yellowhouseassociates.net/download/YHA_CDAA_WP.pdf
Example Use Case: Approval of Classified Travel
1. User submits a classified travel request through a mission planning system. 2. The system sends a web service request to a financial management system, which, in this case,
sits in a unclassified network. As the request passes through the guard, classified information (itinerary) needs to be redacted, while the rest of the message is allowed to pass.
3. The financial management sends an email via SMTP to the mail server for the approver. Since the mail server is on the classified side, the guard needs to restore the redacted content for the approver to see.
4. The approver accesses the mail server from her classified workstation.5. In reality, the workflow is likely to be more complex. But this is sufficient for our discussion.
Unclassified NetworkClassified Network
Financial Management
System
Guard
Mission Planning System
Mail Server
Itinerary (S)
Cost (U)1
2
34
Issues Highlighted by Use Case
1. How is the guard inserted into the work flow?1. If guard is transparent – how is the application notified of failures?2. If guard is an active participant – Does the guard “proxy” the target system by exposing the same web
service interface? And if so, how?3. Can the guard hide the identity of the source/target systems for security reasons – For example, I can
certified to you the message is delivered to the property system, but I cannot tell you which system it is.
4. Can the guard act as the information brokers across domain as well? For example, can the guard locate the right recipient in the right domain for a particular message?
2. How does the guard determine which content to pass? And the redact action?1. Is there a standard vocabulary to describe the information, the actors, the security labels, the security
actions, etc?2. Does everyone have to agree on a single set of security policies?
3. Is a single guard monitoring both Web Service and SMTP traffic on the network? Or it just monitors TCP/IP pockets?
1. How does the guard inspect the protocol traffic?2. If there are two different guards, how do they coordinate. For example, restore the redacted
information for the approver?
Unclassified NetworkClassified Network
Financial Management
System
Guard
Mission Planning System
Mail Server
Itinerary (S)
Cost (U)
1
2
3
Application Aspects
Architecture Concerns
Policy Concerns
Infrastructure Aspects
Network Concerns
Information Concerns
WorkflowConcerns
Framework
Context
Constraints
Transport binding
Information Encoding
CDS Reference Architecture
The reference architect will provide A framework for discussing multi-faceted concerns of CDS A context in which interactions among CDS participants can be
abstracted out, forming the basis for protocols
CDS Concerns Infrastructure Aspects
Network Concerns: How guards interact with the network How CDS-specific communications (with and between the guards) relates to the
network protocol stack Runtime consideration: End-to-End Encryption and Authentication
SSL/WS-Security: signature by guards?
Information Concerns: How guards interact with information floating through them How application-specific communications is described and acted upon by the guards Design/Runtime considerations
Ontology framework for security concepts related to Ontology framework for coordination among a guards
Workflow Concerns: How guards interact with other participants of the work flow (i.e. mission application and other guards) Is a guard an active participants of the application workflow Design-time considerations:
Extension of BPMN/BPEL to describe the guards and domains? Automated BPMN refactoring to insert the guard into a work flow model – MDA Story?
Runtime consideration: WS-Addressing: Guard as an intermediary? WSDL: Guard as a web service endpoint?
Application Aspects Architecture Concerns: How does the introduction of guards impact the
application architecture? Policy Concerns: What is the security requirements for information processed
by the application
Most Mature:Considered by most guards today
Outside the scope of our discussion
Limited Capabilities available today: dirty words, XSLT, etc.Not addressed by most guards. Transparent in theory. But not in practice
CDS Participants Security Domain
Implies a consistent a security vocabulary for users (human and systems), activities and information A security domain MAY have one or more Security Guards.
Security Monitor (Optional) Defines consistent security policies for communication with other domains using the security vocabulary. A Security Monitor MAY act as Policy Decision Point for the domain. A Security Monitor MAY communicate with the Security Guard at runtime.
Mission Application Associate mission-specific concepts with the security vocabulary.
Security Guard Enforces security policy defined by the mission application. MAY act a Policy Enforcement Point for the
domain. A Security Guard monitors network traffic for one or more Network Protocols. A Security Guard MAY coordinate with other guards for this and other domains.
Security Domain
Security Domain
Security DomainMission
Application Mission
Application
Mission Applicatio
n
Mission Applicatio
n
Mission Applicatio
nMission
Application
Mission Applicatio
n
Mission Applicatio
n Mission Applicatio
n
Inter-guard Security
Coordination
Security
Monitor
Security
GuardSecurit
y Guard
Security
Guard
Security Administrato
r
Security
Monitor
Enterprise Security System
Design Decision: Associating Guards with Security Domains
A Guard SHOULD be associated with a single Domain. Rational:
Security: Guard operates at the same security level as the associated Domain without
unnecessary privilege The same security monitor (system and human operator) manages both the domain
and the guard, avoiding policy conflicts and duplication Scalability:
Avoid n square problem in a multi domain environment
Implication: Guards needs to trust each other without revealing mission information each
other Identify: Guards SHOULD require mutual authentication Trust: Mutual trust is established out of band – may be through a white list
Migration considerations for current link-based CDS guard product Adapters may be developed In reality, the adapter functionality is implemented with the mission
applications todaySecurity Domain Security Domain
Adapte
r
Adapte
r
Design Decision: Guards as Active Participants in Workflow Mission applications MUST be aware of the guards and communicate explicitly with the guard
Rational: Need a notification mechanism in case a message is blocked by the guard for the security reasons. So that the
mission application may take appropriate action. End-to-end encryption may prevent the guard from inspecting the message if the message is not explicitly
addressed to the guard Covert Channels will be impossible if the guard actively intercept and forward the message.
Implication: The guard MAY have expose the same interface (WSDL for example) as the invocation target
A Guard MAY provide additional information management services to mission applications Cross-domain service discovery Proxy for service provider Proxy for service consumer
BPMN/BPEL could be extended to model the guards as part of the work flow Model Driven Architecture® (MDA) approach would be leverage to automatically transform a work
model to include the guard.
Opportunity for Standardizing Interactions – CDS Protocol Candidates
Security Domain
Security Domain
Security Domain
Mission Applicati
onMission Applicati
on
Mission Applicati
on
Mission Applicati
on
Mission Applicati
onMission Applicati
on
Mission Applicati
on
Mission Applicati
on Mission Applicati
on
Inter-guard Security Coordination
Security
Monitor
Security GuardSecurity
Guard
Security Guard
Security Administrat
or
Security
Monitor
Enterprise Security System
Candidate 1:CDS Application Interface
Candidate 2:Inter-guard Coordination
Candidate 3:Security Monitor Interface
Candidate 4:CDS Ontology
CDS Application Interface: Abstract
<<interface>>Security Notification Receiver
Security GuardMission
Application
<<interface>>Service Proxy Interface
+ get service end point
<<interface>>Information Discovery Interface
+ get security requirement+ get capabilities
<<interface>>Operational
Optional: Allow application to receive notices from guard
Optional: Allow application to determine relevant security policy
Required: Allow messages to pass at runtime
Required: Proxy a web service endpoint in another domain
CDS Application Interface: WS-* Binding for Operational Message Passing (Notional)
<S:Envelope xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"> <S:Header> <wsa:To>http://fabrikam123.example/financial </wsa:To> <wsa:Action>http://fabrikam123.example/SubmitPO</wsa:Action> </S:Header> <S:Body> <Itinarary/> <Cost/> </S:Body> </S:Envelope>
<wsdl>
<interface>
<operation>
<input>
… …
<wsdl>
:Service
:Information Concept
:Security Attributes
OntologyMessage
Metadata
Message addressed to the guard within the same domain
The target system in another domain
Payload definitions are linked to information concepts via SAWSDL Annotation
Concepts are further associated with security attributes
Putting It Together