OT Protocol Network Sensor
SHIPS WHENA sensor that turns captured ICS traffic into structured logs, plus a labelled capture corpus, wired end to end into the existing OT Sentinel rule set.
The problem
OT Sentinel is a rule set with no sensor under it. The rules assume something upstream has already parsed Modbus function codes and DNP3 objects off the wire, and in most small plants nothing has. Buying that parser is a six-figure line item, which is the same gap the rules were written for.
The scope
Passive parsing only, on a span or tap. Nothing is written back to the process network, because the safety culture in OT is not decoration and a sensor that can transmit is a sensor that can hurt something.
The output contract is the useful part: the sensor emits events in the shape OT Sentinel already decodes, so the two repos become one working system instead of a rule set and a parser that happen to share an author.
A second output is a labelled capture corpus from the OpenPLC lab. Public ICS traffic captures with attack labels are scarce, and that scarcity is the reason the existing rules for four of the five protocols are still logtest-validated rather than hardware-validated.
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.
- No repository exists yet. This entry describes committed scope, not shipped work.
- Lab traffic is generated traffic. It is not a substitute for captures from a running plant.
Building something in this territory, or hiring for it?