Operational Technology
Page 14 of 37
Principle 4: Use standardised and secure protocols
In addition to securing the networks and devices used to establish communications, your organisation must also consider the security of the protocols employed.
As outlined in Creating and maintaining a definitive view of OT architecture, it is common for industrial environments to prioritise availability over the confidentiality and integrity of communications. It is essential that all components of the confidentiality, integrity & availability (CIA) triad are considered. However, you may prioritise different aspects of CIA depending on the connection. For instance, in field networks, authentication and integrity are essential to limit an attackers' ability to send malicious traffic. Conversely, in north-south traffic at network boundary points, encryption becomes critical to prevent attackers from discerning information on how to impact the system.
Protocol validation
Protocols used within and between your network environments should feature data formats to enable simple validation of both the protocol and its data. To ensure that traffic is expected and within acceptable bounds, schemas should be applied to these data flows. Data simplicity is key as it reduces the attack surface and makes it more difficult for adversaries to inject malicious data.
Schemas should be used to inspect and verify protocols and data payloads at key trust boundaries. These boundaries may exist between networks (for example the OT/IT boundary) or between services (for example in front of SCADA control software or a programmable logic controller). Ideally, verification should be schema-based and follow a ‘known good’ model, only allowing traffic that conforms to expected structures and values.
When validating data, consider any nested or encoded content. For example, a field might contain a base64-encoded value. A basic check might verify the length or format of the base64 string, but a more robust approach would decode the value and validate the underlying data against expected patterns or constraints.
Industrial protocols
When evaluating industrial protocols within your OT environment, you should:
-
Default to the latest secure versions of industrial protocols (e.g. DNP3 to DNP3-SAv5, CIP to CIP Security, Modbus to Modbus Security, OPC DA to OPC UA).
-
Ensure that protocols support cryptographic protections for authenticity and integrity, such as digital signatures. Your protocol use should be flexible, enabling you to update to new cryptographic algorithms. In particular ensure protocols support ‘crypto agility’, the ability to switch and update cryptographic algorithms, to ensure the lifetime of the product is matched by the lifetime of the cryptographic algorithm. Where there are no hardware constraints, crypto agility is likely to enable you to migrate to post-quantum cryptography algorithms when and where required.
-
Prefer protocols that support open standards and interoperability to facilitate vendor-agnostic solutions. This approach can help reduce the number of bespoke data flows between environments, thereby decreasing complexity within your architecture. Pay special attention to security functionality as interoperability issues can break the entire communication stack rather than a specific proprietary function.
-
Require a business case for the use of insecure protocols within your environment, making their use the exception rather than the norm. For instance, in time-critical safety applications, encryption may not be feasible. However, compensating controls should be implemented to manage associated risks, and it is critical these controls are documented as part of your risk management framework.
Where your organisation has insecure industrial protocols in use, you should establish a roadmap for migration to secure industrial protocol variants. This will enable you to make considerations to enable this in asset uplifts and system maintenance.
Tip: Use resources published by your manufacturer to support your development of a migration plan. This could include:
|
Industrial control protocols (Modbus, OPC DA, EtherNet/IP, etc.) should be restricted to isolated OT network segments. External connections for data exchange between OT and IT should be brokered through a DMZ and use secure, standardised protocols designed for interoperability (such as OPC UA over TLS, MQTT over TLS, HTTPS). Where operational data needs to be shared, replicate the OT historian to a historian instance in the DMZ via a unidirectional, secure transfer mechanism, ensuring no inbound connectivity from IT to OT. IT systems should query the DMZ historian via a secure HTTP-based API with strong authentication, rather than directly accessing OT systems.
