OT Sentinel: ICS/OT Detection Rules

ot-sentinel-rules★ 1029 rules · 5 protocols · Apache 2.0

The problem

Major SIEM and XDR platforms ship with effectively zero detection coverage for OT protocols. The rules that do exist are proprietary, locked behind per-site contracts that run from $50K to $200K with Dragos, Nozomi or Claroty. That pricing is fine for a national grid operator. It leaves small water treatment plants, distribution substations and single-site factories completely blind.

What it covers

Twenty-nine rules across five protocols: 8 for Modbus, 7 for DNP3, 6 for IEC 104, 5 for MQTT and 3 for OPC-UA. Each ships in two formats: Wazuh XML with custom decoders for direct deployment, and SIEM-agnostic Sigma YAML for everyone else.

Every rule is mapped to MITRE ATT&CK for ICS. Current coverage spans seven techniques concentrated in the tactics that matter most for a plant: 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).

CDB allowlists ship alongside the rules, because almost every OT detection is really a statement about which devices are authorised to speak to which other devices. The lists are empty templates by design. Populated with someone else's asset inventory they would be worse than useless.

How it was validated

All 29 rules are validated with wazuh-logtest against Wazuh 4.14.5. That confirms the decoder chain parses correctly and the rule fires on the traffic it is meant to fire on.

Hardware validation is narrower and it is worth being precise about it: all 8 Modbus rules have been tested end-to-end against a real OpenPLC instance in a GNS3 lab, with Python test scripts using pymodbus that generate the actual attack traffic. The DNP3, IEC 104, MQTT and OPC-UA rules are logtest-validated but not yet hardware-validated. Their test scripts are stubs.

That gap is the most useful contribution someone could make to the project.

The honest pitch

This is a detection engineering accelerator, not a product. Clone the repo, spin up OpenPLC in a VM, deploy the rules to Wazuh, and in an afternoon you will understand what OT protocol attacks look like at the SIEM layer.

The value is in what you learn deploying them rather than in the 29 rules themselves. The rules give you a working baseline and a vocabulary; your own environment is what makes them real.

The safety culture in OT is not decoration. These rules are designed for passive network monitoring. Nothing here should be deployed to a live plant without testing on your own hardware and tuning thresholds to your own traffic.

Scope and limits

Every project page on this site carries this section. If a tool is not ready for something, the honest place to say so is next to the claim, not three pages into a README.

  • Not production-ready. Treat it as an educational resource and a starting point, not a drop-in replacement for a commercial OT platform.
  • Hardware validation currently covers Modbus only. The other four protocols are logtest-validated.
  • PROFINET, EtherNet/IP, BACnet and HART-IP are not yet covered.
  • CDB allowlists ship empty. They must be populated with your own authorised device inventory before any rule that references them is meaningful.
  • Independent community project with no affiliation to any ICS vendor or to Microsoft Sentinel, despite the name.
THE LONG VERSIONTwenty-nine rules and a plastic PLCMajor SIEMs ship with zero coverage for the protocols that run industrial plants. I spent a few months building 29 rules for the five that matter, and learning why the honest answer to "is it validated?" is longer than yes.7 min read →

Building something in this territory, or hiring for it?

← All workNIST CSF Rule Pack →