Cross domain approach and architecture

In the context of cross domain, trust is about how much confidence you have in a given system or network. The NCSC define a zone of trust as a collection of components with a defined boundary (known as a ‘trust boundary’) that share a similar security posture.

Note that trust is relative to the observer. This means the way you see and judge trust depends on the zones you manage. From your own perspective:

• Import is anything coming into the zone you are considering from a zone you wish to peer with. This could be business data, metadata, or control signals; essentially anything crossing into the zone of trust you are considering.
• Export is anything leaving the zone of trust you are considering to a peer zone. Again, this could be business data, metadata, or control signals.

The important point is that the same data flow will be seen differently depending on which side you are on:

• on import, controls focus on preventing harmful or malicious incoming data
• on export, controls focus on preventing sensitive or unauthorised data from leaving

Therefore the controls applied differ depending on direction of data flow.

While the primary data flow may appear to be import (for instance importing an Office document), in reality there will be secondary data flows operating in both directions. In this example, the Office document might be delivered by an HTTP stream, which is implicitly bi-directional. Recognising this will impact the required set of cross domain controls.

Historically, cross domain solutions (CDSs) and cross domain gateways (CDGs) were built as single, high assurance devices linking two networks. These devices enforced strict controls at one clear boundary, operating as a single point where all checking occurred. This worked when architectures were simple, trust relationships were binary, and data flows were tightly scoped.

Modern environments no longer fit this model. Rather than a simple ‘high trust’ and ‘low trust’ networks with a boundary, we recognise that systems span multiple trust zones, with multiple boundaries, often under different ownership and with varying assurance levels and exposure to different threats. In these cases, a single enforcement point cannot provide sufficient protection.

In modern cross domain architectures, there is no single boundary point within a physical device. Instead, the boundary should be viewed as a ‘pipeline of functions’, each performing a specific role in reducing risk and gaining trust in the data flowing between zones. Within this guidance we’ll refer to these functions as control points.

The control points form a series of assurance stages, where each prepares the data for the next. Some of these stages are lightweight; others may be more robust. These more robust points we refer to as security control points. A security control point has the following broad requirements:

• if it receives malicious data it will be sufficiently robust that the data will not compromise the control
• it will not allow malicious data to propagate further if the checks fail
• it will not allow cross-session contamination (that is, if multiple data are being processed, processing malicious data will not impact non-malicious data)
• it enforces data flow directionality (that is, it’s not possible to use the data flow to ‘send data the wrong way’)
• the robustness of implementation is dictated by the the system’s threat model and organisation’s risk tolerance.

This ‘pipeline of control points’ can be compared to how passengers board an aircraft; passengers do not simply arrive at the runway and board. Instead, there are several steps and checks before they can enter the aircraft, which will involve:

• secure parking
• checking-in baggage
• checking boarding passes
• passing through passport control
• passing through security
• checks at the boarding gate

Some of these steps are more robust than others (such as going through the metal detectors in security) and not everything goes through the same steps. For example, checked-in baggage takes a different route to passengers. 

A single cross domain flow will include logical control points and implementation components.

Logical control points

These represent the required security functions applied at specific points in the flow, such as syntactic validation, transport termination, or release control. Logical control points describe what must be enforced, not how or where it is physically implemented.

Implementation components

These are the actual technologies (such as FPGA verifiers, hardened TLS termination components and isolated compute) that implement one or more logical functions. A single physical component may implement multiple control points, or a single logical control point may span multiple physical components. Implementation components can have differing levels of robustness (and hence assurance) depending on the technology, and the choice will  be driven by the system threat model.

The placement of the control points and the choice of physical components is driven by the function of each control and the threats relevant at that part of the data flow. Although import and export flows may use some of the same functions, their logical control points and required assurance levels will differ. This is a result of the asymmetric nature of cross domain data flows.