Security principles for cross domain solutions
Thirteen things that need to be good to make a secure Cross Domain Solution (CDS).
Page 1 of 15
These principles will be replaced by the NCSC’s Cross domain approach and architecture. While these 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.
This guidance lays out a set of Security Principles which you can use to guide the design, development, assessment and deployment of Cross Domain Solutions.
In this guidance, the term “domain” is used for a collection of computer and network equipment that shares services, accesses, and has the same rules and policies.
The mechanisms and systems used to connect different domains are referred to as “Cross Domain Solutions” (CDS).
Segregation and connectivity
Some organisations, particularly larger ones, have multiple computer systems that are segregated or separated to protect against malware and unauthorised data access or leakage.
Organisations are moving towards greater connectivity of their systems or domains with others. They are also joining up internal domains for simplicity or expediency. Such greater connectivity can increase the risk of malware transmission or data leakage.
The purpose of a CDS is to enable information flow, while mitigating or reducing cyber attacks and information leaks. A CDS should consider the needs of the people who will interact with it, as they are a vital aspect of the overall security of the CDS.
The term Cross Domain Solutions refers a set of architectural techniques and supporting technologies used to build secure end to end connectivity between IT systems that you trust differently (different security domains).
Who needs a CDS?
The need for IT services to operate across domains is almost universal. For example, domains must be crossed when Information Technology is separated from Operational Technology in critical systems, when connecting the government’s higher classified systems to lesser trusted systems, or when protecting financial and legal businesses from malware or data loss.
For situations like these, Cross Domain Solutions can be used to enable the import and export of information, sharing less trusted services in the trusted domain, or enabling email to traverse the domains.
Quality counts
As Cross Domain Solutions perform critical security functions, such as transferring information in and/or out of a system, the engineering quality and assurance of the CDS is an important factor.
This guide is aimed at all those involved in deploying a CDS, such as the Security Architects responsible for its design, developers of CDS technologies, and CDS evaluators. As people are an integral part of the ongoing operational security of a CDS, this guidance takes into consideration the many different types of CDS users.
Throughout this guidance a CDS is termed as a solution because a CDS is not necessarily a single device or appliance. It is a series of related technologies or functions, which are referred to in this guidance as ‘components’, embedded within a system architecture.
Your threats and risks
Your organisation will be subject to a range of cyber threats and risks. These could range from inquisitive employees trying to assess how well the CDS is working or criminal organisations looking to exploit your company, all the way through to state-sponsored actors willing to develop dedicated and sophisticated attacks, involving long term investment and research.
These threats and risks will change over time, potentially increasing in frequency, opportunity, nature, and impact.
Risks and threats will depend on various factors, including:
- how connections are made, and what they are needed for
- connected parties
- business needs for exchanges
- technology being employed to build the CDS
- the complex data processing environment your organisation already has
When looking to connect systems together, you must keep in mind that the environment in which a CDS operates can change.
Risks introduced by the CDS
When considering the implementation of any CDS, you should take into account what risks might arise as a result of making a connection between your system and that of a third party.
You should also consider the risks and issues that might arise as a result deploying a CDS within your enterprise and what impact it might have on day to day business activity. Incorporation of CDS technology might bring with it new types of risks, such as changes to business processes and the speed of data processing. There’s also the issue of user perceptions, with staff either finding the CDS a hinderance or seeing it as a cyber security cure-all. These risks should be suitably mitigated, using combinations of technical and non-technical measures.
An example of such an introduced risk could be that users feel hampered by the placement of security controls, so they decide to opt for less secure alternatives to achieve data exchanges, such as moving USB sticks between systems.
Scope of the cross domain principles
Due to the wide range of possible usage and threat scenarios into which a CDS could be introduced, these Principles do not define mitigations for specific threats. The Principles are designed to be applicable across the full range of threat scenarios, so you should assess your CDS design against your own specific usage and threat scenarios.
Risk owners typically require evidence that a solution addresses the risks which have been identified. These Principles will help you provide such evidence as they give you a framework around which assurance can be gained. The amount and type of evidence required will depend on the specific threat scenario, and probably, on the type of system being protected. A risk owner may require the evidence to be obtained from reputable, independent sources, and so these Principles have been authored with independent test facilities in mind.
Organisations subject to elevated threats can consider augmenting these Principles with the NCSC High Assurance Principles, or alternatively, may seek advice from NCSC directly. Elevated threat status may necessitate specific components within the CDS solution undergoing a formal NCSC evaluation, such as CAPS.
More structured or formal evaluations would validate that the protection mechanisms are suitable, and ensure the solution is developed, implemented, tested and manufactured in accordance with these, and related, principles.
Design and implementation
Because Cross Domain Solutions often perform critical security functions, their design and engineering require appropriate levels of care and attention. This section highlights some of the key things to consider when designing a CDS.
Discrete components
The nature of any given CDS can vary widely, depending on the specific business needs and information exchange requirements. The capabilities that will be used to implement each function will reflect this variability. For example, data import may be primarily concerned with minimizing malicious content, whereas data export may be concerned with correct release of data. These differences are likely to necessitate independent components for each function. In other cases, a single component may be used for more than one CDS function.
When considering what constitutes a CDS, you should include as much of the full end-to-end system involved in transferring information as practical, recognising that the complete CDS is likely to comprise a number of discrete components.
The success or failure of a CDS depends on how useful it is to the business and usable by the people that use it. You should consider how your solution will be used by end users and those who will install and administer it.
Direct and indirect interaction
People may interact directly or indirectly with the CDS. A common example of a direct interaction is the use of a CDS-supplied browser to surf the web.
Indirect use involves services performed behind the scenes by the CDS. For example, the process of transforming a complex file type to make it safe for import might appear transparent when used indirectly. The transformed file is simply delivered to its recipient. However, when used indirectly, the end user must still be able to make informed decisions about the data they have received - in this case, has the transformation altered the data?
Protecting the CDS
A CDS should implement, in some form, all the protections described by the Principles below. However, in some cases, individual CDS components can be more flexible, implementing only the defensive techniques required by that component’s role in the overall CDS design.
A CDS design should consider the possibility of a protection mechanism failing, whether through a fault, operational shortcoming or intentional attack. A defence-in-depth approach will help to minimise the impact of any such failures.
Performance issues
Although performance issues are important when developing a CDS, the final effects are highly dependent on the implementation and the context of the system. For this reason, this guidance does not address performance issues in detail.
You should weigh the benefits of using a CDS against any negative perception by your users, to ensure they do not seek to use less secure alternatives. The CDS should also consider the availability needs of any data exchange process.
Best practice
The CDS and its components should be implemented using industry best practice regarding secure design, coding, testing and deployment.
Related advice
This guidance complements the NCSC's existing technology principles, such as those for high assurance products, cloud security and secure communications. When used together with other NCSC guidance, these principles allow you to assess how well different types of CDS protect against the threats you have identified.
