Secure Cross
Domain Communication (CDC) has been a critical concern in the recent past
particularly for the US Intelligence Community. Secure protocols for CDC has drawn
significant thrust from the intelligence community, industry, and academia
alike. Yet, coordination of activities between different (security) domains
remains a crucial challenge. Cross-domain data flows often require extensive
human reviews that are both time-consuming and error-prone. A partial survey of
current cross-domain security solutions revealed, among others, the following
issues:
- From the perspective of mission applications design, current CDC solutions require mission application programs to design and implement their own individual solutions around particular guard designs, resulting in vendor lock-ins. Developers have to learn guard interfaces, design architectures for interacting with them, incorporate CDC concepts into their specific applications, and manage accreditation for the resulting systems
- From the perspective of enterprise security infrastructure, guard products are typically transport oriented. This would require the guard to have the highest security privilege in order to be able inspect inform passing through it, contrary to best security practices. Furthermore, this implies same security terminology is required for both domains connected by the guard. For example, the same set of security labels have to be used. Such an assumption is not always true, especially when the information exchange across organizational boundaries. Last but not least, associating the guards with the links often fails to scale as the number of security domains increase, such as in the interagency cases, commonly known as the “n squared problem”.
- CDC guards often have limited configurability and API. The result will be a proliferation of locked-in stacks that will reduce purchasing flexibility and increase program development expense.
In addition, current CDC solutions require excessive
amount of human intervention, mainly due to the lack of a standard and flexible
framework for describing information. Many guards use dirty word list or some
rudimentary rules expressed in XSLT to filter information passing through them.
These techniques often fail to take into account the context of messages and meaning
of the words, leading to false positives or negatives. Human review is often
required to adjudicate ambiguities, leading to critical delays in the workflow.
Most of the CDC solutions today focus on one or more
particular aspects of cross-domain communications, for example, filtering
information in web (HTTP) traffic. To
understand the multi-faceted nature of cross domain communication, we need to a
conceptual framework in which interactions among CDC participants can be
abstracted out, forming the basis for protocols.
To highlight the issues that the reference architecture
needs to address, let us consider the simple use case shown above. In this
example,
- A user submits a classified travel request through a Mission Planning System (MPS).
- The MPS then sends a web service request to a Financial Management System (FMS), which is part of an unclassified network/domain.
- When the classified travel request passes through the guard, all classified information (itinerary) in the request needs to be redacted, allowing the rest of the message to pass as is.
- The FMS sends an email via SMTP to the mail server for the approver’s review. Since the mail server is on the classified network/domain, the guard needs to restore the redacted content for the approver to see the request in its entirety.
- The approver accesses the mail server from his/her classified workstation.
In reality, the workflow is likely to be more
complex. But, the simplified example above is sufficient and suitable for our
discussions. Consider the following questions raised by this use case.
- How is the guard included in the workflow?
a. If the guard is transparent to the mission
application, then does the application need to be notified in case the guard
blocks the message?
b. If, on the other hand, the guard is an active
participant in the workflow, would the guard “proxy” the target system by
exposing the same web service interface? In other words, should the mission
application address the request to the guard, instead of the financial
management system?
c. In (b), can the guard hide the identity of the
source/target systems for security reasons – For instance, can the guard
certify to the mission that the message is delivered to the proper target
system, without revealing the identity of the system?
d. Can the guard act as the information brokers across
domain as well? For instance, can the guard locate the appropriate recipient in
the correct domain for a particular message?
a. Is there a standard vocabulary that the guards and
mission application share to describe the information, the actors, the security
labels, and the security actions?
a. Or should the guard just monitor TCP/IP packets
without knowledge of application level protocols?
b.
If there are two
different guards, how do they coordinate with each other? In the above example,
how would a Web Service guard and an email guard coordinate to restore the
redacted information for the approver?
A reference architecture will not provide standard
answers to these questions. Rather, it will delineate responsibilities among
various CDC participants, and describe how they interact with one another. As
such, it will allow design choices like these to be made by the designers
and/or architects of – infrastructure, mission application(s), guard products, etc.,
based on their unique business needs.
CDC is a shared responsibility between the CDC
infrastructure and the mission application taking advantage of such an
infrastructure. For the purpose of protocol design, we are primarily concerned
with the infrastructure aspects of CDC. That is, standardized interfaces for
products (hardware or software) whose primary responsibility is to facilitate
secure cross-domain communications. A security guard is one such product, and
perhaps the most important.
As shown in the diagram, the reference architecture
needs to address the following concerns-
- Architecture Concerns: We believe it is reasonable to assume that mission applications are aware of the fact that they interact with system in other security domains, and therefore, the presence of security guards. It is the application’s responsibility to properly handle the cases where a message is rejected by the guard for security reasons.
- Policy Concerns: Security attributes for application-specific messages need to be defined so that proper security policies can be enforced by the infrastructure. We consider this an application concern in the sense that the security attributes are associated with individual data elements processed by the application, even though it is likely that a security administrator attaches these security attributes at runtime.
- Network Concerns: Specifically, the reference architecture needs to address the concerns of how the guard(s) interacts with the network. Any protocol needs to address how CDC-specific communications (messages between the application and the guard as well as messages between the guards) are carried in the network protocols. For example, how such messages are carried in a SOAP message for web services-based communications or in the HTTP header for web traffic. Doing so could require extensions to existing protocols so that security-specific information could be added to the messages. A particular aspect of integrating guard with network protocol is a mechanism to handle end-to-end encryption and authentication. For example, if a mission application encrypts payload using WS-Security, the guard would not be able inspect the message content unless the message is addressed to the guard (instead of the target system) and encrypted using the guard’s keys.
- Information Concerns: Specifically, how guards interact with information floating through them. We believe there need to be a convention for determining how application-specific messages are interpreted and acted upon by the guards, while the goal of enabling: 1) Automation, so that time-consuming and error-prone human reviews can be reduced and, in some cases, eliminated; 2) Interoperability, so that CDC solutions from multiple vendors can work together seamlessly, and vendor lock-ins is avoided.
- Workflow Concerns: Specifically, how guards interact with other participants of the workflow, i.e. mission application and other guards. Compared to the others, there has not been extensive research on this aspect of CDC. Much less discussion about how existing standards such as Business Process Modeling Notation (BPMN) languages can be leveraged for CDC. One important workflow consideration is whether or not the guard is an active participant in the workflow, and if so, how does the guard act as a service intermediary.
