Most of Your Plant Will Never Be Patched

A programme that produces a number nobody can act on

Enterprise vulnerability management works because its central assumption holds: if something is vulnerable, it can be patched, and the only real questions are how soon and with how much disruption. Everything downstream, the scoring, the service levels, the monthly trend line, follows from that assumption.

In an industrial environment the assumption fails for most of the estate most of the time. The question is not how soon the patch goes on. It is whether a patch exists, whether the vendor has validated it, whether the device can be restarted this side of the next planned outage, and whether applying it breaks something that somebody signed.

What that produces is a backlog that grows every month and is worked almost not at all. It is presented as a programme and read as a failure, when it is really a list of risks the organisation has already decided to live with, written in a format that hides the fact that a decision was taken.

Five reasons the patch is unavailable

It is worth separating these, because they call for different answers and only one of them is a vendor problem. A fix that does not exist is a procurement and lifecycle conversation. A fix that exists but has not been validated for this configuration is a schedule. A fix that needs a restart is a question for the outage calendar, which in some plants is annual.

The two that most often go unspoken are the last pair. Patching outside a vendor's process can void a support agreement, and in a safety-related system it can invalidate a certification that took months to obtain. Neither of those is bureaucratic obstruction. They are the mechanisms by which somebody takes responsibility for the plant behaving as designed.

And then there is the end of support case, which is the largest category in most older estates and the one nobody likes writing down. The device works. It has run the process correctly for fifteen years. There will never be another release for it, and it will still be running when everyone currently arguing about it has left.

A severity score describes the software, not your plant

CVSS is a useful common language and it answers a question about a flaw in the abstract: how bad would this be on a general-purpose system that an attacker can reach. Both halves of that sentence are doing work, and in an industrial environment the second half is usually false.

A 9.8 on a controller sitting inside a segmented cell that only one engineering workstation is permitted to address is a different risk from a 7.5 on that workstation, which is permitted to address every controller on the site. Ranked by score, the controller is at the top of the list for years and the workstation is somewhere on page four. Ranked by what can actually reach what, the order inverts, and the second list has actions available against it.

This is the same position the site takes for enterprise estates, where a new finding is ranked by exploitability and asset criticality rather than by score. It matters more in a plant, because in a plant the top of a severity-ordered list is reliably the part of the estate you can do least about.

Exposure is a property of the conduit, not the device

IEC 62443 describes an industrial estate as zones and conduits: groupings of assets with common security requirements, and the defined communication paths between them. The model exists for engineering reasons, and it happens to describe exactly where the usable controls are.

Phrase a finding as a property of a device and there is one action available, which is patching, which is the thing you cannot do. Phrase the same finding as a property of a path and several actions appear. What is permitted to traverse this conduit. Which hosts. Which protocols. In which direction. Whether the engineering workstation needs that reach continuously or only during a change.

None of those touch the device, none of them require an outage, and all of them reduce the exposure the finding depends on. The vulnerability is still there and the risk is not. That distinction is the whole of industrial vulnerability management, and it is unavailable to any programme whose inventory is a list of hosts rather than a map of zones.

• Conduits with a written definition, so there is something specific to narrow.
• An asset inventory operations recognises as correct, because they will be asked to act on it.
• A record of which loops depend on which paths, so the consequence of narrowing one is known in advance.
• Engineering workstations treated as the high-value assets they are, since they hold the reach.

When you cannot remove the flaw, you have to see its use

There is a rung on that ladder that most programmes leave out, and it is the only one available for every finding without exception. If a vulnerability cannot be removed and its exposure cannot be reduced to zero, then the remaining control is detecting the thing an attacker would have to do in order to use it.

In an industrial protocol that is a concrete statement rather than a hopeful one. Exploiting a controller means speaking its protocol: particular function codes, particular parameter writes, particular sequences, from a peer that may never have addressed that device before. Passive observation that understands the protocol at that level can describe exactly what would be seen, which turns a detection from a promise into a specification.

This also reframes what the detection is for. It is not a second opinion on the scanner. It is the compensating control that lets the organisation say, in writing, what happens when somebody uses a flaw it has chosen not to remove, which is a sentence an auditor can actually evaluate.

What a defensible programme looks like

The shift is from counting findings to recording decisions. A finding that has been consciously accepted, by a named role, with a compensating control stated and a review date set, is in better shape than an identical finding sitting unresolved at the top of a severity-ordered backlog, even though the device is in exactly the same condition in both cases.

That is not an accounting trick. The difference between the two is that in the first case somebody looked at the plant, decided, and wrote down what would be true if they were wrong. In the second, nobody did, and the report is standing in for a conversation that never happened.

The practical test is whether the register can be read by an engineer. If a row names a host and a CVE, it is an IT artefact that has been pointed at a plant. If it names the asset the way operations names it, the loop it belongs to, the conduits that reach it and the decision taken, it is a document two functions can work from.

The paperwork is not the bureaucracy, it is the deliverable

Teams often resist this because the output looks like documentation rather than security work. It is worth being clear about what the documentation is doing.

A regulator, an auditor, an insurer or a customer running a supply chain assessment does not expect an industrial estate to have no vulnerabilities. They have seen plants before. What they ask is which ones you know about, what you decided, who decided it and what would happen if the decision turned out to be wrong. An untouched backlog answers none of those. A register of decisions answers all four.

It also survives staff changes, which an informal understanding does not. The reason a particular conduit is narrow, or a particular workstation is restricted, is usually a compensating control for a finding nobody can patch, and if that is not written down it will be reversed by somebody reasonable within three years.

Where this leaves the scanner

None of this is an argument against knowing what is vulnerable. The inventory and the findings are the input, and without them there is nothing to make decisions about.

It is an argument against treating the output as a work queue, and against the particular failure mode where an industrial estate is measured by a metric that was designed for an estate that can be patched. That metric will never improve, the trend line will embarrass everybody who presents it, and the energy will go into explaining the number rather than into narrowing the conduits.

The programme that works measures something else: what proportion of findings have a decision recorded against them, how many have a compensating control that is actually in place, and how many have detection coverage that somebody has specified rather than assumed. Those numbers can improve in a plant that is never going to be patched, which is most plants, which is the point.