The big question is, in the Australian/ASD/ISM context, what is the difference between a Gateway and a CDS?
¶ NIST definition
Cross Domain Solution (CDS) - A form of controlled interface that provides the ability to manually and/or automatically access and transfer information between different security domains. A CDS may consist of one or more devices.
Access Cross Domain Solution - A type of transfer cross domain solution (CDS) that provides access to a computing platform, application, or data residing in different security domains without transfer of user data between the domains. Note: The access function is implemented by transferring keyboard and mouse data down to the lower security domain and sending video/image data up to the higher security domain.
Sources:
CNSSI 4009-2022 from CNSSI 1253F Attachment 3 - adapted
NIST SP 800-53 Rev. 5 under cross domain solution from CNSSI 1253
¶ ASD
… refer to ASD’s Introduction to Cross Domain Solutions and Fundamentals of Cross Domain Solutions publications.
ISM material → Guidelines for gateways , Implementing network segmentation and segregation
Comparison with network gateways (from Fundamentals of Cross Domain Solutions)
A CDS could also be described as a robust network gateway that is designed, built and tested to a high level of assurance, and tailored to a specific use case or set of use cases. Unlike a network gateway or network firewall appliance, a CDS employs a wide range of controls to provide defence-in-depth.
A network gateway is considered much less robust when compared to a thoroughly architected and assured CDS, as many important controls are not present in a typical gateway implementation. For this reason, network gateways are restricted to lower risk connections between security domains, while a CDS comprising security functions with higher levels of assurance is used for connections that are higher risk.
The below table offers a side by side comparison between a CDS and a network gateway.
| Cross Domain Solution | Network Gateway |
|---|---|
| Connects security domains across multiple trust levels | Generally connects security domains at the same trust level (although network gateways are also used between OFFICIAL or PROTECTED networks and the internet) |
| Robust content filtering at the application layer | Protocol filtering at the network and possibly application layer |
| Controls application transactions | Controls network connections |
| Few network services permitted | Many network services permitted |
| Breaks data transport protocols | Generally no protocol break |
| Uses trusted platforms | Generally no support for trusted platforms |
| Uses multiple trusted subsystems | Generally a single device or appliance |
| Typically employs tailor-made solutions, or government-off-the-shelf (GOTS) or military-off-the-shelf (MOTS) products, in addition to COTS products | COTS product |
| Higher levels of security assurance | Generally lower levels of security assurance |
Opinion: This is a very vague qualitative comparison! Architecturally they're the same, it's just a matter of threat modelling and appropriate design. NCSC OTOH provides a useful set of principles (below).
¶ PSPF
Australian Government Gateway Security Standard
- PSPF Release 2025 - Australian Government Gateway Security Standard
- Australian Government Gateway Security Standard 2026
The PSPF only talks about Gateways, and their description in the standard is more like a CDS than the ASD/ISM Gateway definition.
¶ NCSC
- https://www.ncsc.gov.uk/collection/cross-domain - Cross domain approach and architecture
- https://www.ncsc.gov.uk/collection/cross-domain/cross-domain-concepts
- https://www.ncsc.gov.uk/collection/cross-domain-solutions/ - Security principles for cross domain solutions
- https://www.ncsc.gov.uk/collection/cross-domain/cross-domain-design-principles
- https://www.ncsc.gov.uk/blogs/new-cross-domain-guidance-for-government-industry-and-the-wider-security-community
The 6 design principles (from link above)
- Understand and minimise data transfer
- Gain trust across the entire stack
- Only export understood and expected data
- Minimise wider impact of compromised components
- Make key security controls simple
- Design for observability and manageability
Examples
The older set of principles (Thirteen things that need to be good to make a secure Cross Domain Solution (CDS)) which are deprecated by the new principles.
- Security principles for cross domain solutions
- Using the principles
- Network protocol attack protection
- Content based attack protection
- Protect against the unauthorised export of information
- Session isolation
- Persistent compromise protection
- People and the CDS
- Management
- Audit and accounting
- Authentication
- Data-in-transit protection
- Data-at-rest protection
- Patching
- Component integrity
¶ Other reference material
- https://en.wikipedia.org/wiki/Cross-domain_solution
- https://www.nsa.gov/Cybersecurity/Partnership/National-Cross-Domain-Strategy-Management-Office/
- vCDS: A Virtualized Cross Domain Solution Architecture (pdf)(https://par.nsf.gov/servlets/purl/10333071)
- Shedding Light on Cross Domain Solutions (PDF, 5.78MB) Published: 09 Dec, 2015
