Operational Technology
Page 15 of 37
Principle 5: Harden your OT boundary
The prevalence of obsolete assets and weak security controls within the OT environment makes hardening the OT boundary critical. Network segmentation and segregation remain key controls to reduce exposure, where built‑in protections at the device or protocol level may be limited. Although these measures provide a robust first layer of defence, they are even more effective when combined with native security capabilities within OT systems. This could include secure by design devices and authenticated communication protocols.
Note: In certain sectors, the security of connectivity patterns may be set by regulations. In some instances, these patterns can restrict your ability to choose the security controls implemented. Regulated organisations should ensure they adopt new secure patterns, introduced by the relevant industry body or regulator, as quickly as feasible. If the security controls established by the regulator or industry body fall short of the standards anticipated by your organisation, you should implement compensating controls, such as the hardware flow controls outlined in this section, to mitigate residual risk. Regulators and supporting industry bodies should be routinely updating these patterns to improve their security as the threat landscape evolves, and new controls become available. Old connectivity patterns should be deprecated and all users moved to the new secure pattern. |
Because many OT systems are difficult to update or replace, the boundary becomes the primary defence against external threats. Organisations should therefore invest in modern, modular, and easily replaceable boundary assets. This could include deploying a firewall with application-layer (Layer 7) inspection capabilities, often referred to as a next-generation firewall. These assets offer greater flexibility for patching, upgrading, and reconfiguring security controls. Importantly, they can be maintained without disrupting core OT operations. This makes them essential for adapting to evolving threats and maintaining long-term resilience.
Your OT boundary security controls need to be flexible to enable your boundary to evolve to meet changing threats; if a device or system is directly exposed to an external network it has no additional lines of defence. This means that the failure or compromise of a single control or measure would result in an attacker gaining immediate and complete access to the system.
When designing security across all connections, a layered approach, commonly referred to as defence in depth, should be prioritised.
Note: It is critical that devices facilitating connectivity with external services and networks are designed for this threat context and have suitable technical controls. It is critical that OT boundary assets are:
Given their location at the edge of your network, these devices are particularly susceptible to exploitation by attackers if known vulnerabilities are present. The NCSC's vulnerability management guidance provides detailed advice on managing risks throughout an asset's lifecycle. The DSIT Software Security Code of Practice can help assess whether vendors develop software securely. |
To harden your OT boundary you should consider the following:
-
Remove unused services and ports:
Devices should be configured to only expose required services within the network to reduce their attack surface.
-
Implement phishing resistant multi-factor authentication (MFA) for external services:
Access to human-to-machine connectivity should require MFA in order to protect sensitive information and prevent unauthorised control actions. The NCSC’s guidance on Multi-factor authentication for your corporate online services can help you to implement strong methods of MFA.
-
Change default passwords:
No devices deployed in your network should have default passwords, as using default credentials makes the compromise of assets trivial. This is particularly important for devices exposed to the public internet, or your external networks. Your organisation should ensure it has a password policy in place that sets out ways to generate and store secure credentials.
-
Enforce the principle of least privilege:
Both human-to-machine and machine-to-machine connectivity should follow the concepts of least privilege. Only the permissions required for the action should be granted. Where this is human-to-machine the connectivity should be user aware so actions produce an employee specific audit trail. Human-to-machine permissions should also be integrated into joiners, movers, leavers (JML) processes to ensure access rights are revoked if the user's role changes or they leave the organisation. The NCSC has guidance on privileged access management that covers this in more depth.
-
Use context aware access:
Where available you should implement context aware controls on external connectivity. These controls make decisions on connectivity based on a number of factors such as device location, device type and configuration and user pattern of life.
-
Enforce security requirements on third parties:
When a third party designs and implements connectivity into your OT environment, it is crucial to ensure that the solution aligns with your organisation's security expectations. For more information, please refer to principle 5 in the creating and maintaining a definitive view of your OT architecture guidance.
-
Enforce uni-directional traffic flows:
Where possible, establish outbound only uni-directional connectivity, to minimise risks from external connections. This approach reduces the potential impact of external systems on your OT systems and ensures their independence from outside influences. At its simplest form this could be using uni-directional protocols such as UDP and network policy enforcement. For high-threat or high-risk environments you may wish to consider further hardware-based security controls.
Hardware-based controls
-
Cross Domain solutions:
Cross Domain is a methodology and architectural approach to enabling risk-managed bi-directional data flows across trust boundaries. A Cross Domain solution represents a collection of security controls to enable a specific data flow, providing security across the layers of the network stack, backed up by products with hardware security controls at key boundaries. The NCSCs Cross Domain principles can be used to guide design, development, assessment and deployments of these as a security control.
-
Data diodes:
Data diodes aid in establishing assurance of uni-directional data flows, through physically enforced directionality designed into the hardware. This feature ensures that bi-directional communications cannot be accidentally re-enabled due to misconfigurations at either the device or network layer. It is important to understand that:
-
- a diode solely ensures data directionality; it does not encompass the broader security measures typically present in a Cross Domain solution.
- an architecture where a diode ingests untrusted content, followed by software parsers on the more trusted side to ‘make the content safe’ is not considered Cross Domain; to be Cross Domain, we would expect at the minimum for the untrusted content to be structurally verified in hardware to reduce the risk of software parser vulnerabilities.
- a diode in each direction (to enable bi-directional communications such as APIs) with software on the more trusted side to process untrusted content and orchestrate bi-directional flows is considered an anti-pattern.
-
| Tip: Data diodes can be a useful control when ingesting hard-to-inspect data into isolated networks e.g. ingesting logs / network capture into an isolated security monitoring environment. |
