Abstract
The Unified Cross Domain Management Office (UCDMO) states that its mission is to provide coordination and oversight for the cross domain community’s vision of “secur[ing] cross domain access to and sharing of timely and trusted information, creating a seamless Enterprise that enables decision advantage.” The UCDMO defines three types of cross domain solution (CDS) — transfer, access and multi-level — to satisfy this vision.
The transfer CDS, or guard, moves information securely between software applications running in different information security domains. Since the guard must approve all information flows between domains, it is traditionally deployed on a standalone computer host that provides the only physical link between the domains’ networks. This deployment strategy ensures that the guard cannot be bypassed. Unfortunately, as the demand for sharing increases, this strategy can prove costly. Data centers, for example, may charge more for custom guard hardware that cannot be reallocated easily for other uses.
To address rising deployment costs, the UCDMO has proposed to implement the guard as a software service that can be installed and managed from a central location. The guard would be available via the network to any cross domain application that requires it. It may even be deployed on a virtual machine (VM) in a data center. Unfortunately, this deployment strategy also has shortcomings. For example, in tactical environments, access to the network — and thus to a remotely hosted guard service — can be unreliable. The tactical user needs to operate through network loss, so this user would benefit from a local guard deployed on a small hardware footprint for a resource-constrained environment. In other situations, a local guard may be required. A network management application, for example, may use a guard to control many networks at different security levels.In this case, network availability depends on the availability of the guard rather than the reverse. In summary, these use cases encourage deploying the guard as close as possible to its cross domain applications.
In this paper, we introduce XEBHRA (Xen-Based, Host-Resident, Assurance), a layered assurance architecture for virtualized cross domain information sharing. XEBHRA hosts the guard and its domain applications as separate VMs on a trustworthy virtual machine monitor (VMM). XEBHRA joins the domain application VMs to the guard VM using virtual networks, and XEBHRA configures those virtual networks so that the guard VM cannot be bypassed.
The XEBHRA architecture enables the user to not only interact with each domain like an access CDS but also to initiate approved transfers between domains using the local guard. XEBHRA achieves a size, weight and power (SWAP) reduction of (n+ 1)-to-1 for n domains and a single guard. XEBHRA eliminates physical network disruption as an impediment to local information sharing and, since the guard is accessed only from the domain application VMs, it also reduces the exposure of the guard VM to attacks from the physical network.