The Purdue Model as a Segmentation Contract, Not a Diagram

The Purdue Model, often visualized as a stack of levels from enterprise systems at the top to controllers at the bottom, is not merely a diagram but a contract for managing security in industrial control systems. This contract is founded on the principle that traffic crossing between zones must pass through a clearly defined, inspected path.

The levels in this model categorize systems based on their functions rather than trust levels, which means that supervisory systems, manufacturing execution layers, and enterprise layers are grouped together based on what they do, not on how secure they are. This functional grouping is crucial for understanding the plant's operations but does not inherently enhance security on its own.

The key to enhancing security within this model lies in turning these levels into zones, each representing a set of assets that share similar security requirements. Conduits, then, are established as the only sanctioned paths that allow traffic to move between these zones. Unlike physical cables, conduits are policies that specify protocols, host origins and destinations, and the direction of traffic.

Every crossing between zones must be inspected through these defined conduits, serving as the enforceable part of the model.

The directionality of traffic is highlighted as a critical aspect of the design. A path that permits both a request and a response is distinctly different from one that allows either side to initiate traffic. Most industrial traffic follows a natural direction, and enforcing this directionality helps mitigate many security issues. When a conduit must support bi-directional traffic, it should be clearly documented and justified.

The most significant boundary in this model is the one between the operational network and all other systems. This boundary merits a dedicated zone with its own services, hosting only those systems that absolutely require interaction from both sides of the boundary. Avoid placing general-purpose systems in this intermediate zone, as it undermines the model's purpose of preventing a compromise on one side from automatically compromising the other.

Modern developments, such as connected field devices reporting directly to cloud services and remote maintenance access, challenge the traditional boundaries of the model. These new pathways must still be described, inspected, and logged as conduits, ensuring that the model's integrity is maintained despite these changes. The Purdue Model serves as a framework to question and scrutinize traffic flows rather than to completely isolate systems.

While segmentation restricts what can reach a system, it does not prevent what a system does once it is compromised. Operators should maintain narrow permissions on accounts, workstations should be safeguarded against malware, and removable media should adhere to strict policies.

Testing the segmentation contract is essential to ensure its effectiveness. By attempting to reach services in one zone from a host in another, and verifying that the outcome aligns with the designed rules, potential weaknesses can be identified and corrected. This testing should be scheduled regularly, as rules and exceptions can evolve over time.

Documentation of the zone list, conduit list, and associated rule sets should be centralized, linking each control to the relevant standard and keeping this mapping updated. This documentation should be readily accessible to auditors, who can then verify enforcement of boundaries through documented outcomes and test results, rather than relying on anecdotal evidence.

Conceiving the Purdue Model as a contract rather than a diagram shifts the focus from mere placement of systems into a structured approach that demands clear, enforceable rules for traffic flow. This framing encourages a more rigorous review process, leading to better-informed decisions and more effective security measures in industrial environments.