Open standards ease Multi-Level Security (MLS) systems integration
StoryJuly 27, 2011
Edwin de Jong, Ph.D.
Real Time Innovations (RTI)
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.
The use of advanced computer systems and networks as tools in all aspects of modern warfare continues to grow. Situational awareness and timely access to mission-critical information are increasingly the difference between mission success and failure. Providing mission-critical information often involves making data at different security classification levels widely available, often to systems on the battlefield.
Increasing Multi-Level Security or MLS requirements are being met by a new generation of operating systems. General-purpose and embedded operating systems like SELinux, VxWorks MILS, INTEGRITY-178B, and LynxSecure are available. However, the connected and distributed nature of modern systems dictates that a single operating system and set of applications is not sufficient. Secure communication links enable the extension of individual nodes into a distributed system that can collectively process data at multiple security levels.
The following discussion examines some of the challenges involved in architecting and integrating distributed MLS systems – and how these challenges are best addressed by adopting a standards-based integration platform.
Architecting MLS systems
Enforcing security policies in a distributed MLS system can be surprisingly complex. The goal of MLS is to maintain security classification levels throughout distributed systems. The rules are seemingly straightforward and operate on sensitivity (for example, Secret or Top Secret) and a set of categories (for example, red, blue, and green). Data is labeled with sensitivity and one or more categories. Processes, acting on behalf of a user, should only access data at the same or lower sensitivity and only if that process is authorized for that particular set of categories.
The root of the problem lies in the fallibility of computer software. Even the best software inevitably contains flaws. Because even the tiniest flaw can be exploited, it is not possible to rely on the majority of software to enforce security policies.
The question then becomes how to architect software and systems to make it possible to process multiple security levels of data without having to rely on the majority of the software in the system, particularly application software.
Multiple Independent Levels of Security (MILS) architecture, for example, employs operating systems that separate security domains using very small and highly assured kernels. Within each separated environment or partition, applications or virtualized operating systems are run.
Figure 1: MILS (Multiple Independent Levels of Security) architecture, for example, employs operating systems that separate security domains using very small and highly assured kernels.
(Click graphic to zoom by 1.9x)
|
|
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.
Figure 2: Addressing the challenges of controlled information sharing in distributed MLS systems requires a standards-based approach that enforces security policies across different platforms.
(Click graphic to zoom)
|
|
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.
Domain separation
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.
Low-to-high communication
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.
Dr. Edwin de Jong is Director of Product Management and Strategy at Real-Time Innovations, Inc. He has more than 15 years of experience in the architecture and design of complex embedded systems. These systems encompass C4I, radar, track management, multisensor data fusion, threat evaluation, weapon and sensor assignment, and simulation and training. Edwin holds a Ph.D. in Computer Science from Leiden University, The Netherlands. He can be contacted at Edwin.Dejong@rti.com.
Real-Time Innovations, Inc. 408-990-7400 www.rti.com
