The gap between tools is where the attack lives
AI-accelerated attacks exploit that space directly. When an actor deploys automated scripts across thirty targets overnight, as happened across Minnesota water systems in July 2026, the attack completes its kill chain in about the time it takes an analyst to pivot from the network monitoring console to the SIEM, correlate timestamps, look the asset up in the vulnerability database and begin reasoning about blast radius.
The attacker is operating at machine speed. The defender is operating at human-pivot speed. That is not a skills problem and it is not solved by hiring. It is an architecture problem, and the architecture problem has a name: fragmentation.
The answer is not another tool in the stack. Adding a tool adds a pivot. The answer is a platform that removes the pivots.
Detection that carries context
Spharaka Signal's detection is built on a platform-level model of what normal looks like for every asset in the environment. The IDS runs four engines at once: signature matching, protocol conformance analysis, machine learning anomaly detection and process physics validation. Each is informed by the full context of the asset, including its role, its communication history, its firmware version and its position in the OT topology.
The ML anomaly engine builds a continuous behavioural baseline per asset. When a controller starts receiving commands from a source it has never spoken to, outside its operational window, using function codes unusual for its role, the engine flags the deviation without a rule that anticipated that specific scenario.
Context is the rule. That is why context correlation is the defining capability for a platform facing AI-accelerated threats: when the attack itself is novel, only a system that understands normal can recognise the departure from it.
A SIEM that speaks OT
Signal includes a native SIEM. Not an integration with an external SIEM product, but a query and investigation environment operating directly against the same event data lake every detection engine writes to.
Analysts query in AQL, the Spharaka Query Language, with OT-native syntax. Asset criticality levels, protocol function codes, process variable identifiers and IDS engine names are first-class query terms rather than strings parsed out of a message field.
The practical consequence is that an investigation which previously meant exporting from three tools completes in a single query spanning network events, endpoint logs and process physics violations at once. Cross-layer investigation that took forty-five minutes takes minutes, and that recovered time matters most against threats moving at machine speed.
Risk as criticality, exposure and reachability together
Risk in OT is not a vulnerability count. It is the combination of what an asset does, what it is exposed to, and what can reach it. Signal's Risk Module computes a composite score for every asset in the CMDB from three inputs: operational criticality, meaning whether the asset is safety-critical, production-critical or auxiliary; CVE exposure from the ContentDB vulnerability database against the asset's firmware version; and network exposure from the Exposure Module's reachability analysis.
When an alert fires, the analyst sees the affected asset's risk score, its open CVEs and the full reachability graph: which assets are accessible from this one, over which protocols, by which paths. That is the whole chain, from detection signal through what is vulnerable and why, to the blast radius assessment that sets response priority. Every step is native to Signal Console.
The Exposure Module derives topology from deep packet inspection of actual communications, not from manually maintained diagrams and not from SNMP discovery that needs configuring. It reflects what is happening on the network as of the most recent observation window, and it updates continuously. A diagram drawn two years ago describes a plant that no longer exists.
- Operational criticality: safety-critical, production-critical or auxiliary
- CVE exposure: ContentDB matched against the asset's actual firmware version
- Network exposure: reachability derived from observed traffic, not from a diagram
- Blast radius: which assets are reachable from a compromised one, and by what path
Compliance without the spreadsheets
Compliance in critical infrastructure, whether NERC CIP for power, IEC 62443 for industrial systems, or sector-specific requirements for water and defence, generates a documentation burden that is usually met after the fact by a person with a spreadsheet.
Signal reduces that burden by making compliance evidence a byproduct of detection. Every IDS alert is mapped automatically to the corresponding MITRE ATT&CK for ICS tactic and technique, driven by a ContentDB MITRE knowledge base that updates continuously. Every incident carries a structured audit trail from detection through investigation to resolution.
When a regulator asks for evidence of active monitoring, incident response capability and vulnerability management, the answer is the Signal Console audit log rather than an assembled document. The work of proving the programme runs is done by the programme running.
AI triage: the analyst arrives after the assembly
When an incident opens, Signal assembles the correlated timeline across all four detection engines, enriches the affected assets with CVE and CMDB context, scores the incident by risk priority, and maps the investigation to MITRE ATT&CK techniques. All of that happens before the analyst has typed a query.
The analyst's time then goes to the part that requires human judgement, which is deciding what to do. Everything preceding that decision is mechanical, and mechanical work is what a platform should absorb.
Against AI-accelerated attacks this is the architectural response. Not a faster analyst, which is not available for hire, but a platform that removes the work which previously required manual effort so that judgement is applied at the moment it actually changes the outcome.
One platform, one data lake, one lifecycle
The case for consolidation in OT is not the usual licensing argument. It is that detection, investigation, risk, compliance and response are the same workflow observed at different moments, and splitting them across products means reassembling the context at every handoff, by hand, while an incident is live.
Spharaka Signal covers that lifecycle from one console against one data lake, without requiring an analyst to leave the platform for any piece of context their work depends on. That is the fix for a fragmented stack, and fragmentation, not any individual missing feature, is the vulnerability worth closing first.
Frequently asked questions
Why is a fragmented OT security stack a vulnerability rather than an inconvenience?
Because the time cost of pivoting between tools is paid during an incident. An attacker running automated scripts completes the kill chain in roughly the time an analyst needs to correlate timestamps across a network monitor, a SIEM and a vulnerability database. The gap between tools becomes the attacker's operating margin.
How is an OT SIEM different from an IT SIEM with OT parsers?
An adapted IT SIEM receives OT data as parsed strings. An OT-native SIEM treats asset criticality, protocol function codes, process variable identifiers and detection engine names as first-class query terms, and operates against the same data lake the detection engines write to rather than ingesting their alerts second-hand.
Can OT network topology be discovered without active scanning?
Yes, and in OT it has to be. Active scanning can freeze controllers and trip safety systems. Topology is derived from deep packet inspection of traffic that already exists, which also means it reflects what the network is actually doing rather than what a maintained diagram claims.
How does composite risk scoring differ from a CVE count?
A CVE count treats every vulnerable asset alike. Composite scoring combines operational criticality, CVE exposure against the asset's actual firmware version, and network reachability, so a safety-critical controller reachable from a compromised workstation ranks above an auxiliary device with more open CVEs and no path to it.
Does automatic MITRE ATT&CK mapping satisfy NERC CIP or IEC 62443?
It supplies the evidence those frameworks ask for rather than replacing the programme behind them. Automatic technique mapping and a structured per-incident audit trail mean that evidence of monitoring, response and vulnerability management is produced by the detection process itself instead of being assembled afterwards.
