Twenty-nine rules and a plastic PLC

Here is a fact that should be more alarming than it is: if you deploy a mainstream SIEM in front of an industrial control network, it will see Modbus traffic and have absolutely nothing to say about it.

Not "it will alert on the suspicious parts." Not "it needs tuning." Nothing. The protocol is unparsed, the traffic is a beige stream of TCP on port 502, and a message telling a programmable logic controller to open a valve looks exactly like a message asking it what time it is.

The commercial answer exists (Dragos, Nozomi, Claroty) and it is genuinely good. It also starts somewhere around $50,000 per site per year and climbs from there. If you are a national grid operator that is a rounding error. If you are a municipal water treatment plant with four PLCs and one IT person who also fixes the printers, you are simply not in the market, and so you stay blind.

OT Sentinel is my attempt at the floor beneath that market: 29 open-source detection rules covering Modbus, DNP3, IEC 104, MQTT and OPC-UA, in Wazuh XML and SIEM-agnostic Sigma, Apache 2.0, mapped to MITRE ATT&CK for ICS.

#Why these protocols are so easy to attack

Modbus was published in 1979 for serial links between devices in a locked room. It has no authentication, no encryption, no session concept and no notion of an unauthorised message. A write is a write. If you can reach port 502, you are already trusted, because the protocol has no vocabulary for distrust.

Then the industry wrapped it in TCP, put it on a routable network, and, in the reliably worst-case way these things go, connected that network to the business LAN so somebody could pull production numbers into a spreadsheet.

DNP3, IEC 104 and OPC-UA are each somewhat better. DNP3 has an optional secure authentication layer that is deployed roughly never. OPC-UA has real security and is frequently run with it disabled because the certificate handling is a nuisance. MQTT is in industrial deployments precisely because it is simple, which is another way of saying it will accept a publish from anyone who can connect.

The consequence for detection is unusual, and it took me a while to internalise it: you are almost never detecting a malformed packet. Every attack packet is a perfectly valid, protocol-conformant message. What makes it an attack is that the wrong device sent it, or it arrived at the wrong time, or it asked a question no legitimate engineering workstation would ever ask.

That means OT detection is mostly a set of assertions about who is allowed to say what to whom. Which is why nearly every rule in the pack leans on a CDB allowlist, and why those lists ship empty.

#What the rules actually look for

The 8 Modbus rules are the ones I trust most, so here is the shape of them.

Discovery. A function code 43 request, Read Device Identification, asks a PLC to identify its vendor, product code and firmware revision. An engineering workstation asks this approximately once, during commissioning. Something asking it of every address in a /24 is doing reconnaissance, and it maps cleanly to T0846, Remote System Discovery.

Unauthorised writes. Function codes 5, 6, 15 and 16 change the world: write single coil, write single register, write multiple coils, write multiple registers. Whether a write is an attack is entirely a question of source. Detection is therefore: a write function code from a source IP not in the authorised-master allowlist. T0855, Unauthorized Command Message. It is almost embarrassingly simple, and it is also the single highest-value rule in the pack.

Diagnostics abuse. Function code 8 is diagnostics, and its sub-functions include things like "restart communications" and "force listen-only mode." Listen-only mode means the PLC stops responding to the master while continuing to run its program. The operator's screen goes stale while the process keeps moving. That is T0858, Change Operating Mode, and it is the rule I would least like to see fire in anger.

Register scanning. Reading holding registers is normal. Reading every holding register across the full address range, sequentially, in under a second, is somebody mapping the process to figure out which register is the setpoint they want to change later.

Current ATT&CK for ICS coverage across all 29 rules is seven techniques, concentrated in four tactics: Discovery (T0840, T0846: 10 rules), Execution (T0855: 7 rules), Impair Process Control (T0814, T0836, T0855, T0856: 6 rules) and Inhibit Response Function (T0858: 2 rules). The gaps in the matrix are real gaps, not modesty.

#The lab, which is mostly plastic

You cannot test industrial detections on an industrial plant. Nobody will give you the plant, and if they do, you should decline.

So: OpenPLC as a soft-PLC that speaks real Modbus and runs real ladder logic, GNS3 for the network topology, Wazuh 4.14.5 as the SIEM, and Python test scripts using pymodbus to generate the attack traffic. Total cost: one afternoon and a VM.

The workflow that made this tractable was wazuh-logtest. You paste a log line in, and it tells you exactly which decoder claimed it, which rule matched, and why. Detection engineering without a fast feedback loop is guesswork with extra steps; with a good one it becomes something close to test-driven development. Write the trigger traffic, watch the rule fail, fix the decoder, watch it pass.

Which brings me to the part I want to be careful about.

#What "validated" actually means here

All 29 rules are validated with wazuh-logtest on Wazuh 4.14.5. That is a real result and it is worth something: it proves the decoder chain parses the traffic, the rule matches what it claims to match, and the alert carries the right ATT&CK mapping.

It is not the same as hardware validation, and the difference matters.

Only the 8 Modbus rules have been tested end to end against a real OpenPLC instance, with actual pymodbus scripts generating actual traffic against an actual soft-PLC running actual logic, with the alert appearing at the far end. The DNP3, IEC 104, MQTT and OPC-UA rules are logtest-validated only. Their test scripts are stubs. I wrote the stubs so that the gap is visible in the repository rather than buried in a caveat.

I could have written "validated against a real OpenPLC and GNS3 digital twin" across the whole pack. It would have been defensible-ish and nobody would have checked. But somebody is eventually going to deploy this in front of equipment that can hurt a person, and the day they find out my validation claim was doing more work than it earned is not a day I want to be responsible for.

Security has an unusually high tolerance for marketing language. I would rather be the boring, checkable one.

#What this is for

It is not a product. It will not replace a commercial OT platform and I would think less of anyone who claimed otherwise about their weekend project.

What it is: a way to stop being blind for free and, more usefully, a way to learn. Clone the repo, put OpenPLC in a VM, deploy the rules, then attack your own lab and watch what shows up at the SIEM. In an afternoon you will have a working mental model of what an OT protocol attack looks like from the detection side. That model is the actual deliverable. The 29 rules are just the fastest way I know to install it in your head.

The rules give you a baseline and a vocabulary. Your own environment, your own thresholds, your own asset inventory in those allowlists: that is what makes them real.

And if you have DNP3 hardware and a free weekend, I have four protocols that would very much like to be properly validated.

---

OT Sentinel is on GitHub under Apache 2.0. It is an independent community project, not affiliated with any ICS vendor and, despite the name, nothing to do with Microsoft Sentinel. Designed for passive network monitoring. Do not deploy it to a live plant without testing on your own hardware first. Respect the safety culture; it exists for reasons that predate all of us.