Harden the line you cannot patch

The patch you cannot run

A programmable logic controller on a running packaging line does not get patched on a Tuesday because a vendor released an update. It gets patched during the next planned turnaround, months away, when the line is down anyway and a reboot will not stop production. Between now and then, the vulnerability is simply there.

That is the starting condition for hardening, not an excuse to skip it. Hardening a line you cannot patch means segmentation that keeps a compromised device from reaching the rest of the plant, compensating controls that reduce what a weakness can do, allow-lists that only let known traffic through, and read-only paths where a two-way connection was never actually needed.

None of that replaces patching. It is what covers the line while the patch waits for its window, and often for years after, because some devices on the floor never get an update at all.

Where an attacker would actually be stopped

Secure architecture starts with a plain question. If someone got into this network today, where would they be stopped, and by what. On a lot of plant floors the honest answer is nowhere yet. A flat VLAN, a firewall rule that allows any to any because it was faster during commissioning, a switch port left open from a project that finished years ago.

The program trains operators to trace the paths an attacker would actually use, not the ones a diagram implies. MITRE’s ATT&CK framework for ICS lays out the moves attackers make once they are past the perimeter, from an engineering workstation to commands sent straight to a controller. Knowing those moves is how you decide where a boundary has to hold.

A secure architecture is not one firewall at the edge of the plant. It is a series of boundaries, each one assuming the last might fail, so a single misconfigured rule does not hand over the whole line.

Which weaknesses matter when you cannot patch

A vulnerability scanner returns a long list, and a CVSS score on its own does not say which item on that list actually matters on your line. A critical score on a device nobody can reach from outside the cell is a different problem than a moderate score on a device sitting next to an engineering laptop a contractor takes home every night.

Threat and vulnerability management in OT starts from exploitability and consequence, not the score alone. Can an attacker actually reach this device from where they can already stand. What does the process do if the device stops responding, or responds wrong. The program trains operators to weigh both before deciding what gets attention first.

• Whether an attacker can reach the device from where they already have a foothold
• What the process does if the device stops, or does the wrong thing
• Whether a compensating control already sits between the weakness and the process
• How the finding changes once the exposed protocol and the actual traffic are known

The door most attackers actually use

Vendor and integrator remote access is the most common real path into an OT network, more often than an internet-facing PLC. A vendor needs to reach a drive controller three time zones away, an integrator needs to pull logs off an HMI, and the fastest way to get that done becomes the way it gets done every time after.

The program trains operators to secure that access on purpose instead of around it. That usually means a jump host or session broker sitting in the DMZ, multi-factor authentication, a session that is time-boxed and recorded, and a vendor who can reach only the one asset they came to touch.

It also means finding what grew up over the years outside that path: a cellular modem wired straight into a panel, remote desktop software installed on an HMI so a vendor did not have to wait for a badge. Those bypasses work exactly like the approved path, except nobody is watching them.

What a test can do without touching production

An ICS penetration test is not the same exercise as an IT penetration test, and treating it that way is how a test takes down a line. The question a test answers is how far it can go without touching production, and the answer sets the rules before the test starts.

Most of the useful work happens without a single packet reaching a live controller: passive capture off a switch mirror port, a test bench built from the same PLC model and firmware running in a lab, a review of the configuration itself, the open ports, the default credentials, the protocols left unauthenticated by design. Modbus/TCP on port 502 and S7comm on port 102 were never built to check who is asking.

A tester stops before the PLC, not because the finding stops mattering there, but because a crafted command to a controller running a real process is not a finding worth causing. The program trains operators to read a test report for what it could not check, not only for what it found.

Levels, zones and the links that skip them

The Purdue model gives a plant a vocabulary for deciding who may talk to whom. Level 0 and 1 are the field devices and the PLCs that run the process. Level 2 is supervisory control and the HMI. Level 3 is site operations. A Level 3.5 DMZ separates the plant from Level 4, the enterprise network, and IEC 62443 groups those levels into zones that are only supposed to reach each other through a conduit.

The model is only useful if the levels actually hold. The program trains operators to find the links that skip them: an engineering workstation with a second network card wired straight into a cell, a historian that pulls from Level 1 and pushes to Level 4 out of the same box. Those links usually started as a fast way to solve a real problem.

Judging one of those links means asking which zone it crosses, what conduit it should have gone through instead, and what breaks if it is closed. That judgment belongs to the operators who know the process, not to a diagram.

Whether the reason for the rule still exists

Every segmentation rule, every allow-list entry, and every remote-access exception was added for a reason. A vendor needed a path during commissioning. A protocol was allowed through a conduit because one system needed it in year one. The program trains operators to ask whether that reason still exists before anyone changes what it protects, and before anyone removes it either.

A hardening plan built this way is made by the people who know what the line can take, not handed to them from outside. Every change it calls for still goes through the site’s own change process, because a rule that looks safe to remove on a Tuesday afternoon can be the same rule holding up a Thursday night shift.

By the end of the program, an operator has a segmentation model that matches the network as it actually runs, a list of compensating controls tied to the weaknesses they cover, and a remote-access path they can defend to an auditor and to themselves. The Programs page lists every unit in Hardening, and how it connects to Visibility before it and Response after.