How Deterministic Detection Rules Work in OT — From Allow List to Incident
How deterministic detection rules work in OT: Allow Lists, Device Mappings, rule types and incident triage in zcrOT, with a worked example. Free consultation.
How Deterministic Detection Rules Work in OT — From Allow List to Incident
Most OT teams don't have a log shortage — they have a time shortage. Anyone who watches factory network traffic or a SCADA system every day runs into the same problem: the monitoring tool keeps alerting on something, all day, every day, and eventually the team just turns some of those alerts off because there's no time to chase them all down. That's arguably even more dangerous than having no alerting system at all.
A lot of vendors answer this with machine-learning anomaly detection — let a model learn "normal behavior" and flag anything that deviates from it. Sounds smart. But the problem shows up when an alert actually fires. The team often can't answer "why did this trigger?" The model doesn't hand you a reason. It just says "this looks off."
That's why deterministic systems still have a real place in OT work. This kind of rule isn't as clever as a machine-learning model, but every condition is written out explicitly: if A and B happen together, alert. You can always explain why it fired — and in an environment where a wrong call can mean stopping a production line, that explainability is worth more than it sounds.
This piece goes straight into zcrOT's Detection Engine, in the public demo anyone can click through themselves (https://demo.ot.zcr.ai/dashboard/detection-engine). The demo runs on sample data, so instead of reading values off it, we explain what each tab is for and how to read it, then follow one invented scenario from an Allow List entry to an incident. Follow along in the demo as you read.
Three Layers Before Anything Becomes an Incident
zcrOT's Detection Engine splits its work across several tabs. Four of them deal directly with the detection mechanism: Allow Lists, Device Mappings, Detection Rules, and Incidents (the tab for response and triage). Each tab does a clearly different job, and together they form layers of filtering before traffic ever becomes something a human has to sit down and look at.
Layer 1 — Allow List: telling the system what's already normal
An Allow List entry records traffic your team has already looked at and decided is normal. Each entry carries a name, a description, a scope (a source, a destination and a port range) and a type (whether the conversation stays inside the network or leaves it, and over which protocol, such as Modbus or TLS). It's a written-down statement of what normal looks like on this network, so the team doesn't have to keep re-examining it.
A good habit is to keep each entry narrow. Picture an entry for one monitoring server that polls one gateway over Modbus on a schedule. It says something precise: this source, this destination, this port, this protocol. If a different machine starts talking to that gateway, or the monitoring server reaches a different destination, nothing in the entry says that traffic is normal. The broader an entry gets, the more it declares normal. An entry that covers half the network saves typing, but it also declares a lot of traffic normal that nobody has really looked at.
Layer 2 — Device Mapping: turning IPs into names a human recognizes instantly
Device Mappings is the tab that pairs an IP address or Modbus unit ID with a human-readable name. It sounds like housekeeping, but it's what lets a person read the other layers. Allow List entries are written in addresses, and so is most of the raw traffic. Cross-check an entry against the mapping and you know which device on the network it refers to (the two tabs don't reference each other directly, so it's worth making that cross-check a habit). That matters most at 2 a.m. during a live alert, when nobody wants to work out which box an address belongs to. It also makes naming a discipline: give each device one name and use it everywhere, because a name that's off by even a single character can make it look like there's a second device when there's really only one.
The other case worth understanding is Modbus unit IDs. Several devices behind a gateway (say a flow meter, a drive controller and a temperature sensor) don't always have IPs of their own. They can answer on different unit IDs behind the same gateway address. That's a common pattern in real OT work. Mapping the unit IDs as well as the IPs means a team reading the logs knows immediately which device a given unit ID refers to, without pulling up a network diagram to cross-check.
Layer 3 — Detection Rule: the conditions that decide when to actually alert
This is the layer that decides what qualifies as an incident. Each rule has a name, a priority, a type and a severity. There are four rule types: Single Event (fires on a single occurrence, like an unrecognized client trying to reach the gateway), Threshold (needs to cross a set count before it fires, like remote maintenance access outside working hours), Aggregation (rolls up multiple smaller events before deciding, like an unusually dense burst of Modbus errors), and Correlation (compares behavior against a previously seen baseline, like outbound cloud traffic that deviates from its usual pattern). Having all four rule types available matters, because anomalies on a factory floor don't all follow one shape — some need to be caught the instant they happen, others need a trend before you can call it.
Want to set up rules like this on your own OT network? See the full package lineup at the zcrOT plans →.
A Worked Example — From Rule to Incident
Theory alone isn't enough, so here is one scenario walked through end to end. It's invented: no real device, address or name appears in it. If you sketch scenarios like this for your own runbooks, use addresses from the blocks RFC 5737 reserves for documentation, so an example can't be mistaken for a live system.
Take a small plant with a data gateway that collects readings from a handful of field devices over Modbus. The team has an Allow List entry for the monitoring server that polls the gateway, and both are named in Device Mappings. Two rules are switched on: a Single Event rule for an unrecognized client reaching the gateway, and a Threshold rule for remote maintenance activity outside the agreed window.
On a quiet evening, a machine nobody has mapped starts sending Modbus requests to the gateway. Here is how the team's own records line up against it:
- No Allow List entry covers this machine talking to the gateway, so nothing says the traffic is normal.
- Device Mappings has no name for it, so in the raw traffic it's just an address, which is a clue in itself.
- The Single Event rule is written for exactly this kind of client, so it fires on the first occurrence. Because the rule's condition is spelled out, anyone can say afterwards why it fired: an unrecognized client reached the gateway.
- The match becomes an incident, and now a person has something to look at.
What you can work out from that incident is the useful part. You can tell which condition was met from the rule that is written for it. Cross-check any addresses in the underlying traffic against Device Mappings and you know which parts of the plant are involved. The status tells you whether anyone has picked it up yet (for example open, acknowledged or closed). The match count tells you how often the rule matched, and the risk score is there to help you decide what to look at first.
Be careful with those last two. Two incidents can match the same number of times and still deserve very different attention. An unknown client reaching a gateway again and again is a different problem from a low-severity rule matching again and again on a device you already know is noisy. That's exactly why a triage team shouldn't decide what to look at first based on "how many times it matched" alone. And don't assume the risk score is just the rule's severity in another form, either; treat it as one input to triage, not a verdict.
The quiet case teaches something too. The Threshold rule from the scenario stays silent all evening, and that isn't necessarily a malfunction: a rule that's switched on but has never produced an incident may simply be waiting for a condition that hasn't happened. Just be sure that's the reason before you rely on it.
If you want to go further into what OT incidents look like and how to weigh them, there's a dedicated article at 4 OT Incident Types.
More Than Just Modbus Read/Write — Classification Runs Deeper Than You'd Expect
When you create a new Allow List entry, the system offers a Classification dropdown that covers more than the Modbus read and write categories most people would guess going in. Besides Modbus traffic, there are groups for other kinds of traffic, such as HTTPS sessions and ICMP probes, and for inbound port access — a sign the system classifies traffic in more detail than a bare protocol name could suggest on its own.
That said, it's worth being upfront that this Classification detail still lives mainly within Modbus and network-flow-level traffic. If your site includes EV chargers, that boundary matters: zcrOT has no dedicated signature for OCPP (Open Charge Point Protocol), the protocol an EV charger actually speaks to its backend directly. That means detection around an EV charger works from the network traffic flowing in and out of the charger's IP — not by parsing OCPP messages at the protocol level. An organization that needs visibility down to the OCPP message level will need a specialized tool on top of this. That's a real limitation worth knowing upfront, not something to gloss over.
This kind of protocol-scope gap is also a place where zcrOT genuinely trails the global players. If you're weighing zcrOT against Claroty, Nozomi Networks, or Dragos, there's a straight, no-bias comparison already written up at zcrOT vs. Claroty, Nozomi Networks, and Dragos.
Wrapping Up
Everything covered here — the Allow List defining what's normal, Device Mapping turning IPs into readable names, Detection Rules setting the conditions that must trigger an alert, and finally Incidents carrying a risk score to prioritize by — is what lets an OT team skip manually combing through raw traffic line by line, without having to trust an unexplainable black box either. Every alert comes from a rule whose condition is written out, so there's always an answer to why it fired.
If you want the bigger picture on why OT work is fundamentally different from IT from the ground up, keep reading at OT Security for Industrial Facilities. And if you'd rather click through the real thing yourself — no signup required — head to the zcrOT demo, or see the full plan lineup on the pricing page.
Talk to Our Team
Want to know which rules fit your OT network? Talk to our team — it's free, no strings attached.
Sources
- RFC 5737 — IPv4 Address Blocks Reserved for Documentation — sets aside three IPv4 blocks (the TEST-NET ranges) for documentation and examples, so an address taken from them never points at a real system
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security — confirms ICS/OT systems require high availability, real-time processing, and deterministic behavior, making their security needs meaningfully distinct from general IT — supports the article's underlying reasoning for why deterministic detection still has a place, though NIST doesn't address the ML-explainability argument directly