Zones and conduits: start from the risk, not from the switch

Segmentation projects usually start with a list of switches and a wish to get rid of a few flat VLANs. That is a network project. A security project starts one step earlier, with a question that has nothing to do with hardware: what happens to the product, the people and the plant if this group of assets is compromised?

The difference shows a year later. A network-first design produces a tidy diagram, and when someone asks why the packaging line and the utilities share a zone, the only answer is that they shared a switch. A risk-first design can answer that question for every boundary on the drawing.

How we run it

A workable zone model comes out of four passes over the same installed base.

1. Inventory. Every asset, including the ones nobody maintains: the vendor PC under the conveyor, the old HMI that still talks to the historian, the wireless bridge someone added to reach the warehouse.
2. Consequence. What each asset can do to the product, to safety and to availability if it misbehaves or is taken over.
3. Grouping. Assets that share a consequence and a level of trust become a candidate zone.
4. Target. Each zone gets a target security level, and each path between zones becomes a conduit with its own requirements.

Only then does the network design start, and by that point most of it has been decided. IEC 62443-3-2, the part of the series that deals with risk assessment for system design, follows the same order: define the system under consideration, assess the initial risk, partition it into zones and conduits, then carry out a detailed risk assessment that sets a target security level for each zone. The switches come afterwards.

What usually comes out of the workshops

The first surprise is almost always the inventory. On a typical site the walk-down finds assets that are on no drawing, and connections that were made for a commissioning and never removed. The second surprise is that the consequence pass regroups things engineering had kept apart, and splits things IT had kept together. A process skid and its local HMI belong together; the same skid and the office printer on the next floor do not, even if they share a VLAN today.

The workshops work best with three people in the room who rarely sit together: the process or production engineer who knows the consequences, the automation engineer who knows the systems, and the network or IT person who will build the result. Two half-day sessions per production area is a realistic pace.

Legacy assets are the test

Every site has a PLC that cannot authenticate, cannot be patched and cannot be replaced before the next major shutdown. The 62443 series has an answer for it: the asset goes into a zone of its own, behind a device that enforces the conduit, and a compensating countermeasure covers what the controller cannot do itself, with the reason written down. What it must never become is an exception nobody recorded.

Recording it is the whole point. A documented exception has an owner, a review date and a risk someone accepted. An undocumented one is a hole in the model that the next engineer will not know about.

What the zone model is really for

The drawing is a by-product. What the model gives you is a list of decisions you can defend: why this zone, why this boundary, why this exception, who agreed. That list is what an auditor asks for, what a new project has to fit into, and what tells the network team which firewall rule protects what.

A zone model that took three workshops and produced eight zones is worth more than a perfect diagram drawn in an afternoon with twenty.

References

• IEC, IEC 62443-3-2:2020, Security for industrial automation and control systems, Part 3-2: Security risk assessment for system design.