The SANS ICS Five Critical Controls: five things, in an order that matters

Most industrial sites are not short of frameworks. They have IEC 62443, NIST CSF, ISO 27001, sector requirements, and now NIS2. What they lack is an answer to the question that comes straight after: with a limited budget and a plant that cannot stop, what do we do first?

The SANS paper The Five ICS Cybersecurity Critical Controls, written by Robert M. Lee and Tim Conway and published in November 2022, tries to answer exactly that. It is worth reading properly, because most summaries skip the part that makes it work.

Why five, and why not the existing frameworks

The paper makes two arguments. The first is about balance. The authors point out that most of the guidance in existing security frameworks is aimed at preventing compromise, much less at detecting and responding to it. On a network you can rebuild in an afternoon, that is a defensible choice. On a plant where the controllers cannot authenticate, cannot be patched on demand and will still be running in fifteen years, it means most of the guidance targets the part of the problem you are least able to fix.

The second is about origin. Many industrial frameworks were written when ICS-specific threat intelligence was thin, so they inherited IT controls that made sense in an office and help very little in a plant. The result is programmes that keep people busy without being effective.

Robert M. Lee has a line for the difference that I have never heard bettered: IT is how you run the business; OT is why you are a business. An IT attack usually goes after data. An OT attack goes after operations, physical equipment, or safety.

What makes the five credible is where they come from. They were drawn from the analysis of known ICS attacks, not negotiated by a committee reconciling other standards.

Control 1: An ICS-specific incident response plan

This does not mean an IT plan with “and the plant” added at the end. It means a plan built around scenarios. The paper recommends a few drawn from real incidents in your own sector, plus a consequence-based one: start from the outcome you cannot accept and work backwards to how it could happen.

This is the control that holds the framework together, and the one most often skipped. The scenarios are not an exercise in imagination; they are the requirements document for the other four controls. They tell you which segments matter, which traffic is worth collecting, which remote paths matter and which vulnerabilities are relevant.

Skip them and you get a technology-led programme: tools bought, alerts generated, and nobody able to say whether the thing you actually fear would be caught.

The tabletop exercise is where the plan becomes real. It is often the only time operations, security, quality, regulatory and management sit in the same room, and discover, before it matters, that nobody has the authority to stop the line at three in the morning.

Control 2: Defensible architecture

The word is “defensible”, not “secure”, and it is chosen with care. The aim is not a network that cannot be breached. It is a network a human defender can actually work in.

In concrete terms the paper lists an asset inventory, segmentation that creates choke points, assessment of access in both directions (not only inbound), the ability to collect network traffic, and the ability to move to a more restricted posture during an incident.

That last item deserves attention. Can you, deliberately and quickly, cut the plant off from everything non-essential without stopping production? If nobody has designed that, nobody will improvise it during an incident, and the decision will be taken for you by whoever pulls a cable first.

Two additions from the field. Outbound traffic matters: most segmentation projects control what comes in and ignore what goes out, which is precisely the direction exfiltration and command-and-control traffic use. And the architecture has to serve Control 3. A segmentation design that leaves nowhere to put a network sensor will have to be redone.

Control 3: ICS network visibility and monitoring

IT logging stretched to cover the plant will not do. The paper asks for protocol-aware monitoring: a sensor that understands Modbus, S7, EtherNet/IP, PROFINET or DNP3, and can therefore tell a legitimate write from an illegitimate one instead of merely noting that two addresses exchanged packets.

One point is easy to miss and expensive to ignore. The aim is not to detect every anomaly. It is to detect adversary behaviour that matches your scenarios from Control 1. A system tuned to alert on everything unusual in an industrial network will drown its operators, because industrial networks are full of unusual things that are perfectly normal: a maintenance laptop on a Sunday, a historian catching up after a restart, a vendor tool polling every register once a week.

This is also the control that tells you whether the architecture drawn in Control 2 exists. The first weeks of passive monitoring nearly always turn up a connection nobody had on the drawing.

Control 4: Secure remote access

The paper starts from a realistic premise: remote access is not going away, and pretending otherwise produces shadow connections rather than isolation.

