What is OT security, and why can't you run it like IT security?

OT is the computing that moves, measures and protects physical things: the relays that trip a breaker, the drives that spin a pump, the controllers that hold a process inside its limits. OT security is the practice of protecting that layer without interfering with the thing it controls.

That last clause is the whole difficulty. An IT security control that fails closed locks someone out of email. An OT control that fails closed can open a breaker.

20–30 yrs

typical service life of the equipment being protected

5

ordinary decisions that bridge an air gap

6

practices that work

The priorities are inverted

IT security is usually taught as confidentiality, integrity, availability, in that order. OT runs the order backwards. If a plant cannot be operated, nothing else about its security matters, and an operator who cannot see the process will shut it down rather than run blind.

None of this makes OT teams less rigorous. It makes a control that is routine in IT, such as forcing a reboot or pushing an agent or blocking an unrecognised protocol, into something that has to be argued for asset by asset.

Why the old defense stopped working

For most of their history these systems were defended by being unreachable. No routable path existed, so no remote attack did either. That defense has eroded, and rarely by decision. It goes one reasonable step at a time.

• A vendor needs remote support, so a cellular modem goes into a cabinet for a commissioning visit and is never removed.
• Reporting needs plant data, so the historian replicates to the corporate network.
• An engineering workstation needs an update, so it becomes dual-homed.
• A contractor needs to move a file, and a USB drive crosses the gap that the network no longer has to.
• Someone adds condition monitoring, because knowing the transformer is degrading is worth something.

Every one of those is defensible. Together they mean the air gap on the drawing and the network you operate are different things, and nobody owns the difference.

Zones and conduits: the vocabulary that helps

IEC 62443 gives OT a usable way to talk about this. Group assets with similar risk into a zone. Every path between zones is a conduit, and each conduit is named, justified and controlled. The value is not the jargon; it is that the question changes from "is the plant connected?", which is nearly always yes, to "how many conduits are there, who owns each one, and what would it take to close it?"

The Purdue model supplies the layers those zones usually follow, from the physical process at Level 0 up to enterprise IT at Levels 4 and 5, with an industrial DMZ at Level 3.5 where external conduits belong.

Where monitoring fits

Monitoring carries data from the equipment to a person in an office. That crosses every layer. No remote monitoring adds zero exposure. The question is whether the exposure was designed or inherited.

A monitoring deployment worth accepting looks like one more governed device in the DMZ, opening one outbound conduit your team wrote and can close. A deployment worth refusing asks for an inbound rule because that was easier to build.

Practices that hold up

Inventory before anything else.

You cannot protect or segment what you cannot list. Most programs stall here, and the ones that skip it protect a network they do not have.

Segment by consequence.

Group assets by what happens when they fail, not by which cabinet they share. A safety instrumented system does not belong in a zone with the site's printers.

Count your conduits.

Every path in or out, including the vendor laptop and the cellular modem. A conduit nobody owns is the one that stays open.

Prefer read paths.

Anything that only needs to observe should be unable to act. It removes a whole class of incident rather than mitigating it.

Monitor the monitoring.

Telemetry that stops arriving is a security event as well as a reliability one. A blind asset is the most dangerous state available.

Rehearse the failure.

Decide in advance what happens when the link drops. If the answer is unknown, the answer is that the plant finds out at the worst time.

Common questions

Is OT security just IT security applied to a plant?

No, and treating it that way is how programs fail. The priorities invert, the asset lifetimes are an order of magnitude longer, and many OT protocols were designed with no authentication because the network was assumed to be private. Controls have to be chosen for that reality rather than imported.

Do we need to replace equipment that cannot be patched?

Usually not, and usually you cannot. Long-lived equipment is protected by controlling what can reach it rather than by changing it: segmentation, and compensating controls around the zone. That is the practical reason zones and conduits are the organising idea.

Does adding condition monitoring weaken our security posture?

It adds a path, and pretending otherwise is the failure mode. Whether it weakens the posture depends on the direction the path opens, whether it can write, where it terminates, and whether you can close it without the vendor's cooperation. Those are answerable questions and worth asking of every vendor, including us.

Where does compliance fit?

Compliance regimes such as NERC CIP set a floor for specific asset classes rather than a complete program. Meeting the floor is necessary and is not the same as being secure; the sites we see with the fewest incidents treat the standard as the start of the inventory work, not the end.