Why “passive” is the only safe first step on a running line

A plant has one question about any security work on its network: will the line keep running. In a food or beverage plant a filler that stops is spoiled product and a wasted clean-in-place cycle. In a pharmaceutical plant a qualified system that stops is a deviation, an investigation and possibly a lost batch. Everything else about an assessment, its scope, its report, its findings, comes second to that question, and it should.

This is why the first step has to be passive. Not because passive is perfect, it is not, but because the alternative asks the controllers to do something they were never built to do.

What an active scan does to a controller

An active scan is a tool from the office network. It sends a packet to every address in a range and asks what is there, then usually goes back to each address that answered and tries its open ports, asking what software sits behind them. On office equipment this is harmless. A laptop or a server is built to receive unexpected traffic all day and discard what it does not want.

A controller is not built that way. A PLC commissioned a decade or more ago runs a small network stack with a small buffer, designed to talk to one HMI and one engineering workstation in a protocol it expects. A burst of unfamiliar packets, or a single malformed one, can fill that buffer, trip a watchdog or put the processor into a fault state, and when the processor faults the line stops. The same is true of older drives, protocol gateways and some instruments. NIST SP 800-82 Rev. 3 says as much in general terms: tools built for IT networks can disrupt OT equipment, and their use needs planning and care.

There is a second cost in a regulated plant. A scan that reaches a validated controller is an undocumented interaction with a qualified system, whether or not anything faults. The quality team has a word for that, and it is not a word anyone wants on a batch record.

A scan that stops the line has already cost the plant more than most of the risks it was looking for.

What passive observation is

A passive assessment works from a copy of the traffic rather than from questions. The plant’s switch is told to copy the packets passing through a chosen set of ports onto one spare port, a mirror port, and a capture device on that port records what it sees. Nothing is sent into the network. The controllers do not know it is happening, because from their side nothing has happened.

The record is richer than it sounds. Every controller, HMI, historian and workstation on the mirrored segment announces itself in the course of ordinary work: its address, the protocol it speaks, the devices it polls and the devices that poll it, how often, and what crosses the boundary into the office or out of the plant altogether. Many industrial protocols carry the vendor and model in their normal chatter, and some carry the firmware version. From a few days of capture, an asset list and a map of who talks to whom can be built without a single packet having been sent to a controller.

What passive cannot tell you

It is worth being plain about the limits, because a method that oversells itself is a method a plant stops trusting.

Passive only sees what talks. A device that is powered but silent during the capture window is invisible: a vendor’s modem that only dials when the vendor calls, a workstation that was switched off that week, a spare controller on the shelf but still patched in. It only sees what passes the mirrored ports, so an unmanaged switch under a machine hides the conversations inside it. It infers model and firmware from traffic rather than asking, so some fields in the asset list stay blank, and the blanks have to be named as blanks rather than filled in from a guess. And it tells you what is present and reachable, not whether a given weakness could be used; that is a different question, answered later and only with authorisation.

The other limit is the one most often skipped over. A mirror port is itself a change to a live switch. Someone logs into a production switch and alters its configuration. On a busy switch, copying many ports onto one can oversubscribe the destination so that the copy drops packets, which spoils the capture rather than production, but on some older or smaller switches a configuration change has a real cost in processor time. Where a switch cannot be touched at all, the alternative is a network tap, and a tap is an in-line insertion that interrupts the link for a moment while it goes in, which makes it a maintenance window question.

A mirror port is a change to a live switch. Passive is lower risk, not no risk, and the difference is that the risk is known and written down.

So “passive” is not “risk-free”. It is lower risk by a wide margin, and the risk it does carry is small, known and manageable: one switch at a time, by the plant’s own network person or beside them, at a time the production plan allows, with the previous configuration kept so the change can be undone in a minute.

How a passive-first engagement is sequenced

The sequence starts on paper. The drawings, however old, the production plan for the coming weeks, and the names of the people who own each switch come first, because they decide where it is safe to capture and when. Written authorisation names the switches, the ports and the window before anyone opens a cabinet. In a pharmaceutical plant this is also where the quality team confirms that a mirror on a network switch is a documented network change, not a change to a validated system, and records it that way.

Capture points are chosen at the boundaries rather than at the machines: where the lines meet the supervisory layer, where the plant meets the office, and where the utilities join. Those are the places a few ports see the most. The capture runs long enough to cover a full shift pattern and at least one changeover or batch, because the recipe traffic, the lab transfer and the vendor check-in each happen on their own schedule and the window has to include them. While it runs, someone walks the cabinets, because the walk-down finds what the capture cannot.

Then comes the report, in writing: the asset list with its blanks marked, the map of conversations, the crossings in and out of the plant ranked by what each would allow, and a note on each remote link. Only after that, and only if a blank needs filling, does anything active come into view, and then narrowly: a single query to a single device, in a maintenance window, with written authorisation and a named person beside the work. On most sites of this kind that step is never needed. The method is built so that it can be skipped without losing anything the plant needs.

NIST SP 800-82 Rev. 3 · guide to operational technology security

ISA/IEC 62443-3-2 · zones, conduits and risk assessment

Why this is what the plant cares about

Uptime is not a constraint on the assessment. It is the point of it. The reason to know what is on the network, and what reaches it from outside, is to keep the filler filling and the reactor at temperature, and a method that risks either in order to find out has the priority backwards.

Passive-first keeps the work inside the plant’s own rules. No controller is touched, so no change control is opened against a qualified system. No line is stopped, so no product is lost to the assessment itself. The result arrives in writing, and the plant decides what to do with it at its own pace, around its own production plan. ISA/IEC 62443-3-2 asks a plant to know its zones and the conduits between them before it assesses risk; listening is how a plant comes to know them without paying for the knowledge in downtime.

Sources · NIST SP 800-82 Rev. 3 (guide to OT security, including the use of scanning tools); ISA/IEC 62443-3-2 (zones and conduits).