OT Security

OT security is the security of operational technology: the computers and networks that monitor and control physical processes. Pumps, valves, motors, breakers, furnaces, conveyors, turbines. It is a different discipline from IT security, and the difference is not cosmetic.

What makes it different

IT security ranks confidentiality, integrity, availability, in that order. OT reverses it, and adds one above all of them:

IT:   Confidentiality  >  Integrity  >  Availability
OT:   Safety  >  Availability  >  Integrity  >  Confidentiality

A leaked document is bad. A production line stopping costs money by the minute. A safety system failing kills people. That ordering explains nearly every behaviour that looks negligent from an IT perspective:

Patching is rare. Applying an update means stopping the process. Downtime windows are scheduled months ahead, and a vendor-certified configuration may be contractually frozen. Ten-year-old unpatched Windows on an engineering workstation is normal, not exceptional.
Lifecycles are decades. A PLC installed in 2005 is expected to run until 2035. It has no capacity for modern cryptography and no firmware update path anyone is willing to use.
Scanning is dangerous. An ordinary nmap SYN sweep has knocked PLCs offline. Devices with tiny TCP stacks can fail on traffic a desktop would ignore, and a device failing here moves something physical.

The protocols have no security

Modbus, DNP3, S7comm and their siblings were designed for isolated, trusted serial links in the 1970s and 1980s. They have no authentication, no integrity protection and no encryption. Anyone who can reach the port can read any register and write any coil. There is no exploit involved: writing a value is the protocol working exactly as specified.

This is why network position, not vulnerability count, is the thing that matters in OT. Later designs (OPC UA, Modbus/TCP Security, DNP3 Secure Authentication) add real cryptography, but they are deployed slowly and are frequently configured with security disabled for interoperability.

Segmentation as the primary control

Since the endpoints cannot defend themselves, the defence is architectural: keep the attacker off the network in the first place. The purdue-model is the reference layering, and the practical controls are a hard boundary between enterprise IT and the process network, a DMZ for the data historian so nothing on the business side ever talks directly to a controller, unidirectional gateways where the data flow genuinely is one-way, and no dual-homed engineering workstation bridging both sides.

The recurring real-world failure is not a clever exploit. It is a laptop, a vendor remote-access tunnel, or a forgotten cellular modem that quietly connects the two worlds.

What an attack looks like

The interesting objective is rarely data. It is process manipulation: changing a setpoint so a physical quantity drifts out of tolerance, forcing an output so an actuator moves, or falsifying what the operator sees on the HMI so the drift is not noticed. That last part matters, because a well-run process has humans watching it. An attack that moves a valve and leaves the display honest gets caught in minutes.

Safety instrumented systems are a separate, independent layer designed to bring the process to a safe state regardless of what the control system does. Attacks that target the safety layer itself are the ones that turn a costly incident into a lethal one.

Pitfalls

Treating an OT network like an IT network. Aggressive scanning, agent deployment and forced reboots cause outages. Prefer passive traffic capture and vendor-native discovery.
Assuming air-gapped means isolated. Almost no network claimed to be air-gapped actually is; the exceptions are the ones where somebody checks quarterly.
Reporting a Modbus write as a vulnerability. It is not a flaw in the device, it is the protocol as designed. The finding is the reachability, not the write.

What it pairs with

purdue-model gives the layering, plc and scada the components, and modbus, dnp3, s7comm and opcua the protocols themselves.