Cross domain approach and architecture
How to safely enable data flows between areas of different trust within and between modern digital systems.
Pages
Page 4 of 5
Cross domain architecture
As mentioned earlier, cross domain is an end-to-end architectural approach which manages the risk of business data flows between zones of trust. When moving data between these zones, assurance is not gained at a single point, but through the pipeline of layered controls distributed between the source and destination of the data flow. Each stage in the pipeline should be designed to ensure that the next stage can safely process its inputs.
To reduce the risk of unsafe data being passed into critical functions, controls should be applied at the appropriate points in the architecture. For example:
- validating network protocols where networks physically connect
- verifying session protocols before application handling
- confirming data format safety before business logic processes it
The architecture should be constructed from multiple components. Where these components provide a security critical function, they should be single purpose and suitably hardened. This maintains flexibility, reduces component attack surface and avoids unnecessary complexity. While these components may be deployed on shared hardware, it should be possible to reason about the security properties of individual components (as opposed to having a monolithic technology stack providing multiple security functions).
There may be use cases where it’s appropriate to implement the architecture within a single, physical appliance, similar to how cross domain products have traditionally been developed. However, there are an increasing number of uses for cross domain technologies, which may require flexible architectures. As the number of use cases for cross domain technologies increases, there is a need for more flexible architectures. To achieve this, organisations may have look beyond implementations that combine the end-to-end control points in a single platform, appliance or application. This also requires recognising that not all components in the path will be under the same management. Infrastructure, identity services, DNS, time sources and other dependencies may be outside your administrative control, but these are still critical to the secure operation of the cross zone flow. Understanding ownership boundaries and the trust assumptions they create is key to managing the overall risk.
Understanding the threat
Cross domain architectures are fundamentally driven by the threats your organisation faces, and the level of risk you are willing to accept. This is where threat modelling becomes essential. By analysing your assets, adversaries, attack surfaces and likely attack paths, you can determine which data flows require stronger controls and what those controls must achieve. The threat model then directly shapes how you design and implement your cross domain flow, including where boundaries should sit, what validation or transformation is required, and how much assurance you need at each stage.
At the same time, every architectural choice involves trade‑offs between security, cost and usability, and these should be made consciously and proportionately, rather than adding complexity without meaningful risk reduction.
Because cross domain is a risk‑reduction approach, it relies on having a clear picture of the threats you need to mitigate. With that in mind, an attacker typically will pursue one or more of the following approaches to achieve their objectives:
To have impact – whether stealing information or disrupting operations – an attacker must first gain a foothold. This usually means delivering malicious content or exploiting a vulnerability somewhere in your trusted systems. Exploits can target any layer of the stack, from network protocols to business‑logic parsers, and may involve chained vulnerabilities to move deeper into the system. Attacks may use malformed inputs (such as SQL injection) to achieve a specific exploit.
Attackers frequently aim to extract sensitive business or operational information. They may use legitimate export paths or covert channels to move data out of a trusted zone. This is why minimising and tightly controlling exports is essential in any cross domain design.
Not all attacks aim to steal data. Many seek to corrupt or manipulate information, spoof messages, or inject misleading content. This erodes confidence in systems and may push users toward unsafe alternative communication channels.
After a successful exploit, attackers often deploy malware for persistence. These implants need bi‑directional communication to receive commands and return status updates. This creates a continuous cycle of importing and exporting attacker‑controlled traffic.
Attackers may attempt to degrade or block system availability, either as an end goal or to force users onto less secure fallback channels. DoS activity can target any point in the architecture and can significantly impact operational capability.
If your systems connect to other networks, attackers may try to compromise yours as a stepping stone to their real target. This is especially relevant in complex, interconnected environments or where you interface with multiple parties who may be mutually untrusted.