Its priority is explicit. Multi-factor authentication comes first on connections that arrive from outside, across shared or public networks. Not on everything at once, but on the paths an external adversary can reach.

The case to quote in a management meeting is Colonial Pipeline. Its chief executive told a US Senate committee in June 2021 that the attackers had come in through a legacy VPN profile that was not supposed to be in use and had only single-factor authentication. No zero-day; an account nobody had closed. Most sites we assess have a version of that account somewhere.

Where MFA really is not possible, which happens with older equipment and some vendor tooling, the paper does not shrug. It names compensating controls: jump hosts, break-and-inspect points, monitoring at the choke points from Control 2, and the ability to cut the connection entirely during a period of elevated threat. That last one is worth testing before you need it.

Control 5: Risk-based vulnerability management

This control saves the most money and causes the most arguments, because it runs against the way vulnerability management is usually measured.

The paper’s position is that only a small minority of ICS vulnerabilities published each year call for immediate action, and that a share of advisories are inaccurate or unhelpful. For many industrial vulnerabilities there is simply no patch to apply, so a programme defined as “patch everything critical” is not just expensive. On those assets it has no meaning.

Instead, the paper proposes three questions. Does this vulnerability support one of my Control 1 scenarios? Does it give an attacker new exploitable functionality? Is it being actively exploited? Everything else is monitored, or mitigated through architecture.

European law points the same way for some sectors. The NIS2 implementing rules for digital providers (Implementing Regulation (EU) 2024/2690, point 6.6.2) allow an entity not to apply a patch when the disadvantages outweigh the cybersecurity benefits, provided the reasons are documented. That regulation does not cover factories, but it shows the reasoning a regulator is prepared to accept.

The part most summaries omit: the controls are sequential

They are not five parallel workstreams to staff. They form a chain.

1. Control 1 produces the scenarios that define what the rest must achieve.
2. Control 2 must make room for the collection those scenarios need, so the architecture is designed partly around the sensors.
3. Control 3 checks the architecture and detects the scenarios; monitoring often shows that the segmentation does not work the way the diagram says.
4. Controls 4 and 5 build on 2 and 3. Remote access is policed at the choke points, and vulnerability priority is judged against the scenarios and the observed traffic.

Skip Control 1 and the other four have no criterion. That is why programmes that start by buying a monitoring platform so often end up with a platform nobody trusts.

How this sits next to what you already have

It replaces nothing. The authors present the five as a complement to NERC CIP, ISA/IEC 62443, NIST and similar frameworks: a way to prioritise and to measure outcomes rather than another list of prescriptive requirements. Regulated organisations can use them to go beyond the baseline; unregulated ones can use them as the programme itself.

For a European industrial site, the practical reading goes like this. NIS2 tells you what you must be able to demonstrate, IEC 62443 gives you the industrial vocabulary and architecture model, and the five controls tell you the order. They also line up with Article 21(2) of the Directive: Control 1 with incident handling and crisis management (points b and c), Control 2 with asset management and the security of network and information systems (points i and e), Control 4 with access control and multi-factor authentication (points i and j), and Control 5 with vulnerability handling (point e). Control 3, monitoring, is what lets you show that the others work. Doing the five well produces a large part of the evidence Article 21 asks for, in the order that also reduces risk fastest.

Where to start, honestly

If nothing exists yet, run one tabletop. Two hours, one plausible scenario, the people who would really be involved, and a written list of everything nobody could answer. That list is your programme. It costs nothing, and it gives you the criterion for every later decision.

If an inventory exists but no monitoring, put a passive sensor on one production cell for a couple of weeks. It will tell you more about your real architecture than any diagram, and it will usually find at least one connection nobody knew about.

If everything exists on paper, test the one thing nobody tests: whether you can move to a restricted posture on purpose, and how long it takes.

Sources

• SANS, The Five ICS Cybersecurity Critical Controls, Robert M. Lee and Tim Conway, November 2022
• Directive (EU) 2022/2555 (NIS2), Article 21(2)
• Commission Implementing Regulation (EU) 2024/2690, Annex, point 6.6.2