The Detection Gap Nobody Talks About: Why Purdue Level 1 Is Where Attacks Succeed
The Purdue Model has been the reference architecture for industrial control system security for over three decades. Every OT security practitioner can sketch it from memory: Level 4 is the enterprise, Level 3 is operations management, Level 2 is supervisory control, Level 1 is the controllers themselves, and Level 0 is the physical process — the pumps, valves, motors, and sensors.
And here is the uncomfortable truth about how most organisations actually deploy security monitoring: they stop somewhere around Level 2.
They have firewalls between IT and OT. They monitor the engineering workstation. They collect logs from the HMI. They might even have an IDS sensor watching the control-room switch. But the traffic between the PLC and the field devices — the commands that actually open valves, start motors, and change setpoints — that traffic traverses the network unexamined. Every day. In thousands of facilities.
This is not negligence. It is physics. Level 1 networks run on protocols that were designed decades before anyone thought about authentication — Modbus, DNP3, PROFINET, EtherNet/IP, S7comm. These protocols assume that if you are on the network, you belong there. There are no usernames. No passwords. No session tokens. A valid Modbus write that changes a pump setpoint from 60% to 100% looks identical on the wire whether it came from the authorised engineering workstation or from an attacker who pivoted through a compromised IP camera three subnets away.
What Signatures Can See at Level 1 — and What They Cannot
A signature-based detection tool watching Level 1 traffic has exactly one job: compare every packet against a database of known-bad patterns. It can flag a Modbus packet that contains a known exploit payload for a specific firmware version. It can alert on a DNP3 request with malformed object headers that match a published CVE. It can detect the scanning pattern of a known reconnaissance tool.
Here is what it cannot do — and this is the structural limitation that defines the Level 1 problem:
It cannot tell you that a completely well-formed, protocol-compliant Modbus write is malicious because it originated from a device that has never issued a write command before. It cannot flag that a controller suddenly began communicating with a field device it has never talked to in three years of operation. It cannot notice that the inter-packet timing on a PROFINET conversation shifted from its characteristic 16-millisecond heartbeat to a jittery 40-millisecond cadence — consistent with a relay or proxy inserted into the path.
All of these are real attack patterns. Every one of them has been documented in actual OT incidents. And not one of them triggers a signature.
The TRISIS Precedent
The 2017 TRISIS attack on a Saudi petrochemical facility remains the canonical case study. The attackers did not exploit a software vulnerability. They did not deploy malware that any antivirus engine could recognise. They understood the Triconex Safety Instrumented System well enough to write a custom payload that reprogrammed it — using the vendor’s own protocol, with valid command syntax, over an authorised network path.
A signature-based tool watching that traffic would have seen legitimate Triconex protocol operations. Nothing matched a known-bad pattern because no known-bad pattern existed yet. The attack was novel — the very category that signatures, by definition, cannot catch.
What a behavioural baseline would have seen is different. A safety controller that had spent its entire operational life receiving read-status queries suddenly receiving a firmware write command. A device that had always communicated exclusively with its engineering workstation suddenly accepting a connection from a workstation it had never seen before. A protocol conversation whose structure — not content, structure — diverged from every previous conversation in the network’s history.
These are not signature matches. They are baseline deviations. And at Level 1, where every protocol interaction is deterministic and repetitive, baselines are unusually powerful — because the normal behaviour is unusually narrow.
Why Most Organisations Leave Level 1 Dark
The reasons are practical. Level 1 networks often run on serial connections or legacy fieldbuses that are physically difficult to tap. The protocols are proprietary or poorly documented. The traffic volumes are low but the consequences of disruption are catastrophic — nobody wants to be the person who dropped a production line by attaching a monitoring probe.
But the biggest reason is conceptual. The industry spent twenty years convincing itself that the critical boundary was between IT and OT — between Levels 3 and 4, or 4 and 5 in the expanded Purdue model. Secure that boundary, the logic went, and the lower levels are protected. TRISIS demonstrated that this logic is wrong. The attackers were already inside the OT network. The boundary had been crossed long before the payload executed. The only question was whether anything was watching the traffic inside the perimeter.
That question remains unanswered in most facilities today.
What Behavioral Detection Actually Does at Level 1
A passive network detection and response platform — deployed at the Level 1 switch or tap point — learns the normal communication patterns of every controller and field device on the segment. It builds a model not of what traffic should look like (that is policy-based, and policies drift), but of what traffic does look like over weeks and months of operation.
From that model, it surfaces deviations:
- A controller that suddenly issues write commands after a year of read-only operation
- A field device that begins communicating with a new peer for the first time since commissioning
- A protocol conversation whose timing signature shifts — consistent with a man-in-the-middle relay
- A burst of reset or diagnostic commands at 3 AM from a workstation that operates exclusively during day shifts
None of these require signatures. None of them require knowledge of the specific exploit or CVE. They require knowing what normal looks like — and flagging when reality diverges.
The Practical Reality
The OT community is not going to replace its Level 1 protocols. Modbus is fifty years old and it is not going anywhere. DNP3 is embedded in thousands of substations and will outlast every cybersecurity framework currently in circulation. The path forward is not to add authentication to protocols that cannot support it — it is to add visibility to networks that currently have none.
That visibility has to be passive. It cannot add latency. It cannot inject packets. It cannot risk disrupting a deterministic control loop. It has to work on the protocols that actually exist in the field, not the ones that would exist in an ideal world. And it has to surface deviations clearly enough that a plant engineer — not a SOC analyst in a distant city — can understand what changed and why it matters.
These are not aspirational requirements. They are the table stakes for any detection capability that operates at Level 1. And they define exactly the category of tooling that the industry needs to deploy at scale — not someday, not in the next budget cycle, but now. Because the attackers are already at Level 1. The question is whether anyone is watching.
Maigadi — the OT/ICS network detection & response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.