One Day, Seven Advisories: What CISA's Latest ICS Batch Reveals About OT Detection
On June 25, CISA published seven ICS advisories in a single batch. Seven. And the list reads like a floor plan of a modern industrial facility.
Yokogawa FAST/TOOLS — the distributed control system web server that operators use to monitor and manage production processes. Horner Automation Cscape — the engineering tool that programs the PLCs running assembly lines and water treatment plants. Schneider Electric PowerLogic P7 — the power monitoring unit watching over electrical distribution. Delta Electronics DTM Soft — industrial automation configuration software. EVoke Systems — electric vehicle charging station management. Daktronics — controller firmware for industrial displays and signage. H.VIEW — an IP camera deployed across manufacturing floors and warehouse perimeters.
That is not a single vendor’s bad quarter. That is the OT landscape in one day’s vulnerability disclosures: process control, power management, engineering workstations, facility infrastructure, physical security. Every layer of the Purdue model, represented.
The Problem Is the Diversity Itself
Security teams in industrial environments manage device inventories that would make an enterprise CISO pause. A single site might run a Yokogawa DCS from 2016, Schneider power meters installed during a 2020 expansion, Horner PLCs controlling a packaging line, and a fleet of IP cameras added during a physical security upgrade last year. Each device speaks different protocols. Each has its own firmware update cadence, its own authentication model, its own patching window — if patching is even possible without a production outage.
The signature-based detection model assumes a manageable catalogue of known threats. When a new CVE drops, the vendor ships a signature, and the detection engine checks traffic against it. That model works when your asset inventory is homogeneous enough that signatures can be written, tested, and deployed before an attacker weaponises the vulnerability.
But look at that seven-advisory batch again. A signature for Yokogawa FAST/TOOLS web traffic tells you nothing about unauthorised writes to a Horner PLC. A signature for Schneider PowerLogic command injection is blind to firmware tampering on a Daktronics controller. Each new advisory adds another signature to maintain, another pattern to tune, another gap between disclosure and coverage.
The diversity is not an edge case. It is the defining characteristic of industrial environments. And it breaks the signature model at the arithmetic level: the number of device types multiplied by the number of firmware versions multiplied by the number of protocol interactions produces a surface that no signature catalogue can cover.
Detecting What You Haven’t Catalogued
This is where the approach needs to invert. Instead of asking “do I have a signature for this threat?”, the question becomes “does this device’s behaviour match what I know is normal for it?”
A Yokogawa FAST/TOOLS server, in steady-state operation, exhibits a stable pattern: HTTP traffic on its management interface, OPC connections to downstream controllers, periodic data exchanges with the historian, and a predictable set of endpoints it communicates with. That pattern is learnable. When the server suddenly initiates a connection to an external IP it has never talked to before, or when a Schneider PowerLogic P7 begins issuing Modbus write commands to a device it normally only reads from — those deviations are detectable without a single CVE signature.
The detection signal is not “this matches known-malicious pattern X.” The signal is “this device has never done this before, and there is no operational reason for it to start now.”
That shift — from threat-catalogue matching to device-behaviour baselining — is what makes diversity manageable. You do not need a signature for every advisory. You need a baseline for every device. And once that baseline exists, novel attacks register as deviations regardless of whether anyone has seen them before, written a signature for them, or published an advisory about them.
The Pattern That Keeps Repeating
This is not the first time a CISA advisory batch has spanned the OT stack, and it will not be the last. The pattern recurs because industrial environments are accretive — devices are added project by project, vendor by vendor, decade by decade. No single procurement standard or security architecture governs the whole plant. The result is an asset population that is, by its nature, diverse, heterogeneous, and resistant to monolithic detection strategies.
What changes is whether the detection strategy acknowledges that diversity or fights against it. Signatures fight against it — each new device type, each new protocol variant, each new firmware release is another gap to close. Behavioural detection works with it — the diversity itself becomes the detection surface, because every device leaves a unique behavioural fingerprint, and deviations from that fingerprint are the signal.
At Maigadi Networks, we build for that reality. Our passive NDR sensor learns what normal looks like for each device on the OT network — the protocols it speaks, the endpoints it talks to, the cadence of its communications — and flags what is novel. No signatures. No cloud requirement. No assumptions about what your asset inventory should look like, because we work with what it actually looks like.
The seven advisories CISA published on June 25 are not exceptional. They are representative. The question they raise is not whether your vulnerability scanner has the right plugins. It is whether your detection can see a device acting strangely when no signature tells it what to look for.
Maigadi — the OT/ICS network detection & response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.