Data Diodes and Semantic Checking at Secure Boundaries

This White Paper looks at using data diodes at secure boundaries, in particular cross domain and providing red/black separation. It looks at the deployment of application level data diodes such as Isode’s M-Guard and the complementary role of physical data diodes.

Types of Boundary Device

There are three categories of boundary device that it is useful to distinguish.

Software

Some boundary devices are software running on standard operating systems. Such boundary devices usually use hardened or security enhanced variants of operating systems to increase security of the device. An advantage of this approach is that boundary devices can be hardware-independent and can include standard software modules developed for mainstream operating systems.

Appliance

Many boundary devices, such as secure firewalls and routers are provided as appliances. Appliances will be software based inside, but will typically run operating systems appropriate to the appliance without general software access. Appliances will usually provide a mechanism for software update.

“Software Appliance” is a variant used by Isode’s M-Guard, which is distributed as software, but configured to run on a limited choice of hardware or virtual machines. Standard hardware is purchased separately, but only selected hardware explicitly supported by M-Guard.

Hardware/FPGA

The final class of boundary device is hardware. For some very simple devices, controls are simply implemented in hardware.

A popular modern choice for hardware boundary devices is Field Programmable Gate Array (FPGA ). FPGAs allow custom hardware to be developed for a much lower cost than developing custom chips.

A hardware solution will usually not be configurable and this immutability gives a desirable level of protection. Doing things in hardware tends to limit the feasible functionality of a boundary device and also prevents customization.

Data Diode Types

We now consider data diodes, and three particular types.

Appliance – Application Level

Isode’s M-Guard product is an application level data diode, provided as an appliance. This is described in the Isode white paper M-Guard – Isode’s XML Guard. It enforces unidirectional flow of XML messages, providing a data diode service that can be used by other applications.

Another appliance approach is to integrate application protocols in the appliance. An example of this is the Infodas SDoT Data Diode, which supports SMTP, HTTP and TCP in a single direction.

Low Level Hardware

Some data diodes ensure unidirectional flow at a low level. Two common approaches are:

1. Optical, for example used by BAE Data Diode Solution
2. SerDes (Serialization/Deserialization) used for example by OakDoor Basic Diode using FPGA.

This low level approach enables a very high level of assurance that unidirectional flow is enforced. Commonly User Datagram Protocol (UDP) is used as the interface to such data diodes. This gives a simple way for applications to push data through the data diode.

A downside of this approach is that there is no guarantee of reliability, as there is with an appliance.

FPGA Enforcement

Another class of data diodes use FPGA to provide additional security enforcement. These provide specific functionality that needs to be used in conjunction with custom applications on each side of the diode. Two example products are provided by OakDoor.

1. Import Diode ensures data conforms to the SISL syntax. Converting to this format across the data diode gives protection against malware. Note that this provides syntactic checking only and semantic checking needs to be done external to the data diode.
2. Export Diode checks an HMAC which enables the diode to verify that the data has been validated by an approved control process on high side.

Unidirectional Applications

While everyday applications are invariably bidirectional, there are important secure environments where unidirectional data flow is important. For example with an Above Secret domain, it is often useful to access data from lower security domains, while not allowing any data out. Example applications:

• File Transfer – importing files
• Messaging – receiving messages in the higher security domain
• Chat – higher security domain listening to chat rooms in lower security domains

To provide high assurance of unidirectional flow, it makes sense to use a hardware data diode as a central control.

A key concern with low to high transfers is prevention of malware. This means that there needs to be additional boundary checks – the data diode becomes just one part of the solution. For file transfer, there needs to be staging so that anti-virus and other content checks can be applied to the file as a part of the boundary check.

For messaging, content checks on attachments will be particularly important, but message protocol checks need to be applied to prevent attacks at the message protocol level. Chat is considered by example.

Unidirectional applications may also be high to low or between red and black.

Example: XMPP Unidirectional Guard System

XMPP is the NATO standardized chat protocol. Unidirectional chat feels superficially odd, but Multi-User Chat (MUC) services make sense, with high systems receiving messages from low side chat rooms. This is best achieved with Federated MUC (FMUC), as described in the Isode white paper Federated Multi-User Chat. The low-side system will have an FMUC room which feeds messages to a high side FMUC room. High side users will be able to see low-side messages and be able to exchange additional messages with each other in the high side FMUC room.

The above diagram shows the communication chain for unidirectional XMPP. The FMUC rooms will be held in the low side and high side XMPP servers, accessed by local XMPP clients.

Isode’s M-Link Edge product provides conversion between standard XMPP protocols and unidirectional streams for a data diode. A (hardware) data diode enforces unidirectional data flow across the boundary.

M-guard, also a data diode, provides additional semantic XMPP checks that a basic data diode will not be able to provide. This can enforce XMPP protocol following XMPP Application Profile for use with XML Guard to ensure that only acceptable traffic goes through. This can prevent XMPP protocol type attacks which might impact high side systems.

Bidirectional Applications

We now consider scenarios where data needs to flow in both directions.

Why Data Diodes are Important for Bidirectional

Superficially, it might seem that when data is flowing in both directions that there is no benefit from using data diodes. However, there are strong benefits.

Better Security

For a unidirectional protocol, it is straightforward to define clear rules as to what is permitted. M-Guard allows flexible configuration of XML messages which are allowed through the data diode, enabling very precise specification of what is allowed. M-Guard is stateless, so checks on each message are independent.

If a two-way protocol such as Simple Mail Transfer Protocol (SMTP) is permitted through a guard, rules to control it need to consider timing and ordering. This is going to be more complex to specify, with more ways that might lead to security issues.

Unidirectional is simpler, and so leads to better security.

Different Requirements for Each Direction

The primary requirements for boundaries are generally different in each direction.

1. For High to Low and Red to Black directions the primary security concern is information leakage, leading to requirements to validate security labels and prevent covert channels.
2. For low to High and Black to Red, the primary security concern is prevention of malware attacks.

By separating the flows, it helps ensure that appropriate checks can be applied for each direction.

Application Data Diodes Only

One approach for a boundary solution is to make use of application data diodes only. This is the approach suggested in Isode white paper XMPP Cross Domain Solutionusing M-Guard on the boundary. This approach means that data diode appliances can be used for the boundary separation and semantic checking.

Hardware Data Diodes Only

Another approach would be to use hardware data diodes on the boundary. The advantage of this is that such devices have high security assurances, making them an ideal choice for providing connections across a secure boundary.

The downside is that these devices will provide the separation only and do not provide any additional semantic checking.

Hardware Data Diodes and Application Data Diodes

By chaining a hardware data diode and an application data diode such as M-Guard, both high assurance separation and semantic checking can be provided. Some examples of value added semantic checking that M-Guard can provide:

1. Validate security label associated with data. This can be used to require that all high to low data is labelled and only allow appropriately labelled data.
2. Ensure in XMPP and other XML messages that no ‘extra XML’ is inserted, which could be used to create a covert channel.
3. Ensure that Modem SNR information going black to red in support of rate control is tightly structured XML with small elements, in which would be impractical to insert malware.
4. Ensure that Modem speed control information going from red to black has a limited number of message types, which in conjunction with rate control can prevent covert channel.

Conclusions

This paper has looked at different types of data diodes, in particular hardware diodes that can provide high assurance separation and application data diodes such as M-Guard that can provide semantic checking. These can be used independently or chained.