Cross domain security principles
As noted earlier, a CDS must address the cross domain security principles of:
- context-appropriate security-enforcing mechanisms
- secure architecture and design
- system assurance and secure operation.
These cross domain security principles must all be achieved and maintained in order to address the information security objectives of a CDS capability. Conversely, if any of these cross domain security principles were to fail, the overall security of a CDS would likely be compromised – which would impact the security of connected high side security domains.
Detailed descriptions of how a CDS can achieve these cross domain security principles are described below.
Context-appropriate security-enforcing mechanisms
Security policy enforcement
A CDS will enforce a security policy, developed to meet an organisation’s information sharing requirements, whilst upholding the security and risk acceptance assumptions of the high side security domain.
The security policy must consider the information being shared (i.e. the semantic content) and the data format used to convey that information (i.e. the syntax or syntactic structure). A CDS should validate all file content, and any other data, against a schema of known and expected traffic. Furthermore, a CDS will ensure all information, including data type, content, source and originator, is approved for release via conformance to the security policy or a securely-implemented manual intervention process that reveals any hidden content to a knowledgeable reviewer.
Further information on security policy enforcement can be found in the ISM’s Guidelines for Data Transfers and Content Filtering.
Block first, ask questions later
A CDS will block all network traffic by default, maintaining the air gap and only allow information to transit once it passes security enforcement.
Blocking all information transiting from one security domain to another, except where explicitly approved according to a defined security policy, can increase the level of assurance that information transiting a security domain is legitimate and benign. A CDS should also incorporate firewall and gateway best practice and drop all unexpected protocols.
A CDS will filter data and information moving from low side to high side, to protect the integrity of the high side security domain from malicious content.
This will include employing traditional signature-based antivirus techniques to identify known bad content, as well as behavioural analysis and advanced content filtering where appropriate. Where possible, passive neutralisation of malicious content is more effective than traditional malware detection and prevention techniques. This can be achieved through lossy transformation of original data formats into alternative formats that ensure business information remains present (i.e. the data is semantically equivalent) but the binary content and metadata has been modified (i.e. the data is syntactically different).
Data loss protection
A CDS will filter data and information to mitigate its inadvertent or deliberate transfer onto a system not approved to handle it.
For fixed-format messages, a data field should be dedicated to the sensitivity or security classification of messages. A CDS will then check that field to ensure the destination security domain can handle it.
For systems that employ a Reliable Human Review process, system developers should note that humans are unreliable at identifying hidden content without technical assistance, this can decrease further when data is more verbose or more frequent. Release approvers must be knowledgeable about the information for which they are attesting, including its sensitivity and appropriateness for release.
A CDS will ensure all users, including non-human system user accounts, are authenticated and authorised to access the CDS and related security functions.
If it is necessary to receive information from unauthenticated sources (e.g. web or email servers), a CDS should implement cyber security best practice to confirm the authenticity of each data source, such as through verification of Transport Layer Security certificates. This measure would also support provenance checking, as described below.
A CDS will check where data has originated to ensure it aligns with expectations and that provenance is maintained through any links between source and destination systems.
A chain of provenance may be based on the physical design of CDS systems, cryptographic techniques or other approved means. A CDS will also ensure data is not accessed or modified, other than by trusted and approved users or processes. A CDS should support best practice data-in-transit protection for all connections (e.g. point-to-point encryption).
Transformation and normalisation
A CDS, where possible, will convert file types into a standard and normalised format.
Content transformation processes have the potential to remove malicious or hidden content within files or to make malicious content inert. For this reason, transformation is a critical security function for complex document types, particularly those being transferred from low side to high side.
Advanced content filtering, also known as content disarm and reconstruction, is a process for deconstructing a file, removing all elements that do not conform to the file’s type specification, and then rebuilding it into a clean known good version suitable for transfer across a CDS. Files embedded within archives or other documents should be recursively extracted and processed individually.
Following transformation and normalisation, data can be validated against a schema of known and expected traffic. Ideally, data will only be accepted in specific file types that can be analysed against the schema.
A CDS will act as a network proxy and terminate transport protocols at multiple layers of the OSI model for all network traffic.
This protocol break helps a CDS protect the high side from malicious network traffic and application layer protocols. For example, at the transport layer (OSI model Layer 4), Transmission Control Protocol connections may be broken and retransmitted using the User Datagram Protocol.
A CDS will enforce uni-directional data flows using one-way control components and one-way inter-process communication paths.
The direction of data flows will not be modified during the operational life of a CDS without approval. Data transport across a one-way control, such as a data diode, typically uses a stateless protocol facilitated by a protocol break.
A CDS will monitor the size, volume, quantity and types of traffic and take action when this traffic exceeds defined thresholds.
Unexpected traffic, such as that arriving from an unknown source, on an unused network port or at an unusual time, should trigger a security action (e.g. alert or block) as this may indicate a misconfiguration or compromise of upstream services.
Secure architecture and design
Organisations will have an architecture that separates information and systems into stand-alone security domains with a common security policy.
This will most likely be done according to sensitivity or security classification, and is a precondition for the most effective use of a CDS. These isolated security domains, with physical, logical and/or cryptographic separation, are said to be protected by an air gap reflecting the deliberate lack of connectivity to external environments.
A security domain adheres to this cross domain security principle if the only way to transfer or access information from an isolated security domain is via an assured CDS or other approved process that maintains logical network segmentation and segregation.
Further information can be found in the ACSC’s Implementing Network Segmentation and Segregation publication.
A CDS will follow architecture patterns and/or design patterns, where approved and available to system developers, to ensure risks related to common security problems are addressed consistently and securely.
Architecture patterns are being developed for a number of common business requirements and can be requested from the ACSC.
A CDS will be tailored to the specific business, operational and security requirements of CDS system owners.
Although CDS components may be re-usable, particularly where pre-approved architecture or design patterns have been used, the risk assessment and risk acceptance activities relevant to one CDS are not automatically transferable to another.
A tailored and considered risk assessment is necessary when expanding capabilities of a CDS beyond the specific well-understood use cases and threat environments which formed the basis of the original risk acceptance activities. Additionally, new use cases may also inadvertently reduce the security of the initial implementation. Therefore, changes in the security posture of a CDS must be thoroughly assessed against business requirements to ensure residual risks are fully understood and acceptable.
A CDS will employ layered controls such that a single failure will not compromise security.
A CDS will contain redundant components that eliminate single points of failure at all levels of the system stack. For larger and more complex systems, there should be diversity in platforms, operating systems and software components (e.g. by employing diverse implementations of the network stack across system components along the data path).
A CDS will be designed to address security concerns first and foremost with functionality added as necessary to meet business requirements.
CDS system designs should solve security problems rather than blindly apply security controls to an existing system. Critically, security should be baked in throughout the development and implementation process and not bolted on at the end.
A CDS will be designed to be as simple as possible while still meeting security and business requirements.
Complexity in CDS system design will complicate system assurance, operation and maintenance, and possibly increase the attack surface. Furthermore, overly complex systems may introduce additional costs to organisations throughout development, implementation and operational phases.
Software packages and physical interfaces not vital to the day-to-day operation of a CDS should be removed.
Note, when following a risk managed approach, a better security outcome may sometimes be achieved if some security controls are relaxed. As long as it can be demonstrated that the overall intent of the security control is still met and the decision reduces the overheads in managing an otherwise complex system.
A CDS will ensure that critical security-enforcing mechanisms are not able to be bypassed.
Security-enforcing mechanisms are actively coordinated by a filter orchestration process and/or passively by the system’s architecture. A CDS will also break and inspect any encrypted data in transit to ensure enforcement can occur.
It should not be possible to bypass a CDS or its security-enforcing mechanisms. For example, physical and personnel security controls should protect a CDS against tampering.
A CDS will separate data flow paths to ensure that appropriate enforcement is applied on a data path basis.
Data paths are optimised to address the specific threats to either high side confidentiality or integrity. For example, data moving from low side to high side security domains will typically be channelled through a different arrangement of security-enforcing mechanisms compared to data moving from high side to low side.
CDS system architecture will also employ network segmentation and segregation internally, creating separation between security zones within CDS components to limit bypass of critical security-enforcement points. Movement between these security zones will be enforced by software and hardware firewalls as well as one way controls (e.g. one-way inter-process communication paths and hardware data diodes).
Attack surface reduction
A CDS will present the minimum functional system interface to connected security domains.
Software platforms should be hardened by removing any unnecessary interfaces and functionality. Consider the employment of access and authorisation security controls and the use of firewalls to create protected CDS zones. Like a CDS core, these firewalls should also block all traffic by default allowing only the minimum traffic necessary for system operation. Alternatively, consider security through obscurity (although this is an insufficient security measure alone) such as using a network sinkhole to direct traffic into a logically separated CDS zone. This cross domain security principle also applies to the internal components of a CDS.
Cascaded connections mitigation
The risk of cascading connections to lower trust environments will be identified and mitigated.
Consider any additional connectivity into and out of security domains connected by a CDS and how this might affect the threat model. For example, a data spill might not be contained to just one security domain if a cascaded connection to a further security domain exists and is not accounted for.
System assurance and secure operation
Formal system assurance
CDS system owners will ensure CDS capabilities undergo a formal system assessment process and any recommendations are adopted.
In order to ensure projects that involve a CDS are not stalled by formal system assurance activities, CDS system owners will account for these activities in project schedules and plan for any potential failures or findings of unacceptable risk. To reduce this risk, CDS system owners should engage with relevant security authorities early and follow any advice given.
Trusted platforms and components
A CDS will use platforms and components designed and assured for security, especially for critical security-enforcement mechanisms.
A CDS should use components that have been evaluated under the ACSC’s High Assurance evaluation program, or mutually recognised by the ACSC, where they are available and suitable. This ensures that technical, physical and procedural protections for components are sufficient to address national security threats. System developers and integrators should also incorporate a secure cyber supply chain for software and hardware components to ensure they are not compromised during development and manufacture.
Platforms and components should also be hardened by following the ACSC’s Strategies to Mitigate Cyber Security Incidents and other system hardening guides such as the Security Technical Implementation Guides developed by the US Defense Information Systems Agency. Such hardening activities should include the removal or neutering of unnecessary users (e.g. system users, particularly ‘root’) and functionality (e.g. kernel modules, developer tools and any unused third-party software).
A CDS will employ secure administration practices.
Secure administration practices include, but are not limited to:
- managing configuration out-of-band or from the high side only
- using data-in-transit encryption for administration sessions
- authenticating all administrators and management interfaces
- following general information security objectives of role separation with role-based access control and least-privilege
- treating administrative actions as privileged access and auditing appropriately
- implementing separation of duties such that no single person can alter the operation of components of a CDS from end to end (e.g. firewalls, CDS core components and auditing are administered by different people).
Accountability and detection
A CDS will employ the ACSC’s best practice audit advice to generate and store meaningful audit and logging messages.
A CDS should employ meaningful system monitoring and alerting to aid system integrity and availability, and not be reliant on human observation. This functionality should incorporate monitoring tools that are configured to automatically profile normal business behaviour and alert to significant variations and anomalous behaviour.
Further information can be found in the ISM’s Guidelines for System Monitoring and in the ACSC’s Windows Event Logging and Forwarding publication.
A CDS will employ passive and active self-protection measures.
Secure CDS implementations should protect themselves against direct attacks, as well as attacks through data channels, that aim to impact connected security domains. A CDS should also include measures to prevent any compromise that gains a foothold from achieving persistence within the system. Further, CDS components should employ a trusted boot process and only operate in clearly-defined states. For example, system configuration and operation should never occur simultaneously. Finally, security-enforcing mechanisms that are intended to process complex data types should be reset between each session to provide a clean execution environment for filtering software.
A CDS should also implement functionality for identifying emerging security vulnerabilities across its application stack in an automated and time sensitive way, especially for any public or internet-facing components. The underlying hardware of security-enforcing mechanisms should also employ physical tamper detection and prevention measures. More complex systems may also incorporate additional intrusion detection and prevention functionality within CDS zones.
Finally, any release approval processes should check the internal provenance of data and verify the integrity of security-enforcing mechanisms that data has passed through (such as being signed by the content filter orchestrator or similar process). In addition to passive protections, CDS command and control metadata should be validated and correlated with other CDS logs (e.g. release authorisations).
A CDS will fail securely, such that the disabling, compromise or failure of a single component or a chosen number of components should not lead to compromise of the security of the CDS or the high side security domain.
The definition of a secure failure depends on the information security objectives that a CDS is intending to achieve. Typically, the objective is to ensure the integrity and/or confidentiality of information, in which case a secure failure will see a CDS block all information until secure operations can be resumed. However, this may be undesirable if availability of information is determined to be the most critical business requirement. In this case, a critical alert should be generated so that an alternative system or method can be used while the failure is investigated as a matter of urgency.
CDS system owners should have a plan in place to manage any component or system failures. Similarly, a CDS should not be allowed to operate in a degraded state where the secure operation of security-enforcing mechanisms and audit functions cannot be guaranteed.
CDS will operate opaquely and not leak information about the high side or themselves to low side systems or users.
Unsuccessful operations shouldn’t provide security-related feedback or otherwise present new information to users.
Security maintenance and operational support
CDS system owners will maintain the security level of their CDS and security-relevant systems.
Administrators will apply patches and system updates to operating systems, software libraries, anti-malware signature lists and other components as soon as possible. In doing so, any updates or modifications should follow approved change control procedures and be reflected in formal system documentation. Furthermore, patches and system updates should have an assured provenance and be sourced from the highest, and therefore most trusted, security domain where possible.
CDS system owners will monitor and review their security posture regularly, as negotiated with the applicable authorising officer.
CDS system owners should recognise that threat environments and technologies are not static. CDS technologies have matured considerably and continue to evolve since many legacy products and capabilities were first designed.
Note that the risk management process defined in the ISM features a continuous monitoring phase that ensures that the impact of changes to the threat environment and any security-relevant components are considered and risk managed in a timely manner.
CDS system owners will ensure users are trained in the secure use, operation, administration and maintenance of their CDS.
Noting that human behaviours are often as important to security outcomes as security controls themselves, a CDS should be designed in such a way that users will be willing to use them while following all associated processes and procedures. Regardless, users should still be informed of the consequences of misuse or attempted bypass of any CDS or other security-enforcing mechanisms.
Users of transfer CDS should be informed when security-enforcing mechanisms will modify their data, and the possible business impacts of that transformation. Users of relevant source systems that are connected to a CDS, particularly those in high side security domains, should be informed when their data might be replicated and presented within another security domain. Similarly, users of relevant high side security domains should be informed when data has originated from outside of that particular security domain and may be unsafe. Note that informing low side users of the existence of a CDS, or that their data may be replicated, may sometimes run counter to business and security outcomes.
Any access CDS, or other specialist implementations that perform a similar function such as voice and video teleconference gateways, should clearly indicate to users which security domain is currently active.