Operational Technology
Pages
Page 7 of 37
Principle 4: Identify and document connectivity within your OT system
Most modern OT systems no longer operate in air-gapped environments by default. Instead, they require external connectivity to support business functions, streamline maintenance activities, and enable enhanced security controls. It’s the connectivity and interactions between assets within a system that allow it to work to perform the intended function. Understanding how these assets work together within the wider system is essential for building effective and proportionate security controls.
When designing connectivity, reducing your organisation's vulnerability to potential attacks is paramount. For instance, the use of wireless communication technologies can elevate risks, as threat actors may not need to be physically present to exploit the system.
An effective understanding of the communications each of your assets require is critical to being able to design and articulate your networks zones and conduits as described in IEC 62443-3-2. Having this documented will enable your organisation to implement effective network controls such as network segmentation.
At a minimum, you should be able to answer the following 5 questions for each asset in your architecture:
- What does the asset need to communicate with to perform its function?
- What communication protocols are required, and how are they secured?
- What architectural security controls are currently implemented in the OT system?
- What are the network constraints in your OT environment?
- Would a compromise allow an attacker to bypass existing controls?
1. What does the asset need to communicate with to perform its function?
You should maintain a clear record of the connections each asset has with other systems, devices, or services. This should clearly demonstrate which assets it depends on to function, and those assets that depend on it. This could include connections such as centralised control systems or remote database access.
As well as technical details, documentation on connectivity for all new and existing asset connectivity should include:
- a business case, detailing the connectivity requirement, which is centrally recorded and approved
- a reference to how the record is maintained in line with existing change management policies
- a process for periodic reviews to confirm the necessity of each connection against associated risks to the OT network and evolving threats
Additional risk assessments should be performed for external connections to assess if connectivity is required, as well as the security controls implemented.
When evaluating the requirement for a new external connection, you should consider the following:
- Avoid duplication: Instead of designing unique routes for each data flow, consider implementing a unified and secure data export pattern. Minimising duplicate data routes reduces management overhead and lowers the risk of misconfigurations in security controls.
- Establish control: Ensure that any data exiting the OT network is sanitised (removing sensitive material) and authorised (deemed suitable to be stored outside the environment). There should be safeguards in place to stop connectivity if required.
- Data security: Implemented connectivity should ensure that data leaving the OT network is encrypted both in transit and at rest. Particular attention should be applied to who requires access to the data, and the ongoing management of encryption keys. These controls should be designed in line with your information security management programme.
Data flow diagrams (DFDs) should be used to effectively record information about connectivity. Establishing a ‘single source of truth’ will reduce ongoing overheads and enable effective risk management.
Summary
You should have a maintained record of all necessary connections each asset has with other systems, devices, or services. This record should justify the need for each connection and document wider system or third party dependencies. Techniques such as DFDs are used to capture this information.
2. What communication protocols are required, and how are they secured?
A centralised record should be maintained which details the specific communication protocols (for example Modbus, DNP3, OPC UA) and the corresponding TCP/UDP ports required by each asset. This documentation is critical for configuring network equipment, such as firewalls, to enforce strict ingress and egress filtering.
Regular audits of these protocols should be conducted to ensure they adhere to current security standards. Where legacy or insecure protocols are in use (especially on external connections) organisations should seek to replace them with secure alternatives. If this is not feasible, compensating controls such as encapsulating traffic in additional protections (such as a VPN) should be implemented.
Protocol audits should also focus on ensuring the OT protocol incorporates the 3 pillars of the CIA triad. While availability is often prioritised in OT environments to maintain continuous system operation, a secure and resilient OT system requires a balanced approach that also safeguards data integrity and confidentiality.
- Confidentiality ensures that sensitive data within the OT system is protected from unauthorised access. This is especially critical for systems connected to external networks, where exposure to threats is higher. Protocol audits should evaluate how well the communication protocols safeguard data from eavesdropping or unauthorised disclosure.
- Integrity encompasses both the authenticity and accuracy of data. It ensures that the information such as sensor readings, control commands, or system configurations remains consistent and unaltered during transmission. Integrity also verifies that the data originates from a legitimate source, preventing unauthorised entities from issuing commands or manipulating system behaviour.
Implementing a balanced approach to the CIA triad in OT protocols helps block common attack vectors such as machine in the middle (MitM) attacks, packet replay, and the malicious use of legitimate commands
Key areas to document and audit are as follows:
- the use of cryptographic protections, such as digital signatures or secure authenticated protocols, including any key management or supporting infrastructure
- the use of compensating controls on communications, including how these are managed and maintained
- legacy protocol use, including reasons why they cannot be migrated to more modern protocols (and any plans to upgrade the asset out of service)
- how segmentation, additional monitoring or other complementing controls can manage this risk when protocol-layer security may not be feasible (such as in low-latency safety systems)
- the logging and monitoring of OT protocols within the system, including the protocols communications structure and flows
- normal traffic patterns (such as consistent packet sizes or used commands) as this understanding aids in identifying potential malicious activity on the network; variations in expected traffic could indicate issues or threats
Summary
For each asset you should have documented in use protocols, along with their corresponding TCP/UDP ports. This documentation should be used for configuring ingress and egress filters on firewalls. Additionally, a thorough audit of these protocols should have been conducted to ensure compliance with security standards, incorporating necessary encryption and integrity mechanisms.
3. What architectural security controls are currently implemented in the OT system?
Architectural security controls refer to any control that is implemented at a network layer level. As part of your definitive OT architecture record, you should document existing controls, which could include:
Network flow controls
This ensures that data only flows one way through the channel. Flow control does not stop a vulnerability being exploited within the destination system, but it can make it difficult for an attacker to perform command and control, export data, or simply learn more from the sensitive services being protected. A more capable attacker may look to use alternative export paths to exfiltrate data. Consider how resilient the control is. For example, it might rely on protocols like UDP, which need network enforcement. Alternatively, it could use fixed hardware such as a data diode, which is more resistant to change.
Continuous network monitoring and alerting
Maintaining persistent visibility enables you to detect anomalies, identify potential threats, and respond to incidents before they escalate. This should include monitoring the performance of critical systems and the application of security policies to ensure compliance with your organisation's standards. Monitoring should include rules based on an analysis of how your specific system could be attacked, and what would enable you to detect the attack.
Access control and centralised identity
Implementing centralised identity management enables you to enforce use of authenticated protocols so only permitted personnel have access to sensitive systems. This includes using multi-factor authentication, role-based access control (RBAC), and regular access reviews to reduce the risk of unauthorised access or insider threats. Proper access control measures not only protect critical assets but also aid in tracking user activities for compliance and auditing purposes.
Network segmentation
Network segmentation involves dividing the OT network into distinct zones to enhance security and reduce the attack surface. This control limits lateral movement and confines any potential breaches to a smaller segment of the network. By implementing techniques such as VLANs, DMZs, and dedicated subnets, organisations can enforce stricter policies and controls on which devices can communicate with each other. Segmentation also allows you to tailor security measures for specific components in your system, such as legacy systems that present additional risks. Granular segmentation enhances your overall resilience against attacks.
Protocol breaks
A protocol break will terminate the network connection, and the application protocol. The payload will then be passed via a simplified protocol to a receiving process, which re-builds the connection and passes the data on. A well-engineered protocol break will make a protocol-based attack against the destination system much more difficult
Content validation and inspection
Content validation enables you to gain assurance that data flows do not contain malicious data which could undermine the integrity of your OT environment. The NCSC has existing guidance on safely importing data and implementing secure application programming interfaces (API).
Isolation plans
Isolation can be a critical control of OT systems in an incident, removing connectivity to less-trusted systems. However, to ensure your organisation can isolate connectivity routes during an incident, it's important to clearly document potential impacts. This means that, if an incident occurs, you should know exactly how it will affect various systems, networks, and processes. These plans should also include how you will recover these systems and restore connectivity post incident.
You should use this information to evaluate gaps in your existing controls and determine areas needing further improvements. Frameworks such as the MITRE ATT&CK framework for ICS can be beneficial to map controls against potential attacks.
Summary
You should understand your existing architectural security controls and what protections they provide to the asset and the wider system. Network security controls should be designed to limit the ability for a compromised system impacting your wider OT network. The potential resulting impact from a compromise within the context of applied controls should be well understood and documented for effective risk management.
4. What are the network constraints in your OT environment?
When documenting OT networks, it is important to record any factors that could limit the ability to implement effective cyber security controls. This will help you to make informed decisions when planning future security programmes. These factors could include:
Bandwidth
What limitations are there on the data related to the asset, and how much of the available bandwidth is already being used by the OT process? If there is no spare capacity within the network, this may inform a need for future uplifts to support security functionality.
Exposure
Understanding the exposure of your data bearer is critical to inform the risk to data being carried. Over-the-air wireless bearers (including technologies such as Wi-Fi, Bluetooth and LTE) may pose additional risks due to them being openly accessible, this can drive the requirement for strong controls to handle jamming attacks and prevent replay or MiTM attacks.
Latency
Understanding acceptable latency levels is critical in shaping effective cyber security controls in time-sensitive environments like process control or emergency shutdown systems. High latency requirements may necessitate the use of lightweight encryption and/or streamlined authentication methods to avoid delays while maintaining essential security measures. There may be times where cyber security controls are avoided due to unacceptable added latency. Where this is the case, other mitigations through defence in depth should be in place.
Redundancy
What redundancy is in place in the system that would enable updating? Where are single points of failures where downtime is not feasible? Within redundancy, you should also seek to understand what backup communication routes would be used in the event the primary bearer fails. This backup bearer needs to be equally secure and not expose the OT system to additional risk.
Availability
Connectivity may need to be continuously available because it is critical to the function or resilience of the OT system. External functions with high availability requirements should be considered critical system dependencies.
Summary
The technical factors that may limit the implementation of cyber security controls in OT networks should be thoroughly documented. By identifying these constraints, organisations can make informed, risk-based decisions regarding future security enhancements. Effectively managing these limitations is essential to mitigate additional risks being exposed.
5. Would a compromise allow an attacker to bypass existing controls?
When assessing external connectivity into your OT network, it’s important to understand how compromised routes or assets could impact connected systems. This could include - but is not limited - to considerations such as:
Security of edge routers in your WAN
What systems would an attacker be able to directly access if they compromised the edge router in your OT WAN? Your organisation should have confidence that defence-in-depth controls would prevent an attacker being able to reach directly into the critical OT components from this style of compromise.
Unsecured connectivity into your OT network
This could be the use of unsecure OT protocols between organisations that might not support security controls. You should consider how you prevent this data being manipulated to cause an impact in your OT system without requiring an attacker to directly compromise the system.
Legacy connectivity into the core OT network
This could include exposed wireless communication channels that do not support adequate encryption or authenticity controls. You should understand the scale of impact if one of these accesses is compromised.
If security compromises have been necessary in the external connectivity, you should have mitigating controls in place to limit the potential impact of a threat actor if a compromise occurs.
Summary
Your organisation should have a comprehensive understanding of the potential impacts of compromised external connectivity into the OT network. Where security compromises have been made, mitigating controls should be in place to limit the potential impact.
