You Cannot Unplug a Turbine

The response action that does not exist in a plant

Enterprise containment works because the worst case of being wrong is an inconvenienced user. A laptop quarantined in error costs somebody an afternoon. That asymmetry is what makes aggressive, automatic containment reasonable on the IT side, and it is the assumption the entire playbook rests on.

Move the same playbook across the boundary and each verb loses its meaning. The endpoint may be a controller holding a setpoint for a process that is exothermic, or molten, or pressurised. The account may be a service account three control loops authenticate through. The network segment may carry the only path between a supervisory server and a line that has to be told to stop in the right order.

None of this makes an industrial environment unresponsive. It makes the response a joint decision with a cost attached, and that single difference is what most OT security programmes have not yet absorbed from their IT counterparts.

Three constraints that decide what you are allowed to do

Safety comes first and is not negotiable. Most hazardous processes run with a safety instrumented system whose only function is to bring them to a safe state when a defined condition is met. Any security action that could trip it, delay it, or make its state harder to read is an engineering judgement before it is a security one, and the judgement is not a security team's to make.

Availability is second, and in industrial settings it is frequently a component of safety rather than a commercial preference. A controlled stop is a sequence, not a switch. For some processes there is no clean place to pause, and a restart can take hours and consume material.

Change control is third and is the one most often forgotten in a hurry. An industrial estate runs under management of change, and a containment action is a change. The procedure exists because an unreviewed change once hurt somebody, and an incident is a bad moment to discover that your response plan quietly assumed an exemption nobody has granted.

• Devices that cannot take an agent, because nothing supported will install on them.
• Devices that cannot be rebooted outside a maintenance window, which may be months away.
• Protocols with no authentication, where a command is accepted because it arrived rather than because of who sent it.
• Vendor support agreements that are voided by unapproved changes to the system.

Containment here is a graded set, not a switch

The useful reframing is that containment in an industrial environment is a ladder rather than a binary. At the top are actions that cost nothing and need nobody's permission. At the bottom is a production decision that a plant manager signs. Most organisations have written down only the bottom rung, which is why their real options during an incident are to do nothing or to stop.

The top two rungs should be automatic and should already be running. Raising capture fidelity on an affected asset costs nothing and risks nothing. Producing an alert that names the asset, the control loop it belongs to and the sequence observed is likewise free, and it is the difference between handing operations a problem and handing them a decision.

The middle rungs are where most real containment happens, and they are the ones that depend on architecture rather than on courage. Narrowing a conduit or cutting a single remote session can stop an intrusion progressing without touching the process at all, but only if the paths between zones were defined well enough that there is something specific to narrow.

The standards already gave you the vocabulary

IEC 62443 models an industrial estate as zones and conduits. A zone is a grouping of assets with common security requirements. A conduit is the communication path between zones, with its own requirements and its own definition of what is permitted to traverse it.

That model exists for engineering reasons, and it happens to describe exactly where proportionate containment is available. Acting on a conduit is almost always safer than acting on an asset, because a conduit can be narrowed to what it was defined to carry while the process on either side of it continues to run.

The catch is that a zone and conduit model which exists only on a drawing gives you nothing during an incident. If nobody can say what the conduit between the supervisory zone and the control zone is actually permitted to carry, then there is no narrowing available, and the ladder collapses back to the choice between ignoring the alert and stopping the line.

• Zones defined by what the assets do and what they require, not by which switch they happen to share.
• Conduits with a written definition of the protocols, endpoints and directions they carry.
• An asset inventory that operations recognises as correct, because they will be asked to act on it.
• A record of which loops depend on which conduits, so the consequence of narrowing one is known before it is narrowed.

The responder is an engineer, and the artefact that matters is evidence

Security does not get to act alone here, and should not want to. The person who knows what happens physically when a conduit is narrowed is a controls engineer, and the decision is a joint one between two functions with different training and different priorities.

What that engineer needs is not an anomaly score. A detection that reports anomalous industrial traffic at high severity gives operations a binary they cannot resolve: ignore it, or stop something. Neither option is proportionate and both are defensible afterwards, which is why the argument tends to be settled by whoever is most senior in the room rather than by the evidence.

A detection that reports which asset, which control loop, which peer it spoke to, which function codes in which order, and how that compares with the asset's own established pattern leaves a proportionate action available. The conversation changes from whether this is real to which rung of the ladder it justifies, which is a conversation two engineers can have in ten minutes.

Why the time pressure sits in the understanding, not the action

There is a tempting conclusion from all of this, which is that automation has no place in industrial response. The conclusion is half right and the wrong half is widely repeated.

The action should be slow. It should involve a human who understands the process, it should be authorised, and it should be logged. Nobody should ship a product that reaches into a plant and starts changing things on a model's say-so, and a pre-written playbook that executes whatever happens is a worse idea in a plant than anywhere else, because the plant is the one place where the consequences are physical.

The understanding should not be slow. Reconnaissance in industrial environments runs over months precisely because it is patient, and the defender's remaining advantage is that long window. Compressing the time it takes to turn an observation into an evidenced finding from an hour to a minute does not remove the engineer from the loop. It gives the engineer the whole window to decide in, instead of the tail end of it.

• Autonomous investigation, which produces the finding and the evidence behind it.
• Human authorisation, which selects the rung and accepts the consequence.
• A record of both, which is what the post-incident review and the regulator will read.

Write down who may do what, before you need it

Most industrial incident response plans are written at the level of a flowchart and fail at the level of a signature. They say that containment requires operational approval and do not say who provides it at three in the morning on a public holiday.

The artefact worth having is narrower than a plan. It is a table with one row per specific action: narrowing this conduit, cutting remote access for this vendor, isolating this cell. Each row names who authorises it, who covers them out of hours, what evidence has to be presented first, whether a safety review is required before it, and what gets recorded.

Building that table surfaces the gaps while it is cheap to surface them. Teams routinely discover that an action everybody assumed was available requires an approval nobody has the authority to give at night, which is a far better thing to learn in a workshop than during an intrusion.

What a plant should expect from its monitoring

The requirements that follow from all of this are specific, and they are not the requirements an enterprise detection tool is built to meet.

Monitoring has to be passive by default, because an active scan against a device that was never designed to be scanned is itself an incident. It has to understand the protocols at the level of function codes and parameters rather than ports. It has to know which asset belongs to which loop, because that is the unit a responder acts on. And it has to be able to answer the question operations will ask first, which is what would be affected if we did this.

MITRE ATT&CK for ICS is the useful shared vocabulary for the rest: an unauthorised command message, a modified parameter, a stopped service. Naming what was observed in those terms gives two functions who do not share a professional language something they can both read.

• Passive observation as the default, with no packets sent to production assets.
• Protocol awareness at the level of function codes and parameters, not port numbers.
• Asset and control loop context attached to every finding.
• A clear statement of blast radius, so a proportionate rung can be chosen.

The honest version

Industrial incident response is harder than its enterprise counterpart for reasons that are not going away. The constraints are real, the authority is genuinely shared, and the correct answer to most alerts is a smaller action than a security team would instinctively take.

What is fixable is the part that has been accepted as inevitable. The reason so many industrial organisations have only two response options is not that the ladder does not exist. It is that the middle rungs depend on an architecture that was never finished and on evidence that their monitoring does not produce.

Both of those are projects rather than mysteries. A conduit inventory is work. A detection that names loops instead of scoring packets is a procurement decision. Neither requires anybody to unplug a turbine, which is just as well, because nobody is going to.