Why do you need three detection engines?

Because each covers what the others miss. Signatures catch known protocol abuse at line rate but cannot see an attack made entirely of valid operations. Query-language rules express multi-event and multi-asset logic. Behavioural models catch the genuinely unfamiliar. Running one alone leaves a predictable gap.

How do you detect an attack that uses only legitimate commands?

By evaluating context rather than packet validity. Once each register is resolved to its meaning and safety relevance, a valid write becomes suspicious based on where it came from, when it happened and what it targeted. That is expressible as a rule, and the behavioural models score the same activity against the asset's own history.

Does behavioural detection produce a lot of false positives in OT?

Industrial traffic is considerably more repetitive than enterprise traffic, so baselines are tighter and deviations are more meaningful. The larger risk is the opposite: a model that flags a deviation without explaining it. Findings are therefore presented with the asset and process context needed to adjudicate them.

What is MITRE ATT&CK for ICS?

A knowledge base of adversary tactics and techniques observed specifically against industrial control systems, distinct from the enterprise matrix. Mapping detections onto it shows which industrial adversary behaviours are covered and where the genuine gaps are.

Does detection run at the sensor or centrally?

Both. Signature detection runs inside the edge sensor at line rate, so it does not depend on the central platform being reachable. Query-language rules and behavioural models run centrally against the unified event store, where cross-asset and historical context is available.

How do OT detections reach the enterprise SOC?

Signal findings pass into Spharaka Sphere and correlate with enterprise telemetry there. That matters because industrial intrusions usually start outside the plant, and reviewing the two halves in separate consoles is how the connection between them gets missed.

OT Threat Detection: Three Engines, One Pane

Why one engine is never enough

A signature engine encodes a pattern someone has already observed and characterised. That is genuinely valuable in industrial networks, where a number of consequential attacks reuse the same protocol abuse, and it runs at line rate inside the sensor.

It also cannot detect an attack expressed entirely in legitimate protocol operations, which is what a competent industrial attacker produces. Nothing in a well-executed setpoint manipulation looks malformed. Every packet is valid; the problem is who sent it, when, and to which register.

Behavioural models cover that ground by learning what normal looks like for each device and each zone. Their weakness is explanation: a model reporting a deviation without saying what deviated gives an operator nothing they can act on during a shift.

A competent attack on a control system contains no malformed packets. Every frame is valid protocol. The anomaly is entirely in the context.

Engine one: signature detection at the sensor

Signature detection runs inside the edge sensor using Suricata-derived rules tuned specifically for industrial protocols, evaluated against the same traffic the deep packet inspection engine decodes. Because it executes at the sensor it adds no round trip and no dependence on the central platform being reachable.

The rules target protocol abuse with known operational consequences rather than generic network signatures, which keeps false positives on legitimate industrial traffic manageable in a way IT rule sets do not achieve when pointed at a plant network.

Engine two: rules written against meaning, not bytes

The second engine runs a pipeline query language against the unified event store, which allows detections a signature engine cannot express because they span several events, several assets or a period of time.

It works because of what the store already contains. Every industrial event is tagged as it is written with its resolved tag name, whether the register is safety-relevant, whether it is security-relevant, which resolution tier matched, and a severity. That means a detection can be written in terms of process meaning rather than protocol mechanics.

The canonical example: raise a critical alert when a write to a safety-relevant register originates from any zone other than the engineering workstation zone. That is a single expression. No signature rule can state it, because a signature engine does not know which registers on that specific controller are safety-relevant.

Engine three: behavioural models across six patterns

The behavioural engine runs a set of models grouped into six patterns, each answering a different shape of question about normality.

First-seen. A protocol, function code, peer pairing or register write observed for the first time on this asset.
Stateless rules. Unauthorised function codes, off-hours activity, anonymous authentication, zone crossing, unrecognised hardware vendor prefixes.
Statistical deviation. Traffic volume, process values, event rate and error rate scored against their own history.
Rate and change. Bandwidth shifts, controller mode changes, program hash drift, alarm rate spikes and account lockouts.
Zone boundary. Topology-aware detection of movement across segmentation that should not be crossed.

One alert pane, and an investigation that holds context

All three engines write into the same alert pipeline, and the investigation view renders any alert identically regardless of which engine produced it: an overview, the contributing events, the asset context, the process context and the risk impact.

This matters more in OT than in enterprise security, because the analyst reviewing an industrial alert frequently is not the person who understands the process. Presenting the resolved tag, its engineering unit and its safe range next to the alert is what allows a decision to be made without paging a control engineer for every finding.

Mapping to MITRE ATT&CK for ICS

Detections are mapped onto the ICS matrix rather than the enterprise one, because the adversary behaviours that matter here are industrial. The coverage view shows which tactics your current detections actually cover and where the gaps are, which is a more honest planning input than a count of enabled rules.

Tactics covered include Discovery, Lateral Movement, Persistence, Command and Control, Inhibit Response Function and Impair Process Control.

Feeding the wider security operation

Industrial detections that stay in an industrial console solve half the problem, because the intrusion usually began somewhere else. Signal findings pass into Spharaka Sphere and correlate with enterprise telemetry, so a compromised corporate account and an anomalous engineering session are visible as one storyline rather than two tickets in two systems.

OT Threat Detection: Three Engines, One Alert Pane