Cross domain approach and architecture
How to safely enable data flows between areas of different trust within and between modern digital systems.
Page 5 of 5
Cross domain design principles
This section describes 6 design principles for cross domain, based on the core concepts mentioned above and the threats that require mitigating.
Note
These principles replace the NCSC’s Security principles for cross domain solutions. While those principles are now deprecated, they are retained because Principles Based Assurance (PBA) for cross domain products rely on them. The cross domain PBA approach will be updated in time to reflect these new design principles. The blog New cross domain guidance for government, industry and the wider security community gives more details.
The 6 design principles
Understand and minimise data transfer
Transfer only what is necessary to achieve the required business outcomes. Choose simple protocols and strip unneeded information where possible. Doing so reduces the attack surface, limits covert channel risks, and strengthens overall system assurance. Recognise that different data flows will need to be considered separately, based on their specific characteristics.
Gain trust across the entire stack
Consider all data across the entire stack untrusted at its origin. This ranges from physical network layer to application context. Layer sequential security controls to progressively gain confidence in all data that enables the flow. This can be achieved through terminating or inspecting all meaningful data. ‘Meaningful data’ includes the specific content at that layer, as well as any associated control data (such as routing information or API parameters). This includes any content which could be interpreted as program logic, and therefore potentially lead to remote code execution or unintended processing. Be aware that you may need to regain trust in a layer of the stack multiple times depending on the sequence of components in the flow.
Only export understood and expected data
Minimize and control export flows to reduce the risk of sensitive data leakage across boundaries. Where needed by your threat model, implement layered, deliberate authorisation and validation mechanisms to prevent unintended export while balancing operational needs.
Minimise wider impact of compromised components
Consider the benefit an attacker could derive if they are able to compromise a component in your cross domain flow. This is particularly important for lower assurance components such as data transformers. While a compromise may not threaten the more trusted zone, it may enable other attacks, for example theft, or loss of integrity of data within the flow, or using the component as a pivot point for other attacks.
Make key security controls simple
Reduce the attack surface of components that form key security controls to enable increased assurance in their correct operation. Key security components should only perform a single function to reduce the risk of compromise.
Design for observability and manageability
Cross domain architectures should be designed with observability and manageability built in from the outset to enable security monitoring and integration. Ensure that data flows can be clearly traced end-to-end, and that the operations carried out on the data are recorded. It should be possible to correlate session information through the flow and map it back to the initiator. Components within the flow should be simple to deploy, configure and update, even when spanning multiple boundaries.
Example security cross domain data flows
In modern cross domain architectures, we no longer have a single network boundary between zones. Instead, we have a pipeline of control points that collectively provide assurance across the flow. Each control point contributes to managing the risk of moving data between zones, and ensures data must pass through the steps in the correct sequence. Security control points are specific points in the pipeline where additional assurance is needed to enable data to continue through the pipeline.
In this section, we’ll provide examples that show how security control points can be considered in import, export and bi-directional pipelines. Note that these are not presented as a definitive set of controls; their purpose is to show how organisations can think about applying security control points within their own cross domain pipelines.
Example 1: Security control points for import flows
Import flows are generally a linear set of controls to gain trust in the safety of the data across all layers of the stack. The pipeline of controls must ensure that each component that parses any data is only exposed to data that has been validated as safe for that parser. This aligns with the principle of Gain trust across the entire stack.
Importantly, moving through a control point does not always result in an increase in trust. Trust may be reduced at certain stages to enable the meaningful processing of data by later stages.
The example in the figure below shows a cross domain HTTPS flow. For this example, assume that JSON-to-XML transformation is required. The figure shows two security control points:
- TLS Termination. Termination of TLS in a security control point (the TLS Offloader in this example) provides mitigations against exploits targeting the network stacks of upstream components.
- XML Validation. Before the data can be validated as XML, it needs to be converted from JSON. As the JSON‑to‑XML conversion occurs before the data has been validated as safe to parse, the Processing component becomes less trusted. This drives the need for the second security control point in the higher assurance XML Validator.
The diagram also shows what trust there is in specific layers of a simplified network stack. In this example, the layers are:
- Physical
- Flow control
- Structure of business data
- Meaning of business data
At each stage of the pipeline, the amount of trust in each layer is shown. Where the layer is red, there is limited or no trust. Where it is green we’ve gained sufficient trust in that layer. And finally, where it is mustard, we’ve lost trust in a layer we previously had trust in. This shows how the overall trust in the data increases and decreases across the pipeline until it reaches the Trusted Network, and is an important concept when thinking about import Cross Domain data flows.
This layered view ensures that each control point is only exposed to data it can safely process, and that the overall risk of handling untrusted or partially validated data is addressed throughout the cross domain pipeline. The security control points in the pipeline are driven by functional and security considerations.
Example 2: Security control points for export flows
Security control points in export cross domain architectures have a different purpose to import security control points. In import flows, the focus is on preventing harmful or malicious data from reaching potentially vulnerable parsers. In export flows, the priority is preventing the inadvertent or unauthorised release of sensitive information to a less trusted zone.
Although export control points may be located at similar physical points to import control points, their logical function is different. The controls applied must ensure that only acceptable data is released. This involves two distinct concepts:
- Release Authorisation: deciding whether the data can be released
- Release Control: enforcing that only authorised data is released
The release control function is a security control point for the export flow.
The figure below shows a conceptual flow to enable export of complex data. In this case, determining what is acceptable to release is inherently complex. Deciding whether freeform, human or AI-generated content is safe cannot be achieved with absolute assurance. Such checks often rely on heuristic measures, such as keyword scanning, data loss prevention tooling, or manual second‑person review. These checks are individually low‑assurance, subjective and therefore imperfect.
The Processing Zone in the diagram has an implicit trust boundary between it and the rest of the Trusted Zone. This is due to the multiple boundaries concept introduced earlier. These functions are less trusted (due to their complexity or need to interact with other functions in the wider system), and hence a degree of separation is needed. However, this does not have to be as robust as a security control point.
Not all data flows require separate release authorisation and control. Some business use cases do not need to control the release of data. And some exports are simple and predictable data such as an ‘acknowledge’ status code. In these cases, a simple control point could manage both functions.
If your data flow does require complex release control, each check should be independent and isolated, as required by the threat model, and a single component failure should not result in unexpected release of data.
Example 3: Security control points for bi-directional flows
A bi-directional flow is where there is a round trip between zones, such as an HTTP request / response flow. In these scenarios, there needs to be a link between the import flow and the export flow (ie the export is the response to the import request).
The security control points in the import and export flows exist as above. However, due to the linked nature of the flows, additional boundaries need to be considered. This is shown in the figure below:
In any bi-directional flow, the two flows will have to merge at some points. In the example used above, they have to merge at two points for the data flow to work correctly:
- The TLS Offloader
- The Trusted Network
There is an implicit architectural boundary required to isolate the import and export flows outside of the explicit merge points (shown as the Processing Boundary in the diagram).
To give an example of why this is required, on the import flow, we have stated that the Processing component may be compromised by malicious JSON. We can assume the response from the more trusted network is in plain text, and passes through the same Processing component. In this case, an adversary has an import path to the Processing component (the request flow from the Untrusted Device) and an export path from it (the response flow back to the Untrusted Device). Therefore, they could:
- maintain command and control over the Processing component
- selectively alter data being imported or exported
- steal sensitive data from the Processing component
- selectively impact the user experience or availability of the system
It’s important to consider what control points and security control points are required to prevent an attacker achieving a bad outcome by pivoting between linked import and export flows. You also need to consider the level of assurance you require at this point in the end-to-end architecture, based on your threat model.