1. Cross-Domain Security Reference
Architecture
Foundation for Cross Domain Security Protocols
Wen Zhu, Dr. Lowell Vizenor Dr. Avinash Srinivasan

2. 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

3. 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

4. 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
3
4

5. 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

6. Application Aspects
Architecture
Concerns
Policy
Concerns
Infrastructure Aspects
Network
Concerns
Information
Concerns
Workflow
Concerns
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

7. 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

8. 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 Domain
Mission
Application
Mission
Application
Mission
Application
Mission
Application
Mission
ApplicationMission
Application
Mission
Application
Mission
Application
Mission
Application
Inter-guard
Security
Coordination
Security
Monitor
Security
GuardSecurity
Guard
Security
Guard
Security
Administrator
Security
Monitor
Enterprise
Security System

9. 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 today
Security Domain Security Domain
Adapter
Adapter

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

11. Opportunity for Standardizing Interactions –
CDS Protocol Candidates
Security Domain
Security Domain
Security Domain
Mission
Applicatio
n
Mission
Applicatio
n
Mission
Applicatio
n
Mission
Applicatio
n
Mission
Applicatio
n
Mission
Applicatio
n
Mission
Applicatio
n
Mission
Applicatio
n Mission
Applicatio
n
Inter-guard Security
Coordination
Security
Monitor
Security
GuardSecurity
Guard
Security
Guard
Security
Administrato
r
Security
Monitor
Enterprise
Security
System
Candidate 1:
CDS Application
Interface
Candidate 2:
Inter-guard
Coordination
Candidate 3:
Security Monitor
Interface
Candidate 4:
CDS Ontology

12. 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

13. 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

14. Putting It Together