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