DEV Community

Max Bayern
Max Bayern

Posted on Originally published at ot-cyber.de

SANS Five Critical Controls with AI: OT Security Without a SOC

Small teams in manufacturing and machine building usually have no SOC of their own. You can still implement the five SANS ICS Critical Controls if AI takes over the legwork: it reconciles asset lists, filters advisories, pre-sorts alerts and drafts incident response plans. This applies to every operator and machine builder that falls under NIS2 or the Cyber Resilience Act (CRA), and equally to anyone who simply wants to avoid unplanned downtime. Operators should start with an incident response plan and controlled remote access. Decisions at the plant stay with humans. (This is an English adaptation of the German original.)

Five controls instead of a hundred requirements

The SANS Institute condenses industrial security into five ICS Critical Controls. Control 4, for example, covers Secure Remote Access (SANS Webcast).

Max Gilg, an OT cybersecurity expert from Rosenheim, works with these five points because they set priorities. And for good reason: a typical supplier with two IT people, for example, cannot tackle all the requirements of IEC 62443 at once. Five controls, however, are achievable.

You don't need a SOC for this: the five controls set the order, and AI does the collecting and cross-checking. What happens at the plant is still decided by a human.

Where AI in OT has to stop

In December 2025, CISA and the Australian ACSC, together with partner agencies including the BSI, published guidance on the secure integration of AI into OT (NCSC New Zealand). It formulates four principles. These include frameworks for AI governance and assurance as well as oversight mechanisms.

In day-to-day operations that means: AI may read and write drafts. It does not write values into a PLC, and it does not enable a firewall rule either. To complicate matters, configurations usually contain real IP addresses, hostnames or plant names. These do not belong unfiltered in a public AI service: replace them with placeholders first, or use a locally hosted model.

When production stops after a cyberattack

A pure IT emergency plan is not enough for a plant: it describes, for example, how to restore the mail server, but not who decides whether the line keeps running in manual mode.

AI can deliver the first draft. The basis is the asset list and the vendor contact list, plus the shift schedule (anonymized). The draft then states who calls whom in which order and where the PLC projects are stored. It also covers which backups are offline. In a second step, the AI writes an exercise scenario, for example ransomware on the engineering PC on a Friday at 10 p.m. Production management and maintenance play it through together with IT at a table for one hour. Every gap that shows up in that hour is a concrete work item.

The plan also includes the reporting route: in Germany under the NIS2 implementation act (DQS), in Austria under NISG 2026 (WKO). If it burns anyway, our OT-Notfallhilfe (OT emergency response) can help.

Segmentation without a big project

Segmentation starts with knowing what is actually on the network. That knowledge is usually scattered. Part of it sits in the switches' ARP tables and in the engineering projects, part in the maintenance team's Excel list or on delivery notes. An AI merges these sources into one table and flags contradictions, for example a controller that appears in the project but never shows up on the network. In the end, someone who knows the plant has to verify it.

With this OT asset inventory you can sketch a zone model. Next, the firewall rules are exported. The AI searches them for any-any rules and old exceptions, as well as for direct connections from the office network into the cell. The result is a prioritized list that the network engineer can work through in two maintenance windows.

Detecting attacks without a 24/7 control room

Detecting attacks starts with passive listening, for example via a mirror port on the production core switch. This usually does not disturb the controllers. The real problem for small teams begins afterwards: the volume of alerts.

This is where AI comes in. If an unusual S7 or Modbus/TCP connection shows up at night, it explains what might be behind it. By morning there is a short report in which known items such as the backup job or the remote maintenance window are already separated from what is new. Assessing a real suspicion nevertheless stays with your own team or a service provider. How this is built is described on the page about attack detection in OT networks (SzA).

Control 4: Remote access to the PLC, but controlled

The service technician may access the PLC via remote maintenance, but only in a controlled way. In its list "Top 10 Bedrohungen und Gegenmaßnahmen", the BSI describes the most important threats to industrial control systems (BSI). In a webcast on Control 4, SANS recommends MFA wherever possible, as well as jump hosts (SANS Webcast).

For maintenance, that means: access only via a jump host, enabled for the duration of the job, with MFA and logging. The vendor's service laptop does not connect directly to the cell network, and USB sticks are checked beforehand. The AI reads maintenance contracts and firewall rules and lists all remote access paths that are permanently open.

For purchasers, the CRA is the lever. It obliges manufacturers to report actively exploited vulnerabilities in their products and severe incidents having an impact on the security of the product (Regulation (EU) 2024/2847). The tender for your next machine should therefore contain clear requirements: remote maintenance only through your own access, and an SBOM, plus a support period and machine-readable advisories. Machine builders who have to deliver this are supported by our CRA as a Service.

Which vulnerabilities to tackle first

In practice, vulnerabilities are often closed late or not at all. Patching everything is unrealistic in OT anyway: every firmware update needs a maintenance window.

Risk-based means: first comes whatever is actively exploited and reachable from outside. Two sources help here: CISA's KEV catalog (Known Exploited Vulnerabilities) and vendor advisories, ideally in machine-readable form. Once a week, an AI matches both sources against the inventory. Its proposal is then either mitigate immediately or patch at the next shutdown. Everything else is monitored. We also take over this work in OT vulnerability management.

The first two weeks

In week one, the inventory and the list of remote access paths come first; in week two, the tabletop exercise for the emergency plan. After that follow firewall rules, passive network monitoring and the weekly advisory matching. What gets faster is mainly the collecting and sorting. Decisions are still made by the team.

It is welcome that the five controls can create a solid foundation for NIS2 and the CRA. What matters, though, is that both regulations have their own obligations, which are not fulfilled by this alone. Operators should start with remote access and the emergency plan, and certainly not only when the auditor arrives.

A note for context: the working methods described come from consulting practice; the post contains no lab measurements. Statements about authorities, standards and laws are taken from the linked sources. Time figures such as maintenance windows or the length of the tabletop exercise are based on experience.

If you are looking for a contact to get started: with our OT-Security-Beratung we support operators and machine builders across DACH, from the first workshop to the ongoing OT-Lagebild (OT situational picture).

Sources

For the architecture side of machines you build or buy, see Security-Architektur der Maschine.

Original (German): https://ot-cyber.de/blog/sans-five-critical-controls-mit-ki-ot-security-ohne-soc.html

Max Gilg is an OT cybersecurity consultant based in Rosenheim, Germany (OT-Cyber.de).

Top comments (0)