The Purdue Model as a Segmentation Contract, Not a Diagram

The reference diagram is the part everybody remembers: a stack of levels, with enterprise systems at the top and controllers at the bottom. The diagram helps in a briefing and does nothing as a control. What carries the security value is the rule underneath it, which says traffic crossing a boundary must pass through a defined, inspected path. Write that rule down, and the diagram becomes a contract rather than a picture.

Levels describe function, not trust

Each level groups systems by what they do. Supervisory systems collect data from controllers; a manufacturing execution layer coordinates production; an enterprise layer runs business applications. Grouping by function makes a plant understandable, and it does not by itself make anything safer. The safety comes from deciding what may pass between the groups and enforcing that decision on the path between them.

Zones and conduits as the enforceable part

Take the levels and turn them into zones, where a zone holds assets with the same security requirements. Then define the conduits, the only sanctioned paths between zones. A conduit is not a cable; it is a policy: which protocols, from which hosts, to which hosts, in which direction. Every crossing gets inspected there. Written this way, a zone diagram can be tested against firewall rules, and the differences between the two are findings.

Direction is half the design

A path permitting a request and its response is not the same as a path permitting either side to initiate. Most industrial traffic has a natural direction, and enforcing it removes a large class of problems. Where a conduit has to carry both directions, say so explicitly and record why. A rule set nobody can explain in one sentence is a rule set that gets widened during the next outage.

The boundary that matters most

The busiest boundary sits between the operational network and everything else. Give it a dedicated zone with its own services, and let it hold only the systems that genuinely have to be reachable from both sides. Do not place a jump host there because it was convenient. The intermediate zone exists so a compromise on one side is not automatically a compromise on the other, and general-purpose systems inside it defeat that purpose.

Where the model strains

Two developments press on the hierarchy. Connected field devices now report to cloud services directly, which crosses several zones at once and bypasses the paths the model assumes. Remote maintenance access opens a route into the lowest levels from outside the plant. Neither development invalidates the design; both require the crossing to be described, inspected, and logged like any other conduit. The model is a way to ask the question, not a way to avoid it.

Segmentation is not isolation

A zone boundary restricts what can reach a system. It does not restrict what a system does once a user is on it. Operators need accounts with narrow permissions, workstations need protection against ordinary malware, and removable media needs a policy. Teams treating a firewall as the whole answer end up with excellent perimeter control and an incident arriving through a maintenance laptop.

Test the contract

A segmentation design is a set of claims, and claims can be tested. From a host in one zone, attempt to reach a service in another and confirm the outcome matches the design. Do it on a schedule, because rules drift and a temporary exception often outlives its reason. Record the outcome, and treat an unexpected success as a defect with an owner rather than an anecdote.

Documentation that an auditor can read

Keep the zone list, the conduit list, and the rule sets implementing them in one place. Note which standard each control maps to, and keep that mapping current. When the plant changes, the change record should point at the conduit it affects. An auditor asks how you know the boundary is enforced; the answer is a document plus a test result, and both should be easy to find.

Why the framing helps

Calling the model a contract changes the conversation. A diagram invites an opinion about where a system belongs. A contract asks a question with an answer: does the traffic this system needs cross a boundary, and if so, which conduit carries it and what does that conduit permit. Questions like that produce decisions, and decisions can be reviewed.