Open standards ease Multi-Level Security (MLS) systems integration
When sharing mission-critical information across networks, enforcing security policies can be surprisingly complex. Using a standards-based platform to manage secure communication channels helps overcome the technical challenges.
partition, applications or virtualized operating systems are run.
Most MILS systems also provide communication mechanisms that allow for controlled sharing of data between partitions. This can be used to allow many of the communication patterns found in a Bell-LaPadula architecture, for example, such as Read Down (read from lower classification level components or storage).
A MILS separation kernel allows applications that require high-assurance to run on the same system with medium- or low-security applications.
The problem of controlled information sharing
At the core of distributed MLS systems is the controlled sharing of information across networks. This often requires a guaranteed one-way flow of information that is different from most network or interprocess communication standards.
The one-way nature of these communication channels is a constant challenge when architecting MLS systems. Most communication mechanisms, even when only transferring data one way, have a mechanism for a reader to communicate back to the writer. This channel is used, for example, for reliability traffic, like positive and negative acknowledgement of packets in a reliability protocol. Without this backchannel, most existing software, including network protocols, will not work unmodified.
Some implementations have a limited backchannel that is controlled by a trusted component. For example, consider two processes communicating using a System V Message Queue on a Linux system. In this scenario, the operating system kernel provides limited information back to the writer, such as when the queue is full, allowing the transfer of status information without allowing the reader to communicate back arbitrary data. Arbitrary data communication paths, called overt channels, are the largest risk to the controlled sharing of information because they are intentionally enabled, high-bandwidth communication paths.
Even when overt information flows are removed in a communication channel, it is possible that unintentional (from the point of view of the system designer) information flows are still present. These flows, called covert channels, are typically present when the reader can influence reliability data provided to the writer. In the aforementioned example, the indication of queue status to the writer can be exploited to communicate a substantial amount of information over time.
Standards-based information sharing
Addressing the challenges of controlled information sharing in distributed MLS systems requires a standards-based approach that enforces security policies across different platforms (Figure 1). The Data Distribution Service for Real-time Systems (DDS) standard from the Object Management Group (OMG) is a compelling choice for managing distributed MLS communication channels. Its peer-to-peer, brokerless architecture directly supports MLS systems without compromising security controls or introducing special security components that must be trusted to maintain data separation.
The DDS standard provides anonymous publish/subscribe communication. To an application, DDS provides an interface for sending and receiving data while providing QoS such as reliable data transfer, sending historical data, and hot fail-over. In addition, the standard offers specific mechanisms that help implement controlled information sharing in MLS systems.
The most fundamental requirement of a distributed MLS system is that of ensuring the separation of data from different security levels across the network. The DDS standard provides a mechanism, called Domains, that effectively supports the separation requirement of these systems and gives system designers a powerful tool to meet this particular constraint. DDS Domains represent logical, isolated, communication networks. Multiple applications running on the same set of hosts in different DDS Domains are isolated from each other (even if they are on the same machine). Application processes belonging to different DDS Domains will never exchange data, including both user and meta-data. Because this method is for systems with no cross-domain requirements, backchannel traffic is not an issue.
For distributed MLS systems, providing mission-critical information often involves making data at different security classification levels available on the network across security domains. The DDS standard provides a QoS model that enables system developers to control the behavior of communication protocols. If backchannel traffic is not allowed, the developer can configure DDS to use a best-effort delivery protocol, which does not return acknowledgements. This way, the system accommodates one-way, low-to-high data flow that would allow for the implementation of Read/Write at level capabilities as well as Read Down/Write Up capabilities.
Secure bidirectional information sharing
In distributed MLS systems, fully bidirectional transfer of information between security levels often involves the use of a Cross Domain Solution (CDS). A CDS can run in one of two modes:
- Low-to-high reliable transport – transfer of user data from the lower security level to the higher security level with a transfer of only reliability-protocol traffic, including positive and negative acknowledgement messages, from high-to-low
- Bidirectional transport – transfer of user and reliability-protocol data from both low-to-high and high-to-low
The CDS can be a separate hardware solution with two or more network interfaces or a software component that runs in a MILS OS partition. In either scenario, the CDS can bridge several network levels, providing bidirectional traffic between any pair of levels as allowed by the security policy of the CDS.
High-to-low transfer using a DDS-based CDS
A fundamental requirement for any CDS is that all traffic flowing through the CDS can be inspected and potentially filtered according to the active security policies. This requirement is directly supported by the DDS standard through its type system. DDS provides type information for all data flowing through the system. The CDS can use the type information to dynamically inspect the contents of each packet that passed through. The data inspection can inspect all data fields and, potentially, allow for the modification or redaction of fields according to a security policy. The DDS standard provides an architectural opportunity to perform deep inspection of content to preserve data confidentiality (for high-to-low transfers of user data) and protect differing levels from malicious code or data. Since DDS exchanges type information once (when it sets up a communication channel), the data inspection capability takes minimal network bandwidth.
These are a few examples of how a standards-based platform helps implement secure sharing of mission-critical data across networks. Some system integrators have already adopted a standard-based approach and are well positioned to respond to the increasing MLS requirements.
Real-Time Innovations, Inc. 408-990-7400 www.rti.com