Operational technology (OT) comprises the hardware and software that monitor and control physical processes: the PLCs that operate valves, the SCADA systems that run pipelines and power networks, and the safety instrumented systems that bring a plant to a safe state when conditions deviate. As these systems are connected to enterprise networks and the internet, they inherit cyber threats. They do not inherit the assumptions on which IT security is built.
Different priorities
In IT, the conventional order of priority is confidentiality, integrity and availability. In OT that order is typically reversed, and safety takes precedence over all three. A data breach is a serious incident. A process controller that receives a manipulated set point can cause injury, damage high-value equipment and halt production for weeks.
This changes what “secure” means. A control that blocks unrecognised traffic may be appropriate in an office network and hazardous on a control network, where an unexpected block can cause a process trip.
Different lifecycles
Enterprise endpoints are refreshed every few years. A distributed control system may remain in service for twenty years or more, often on operating systems beyond vendor support. Patching typically requires a planned outage, vendor qualification and testing, so updates applied within days in IT can take a year or longer in OT. Security architecture must therefore accommodate equipment that cannot readily be upgraded.
Different networks
Industrial protocols such as Modbus, and earlier versions of many proprietary protocols, were designed for closed and trusted networks. Many lack authentication, so any device able to reach a controller can issue commands to it. Network segmentation, rather than endpoint software, is therefore the primary line of defence.
The Purdue model, referenced throughout IEC 62443 and many national OT frameworks, describes the hierarchy from field devices to enterprise systems. Its central principle is straightforward: traffic between IT and OT should be brokered through a controlled industrial DMZ, and no internet-facing system should communicate directly with a controller.
Effective practices
- Maintain asset visibility. An accurate inventory of controllers, HMIs, engineering workstations and network devices, including firmware versions.
- Segment zones and control conduits. Define zones by function and criticality, and permit only the traffic each conduit requires.
- Secure remote access. Route vendor and engineering access through a managed jump host with multi-factor authentication and session recording, rather than persistent VPNs or unmanaged remote desktop tools.
- Monitor passively. Passive network monitoring detects new devices and anomalous commands without introducing risk to the process.
- Align change with operations. Schedule patching and hardening within maintenance windows, and record deferred items as risks with accountable owners.
- Validate recovery. Maintain tested, offline backups of controller logic and configurations, and rehearse restoration.
Bringing IT and OT together
The most effective OT security programs are collaborative. IT security contributes threat intelligence, monitoring capability and governance. Engineering contributes process knowledge and the authority to determine what is safe. A shared risk register, written in terms both functions understand, is often what aligns them.