Securing OT/ICS: a cycle, not a project

Industrial cybersecurity is often sold as a list of products. It is more useful to see it as a sequence, because the order decides whether any of the products help.

The sequence is nobody’s invention. It comes from the NIST Cybersecurity Framework, and that is the best reason to use it: auditors, regulators and customers already speak its vocabulary.

A note on the framework itself

CSF 2.0, published in February 2024, has six functions: Govern, Identify, Protect, Detect, Respond, Recover. Govern is the new one, and the important change. Strategy, roles and accountability became a function in their own right instead of a preamble.

Practitioners often compress this to five steps, pairing Govern with Identify at the front and adding “Improve” to Recover to close the loop. That is a reasonable way to present it, and CSF 2.0 does place improvement inside Identify. Know the exact wording before you use it in front of an auditor, though. They will know the six.

1: Govern and Identify

Define the strategy, the responsibilities and the requirements. Then take the inventory: assets, systems, networks, flows, dependencies, risks, vulnerabilities. You only protect what you know exists.

In OT this step is harder than it sounds and worth more than it looks. You cannot push agents onto a fleet of controllers, and an active scan can knock an old device off the network. So the inventory is built passively, from traffic, and by walking the plant with the people who maintain it. It is slow, which is exactly why it gets skipped.

Insist on two things. The flows matter as much as the asset list: knowing you have forty controllers helps far less than knowing which two exchange a signal that appears on no drawing, and that undocumented link is what breaks segmentation projects. And the inventory has to be tied to the change process. Left alone, it describes, six months after the audit, a plant that no longer exists.

2: Protect

The densest step: four workstreams with one objective, a smaller attack surface and less room for an intruder to spread.

• Segment into zones. Separate production from the office, and production cells from each other, so that one compromise does not become every compromise. IEC 62443 gives the vocabulary of zones and conduits, and it genuinely helps the conversation with IT.
• Control IT/OT access, remote access first. Vendor and contractor access is one of the most common ways into industrial networks. Named accounts, limited in time, through a controlled path, recorded.
• Harden. Tighten configurations, remove default credentials, disable unused services and ports. Unglamorous, cheap, and skipped more often than anything else.
• Back up controller programs and HMI configurations, not only the servers, and keep step 5 in mind: the backup alone is not the deliverable.

3: Detect

Watch the systems, the flows and the events: monitoring, logging, detection of abnormal behaviour. The dependency runs in a strict order. You only detect what you observe, and you only observe what is logged. A site that has never switched on logging on its engineering workstations has not failed at detection; it has never tried.

Against an intruder who pre-positions in the network, encrypts nothing and waits, detection is the only control that applies. Without visibility of OT traffic, such an intruder can stay for weeks, and the first sign may be the attack itself.

4: Respond

Prepare the incident response procedures, apply them, test them on scenarios. In OT the objective is specific: limit the impact on safety and production.

Until it has been played out once, a procedure is only a document. A tabletop exercise exposes things nothing else will. Who can stop a line at three in the morning on a suspicion? If nobody in the room can name that person, the decision will be taken by delay. How do production and security talk to each other? One team’s reflex is to isolate, the other’s to keep running; both are legitimate, and the arbitration has to be agreed beforehand.

Then the regulatory clock. NIS2 asks for an early warning within 24 hours of becoming aware of a significant incident. Meeting it takes detection, escalation, someone with authority to decide and a notification already drafted, all in place before the day it is needed.

5: Recover and improve

Restore the systems, test the recovery procedures regularly, keep the business running, and feed the lessons back.

A backup is a hypothesis; a restore is evidence. The number that matters is how many hours it took, the last time someone loaded a controller program onto a spare and proved the line ran. If nobody has ever measured it, the recovery plan is an assumption.

The lessons close the loop onto step 1. Every incident, near miss and exercise changes the strategy and the inventory.

The property that matters most

The steps form a loop. Every new machine, every integrator visit, every significant change starts it again. A line commissioned in June brings assets nobody inventoried, flows nobody segmented, and a remote access account nobody will remember to close.

Most OT security programmes die there, eighteen months after the audit, when the architecture is still correct on paper and no longer matches the plant. The controls that last are wired into management of change, so that adding equipment adds it to the inventory, the zone plan and the backup scope without anyone having to think of it.

OT security has no end date. It is a property of how the site manages change.

And the part no tool replaces

None of the five steps works without trained, aware teams.

The inventory is built with the people who maintain the plant. Hardening is accepted, or quietly undone, by the people who run it. Detection produces alerts someone has to judge, and the response procedure is carried out at three in the morning by whoever is on shift. An operator who understands why a USB stick is scanned before use will scan it. One who does not will find the procedure a nuisance and work around it.

Tools and vendors change. The approach, and its dependence on people, does not.

References

• NIST, The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29, February 2024: nvlpubs.nist.gov
• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, September 2023: nvlpubs.nist.gov
• Directive (EU) 2022/2555 (NIS2), Article 23(4): eur-lex.europa.eu