Autonomous Intrusion Detection for Industrial Networks

Why signature-based IDS runs out of road in OT

Signature detection works when the population of things to detect is large, well documented, and updated on a predictable cadence. That describes IT malware reasonably well. It does not describe OT.

OT protocols themselves are stable. Modbus, DNP3, and OPC UA change slowly, sometimes over decades, so there is little new protocol behaviour to write signatures against. The problem is the opposite one: the asset population sitting behind those protocols is enormous in variety. Every vendor, firmware revision, and integrator configuration produces a slightly different device with a slightly different notion of what a legitimate command sequence looks like. A signature written for one plant's PLC fleet often does not transfer to the next.

The practical consequence is a thin signature library that catches known, publicly disclosed OT malware and almost nothing else. Novel intrusions, misconfigurations, and insider misuse of legitimate protocol functions pass straight through, because there was never a signature for them to match.

Passive traffic analysis and protocol dissection

The starting point for OT detection is not signatures at all. It is the ability to observe traffic passively and dissect it down to the function code and register level.

This matters because OT protocols carry meaning at a granularity that generic packet inspection cannot reach. A TCP flow to a PLC on port 502 tells you almost nothing. Knowing that the flow is a Modbus write to a specific coil, at a specific rate, from a specific engineering workstation, tells you whether the traffic is routine maintenance or something that should not be happening at 2am on a Sunday.

• Parse to function code and register, not just IP and port, so anomalies are described in terms an engineer recognizes.
• Correlate protocol activity with asset identity, firmware version, and the physical function the register controls.
• Do this without injecting a single packet onto the wire, because observation must never risk the process being observed.

Learning normal from operational baselines

IT anomaly detection typically baselines against a fairly homogeneous notion of user and network behaviour. OT baselining has to account for the process itself, which has its own rhythm.

A batch process cycles through discrete phases with predictable command sequences at predictable intervals. A continuous process runs steadier but shifts with shift changes, seasonal demand, and planned maintenance windows. A baseline that does not account for this rhythm will either miss anomalies buried in a busy phase or flag routine phase transitions as suspicious.

• Process cycles: command sequences and register writes that repeat within a batch or continuous run.
• Seasonality: demand-driven shifts in throughput, shift patterns, and maintenance calendars that change what normal traffic volume looks like.
• Campaign windows: planned outages, commissioning activity, and vendor remote sessions that legitimately look unusual and must be modeled as expected exceptions, not permanent baseline drift.

What autonomous specifically adds

Autonomy is not a marketing label for automation. In OT detection it does three concrete things that static baselining and signature matching cannot.

• Continuous baseline adaptation without drift: the model updates as the process legitimately changes, but distinguishes a gradual shift in operating pattern from an attacker's slow, incremental probing that would otherwise be absorbed as 'the new normal.'
• Contextual anomaly reasoning: an anomalous register write is evaluated against asset criticality, physical consequence, and recent incident history before it becomes an alert, rather than being reported as a bare statistical outlier.
• TTP correlation to OT-specific frameworks: findings are mapped to MITRE ATT&CK for ICS tactics and techniques, so an analyst sees where a sequence of small anomalies sits in a known adversary playbook rather than reviewing isolated events one at a time.

Deployment topology: how to see traffic without touching it

Detection quality in OT is inseparable from deployment topology. Getting visibility wrong is either useless or dangerous, and there is not much middle ground.

• SPAN or mirror ports on the switches carrying OT traffic, so the sensor receives a copy of the traffic without sitting in its path.
• Test access points (taps) at critical segment boundaries, particularly between the process control network and the DMZ, for visibility that does not depend on switch configuration surviving a change.
• Unidirectional gateways where data needs to leave a safety or process control zone for monitoring purposes, enforcing that nothing can flow back in regardless of what happens to the monitoring system.
• Sensor placement at zone and conduit boundaries consistent with the site's Purdue model segmentation, so detection coverage maps to the same trust boundaries the network architecture already defines.

What not to do in OT

The instinct to bring IT security practice into OT unmodified causes more incidents than it prevents. Two practices in particular do not belong in the plant.

• Active probing and vulnerability scanning against live control devices. Many PLCs and RTUs were never built to withstand unexpected traffic and can fault, freeze, or fail open when scanned, which is a worse outcome than the vulnerability the scan was meant to find.
• Installing monitoring agents directly on PLCs or other controllers. These devices typically run fixed, vendor-certified firmware with no spare compute budget and no supported mechanism for third-party software, and an agent can void vendor support or destabilize a safety function.
• The safe default is passive, out-of-band observation everywhere it is possible, with any exception to that rule requiring engineering and safety sign-off, not a security team decision alone.

Integrating with the OT SOC and IT SOC without alert fatigue

Most organizations now run OT detection findings into a SOC that also handles IT alerts, whether that SOC is dedicated or shared. The integration point is where a lot of good detection engineering gets undone, because OT alerts arriving in an IT-tuned queue at IT volume and IT severity conventions get triaged by analysts who do not have the process context to judge them.

• Route OT findings with process context attached, including which asset, which physical function, and which safety implication, rather than raw event descriptions.
• Apply OT-specific severity scoring rather than reusing IT CVSS-style triage, since a low-bandwidth anomaly on a safety-instrumented system outranks a high-volume anomaly on a non-critical HMI.
• Correlate IT and OT findings that share an actor or timeline, so a phishing compromise on the corporate network and an anomalous OPC UA session three days later are presented as one incident, not two disconnected tickets.
• Keep OT alert volume deliberately low by design, favoring fewer, better-reasoned findings over comprehensive but noisy coverage that trains analysts to stop reading OT alerts altogether.

Safety-preserving response patterns

Response in OT has to be designed around the fact that the wrong action can cause a safety event, not just a service outage. That changes what an acceptable automated response looks like.

• Detect and recommend by default, with containment actions presented to an operator or engineer for approval rather than executed automatically.
• Reserve automatic action for narrowly scoped, pre-approved cases, such as isolating a single engineering workstation from the corporate network, never for actions that touch the process control path itself.
• Require operations sign-off for anything that could affect a production line or safety interlock, encoded as policy rather than left to individual analyst judgment during an incident.
• Log every recommended and executed action against the incident timeline, so a later safety or compliance review can reconstruct exactly what the system suggested and what a human decided.

How Spharaka Signal implements this

Spharaka Signal™ combines protocol-aware passive detection with the AuraXP™ agentic fabric and the AirWatch™ governance layer. Detection runs at the protocol level using taps, mirror ports, and unidirectional gateways rather than agents or active probing. Findings are reasoned against process baselines, asset context, and MITRE ATT&CK for ICS before they reach an analyst, which keeps OT alert volume low and each alert meaningful.

Reasoning is shared with the IT SOC through the same platform Sphere uses, so an OT finding and a related IT finding are correlated into one incident view. Response actions are constrained by OT-specific policy enforced through AirWatch, so an agent cannot take a step that would trip a safety interlock or touch the process control path without the sign-off that policy requires.