Segmentation for a Flat Plant Network
Corvane Components runs three manufacturing plants and a distribution center on a single flat /16 network with 1,200 managed endpoints. Programmable logic controllers on each plant floor share the same VLAN as office laptops, and contractor laptops plug into wall ports with no registration. In 2019 a phishing email on a plant office PC delivered a commodity banking trojan that scanned the /16, reached a historian server, and caused a 14-hour line stoppage; the post-incident report noted that no firewall existed between the plant floor and the office. Management has approved a segmentation program with two constraints: no production line can be stopped for more than a four-hour maintenance window, and the plant engineering team, not IT, must approve any change to control-system addressing. IT proposes one VLAN per plant plus a firewall at the core, and wants to deploy 802.1X on every switch port in the same phase.
1. Evaluate IT's proposed design. What would you change, and in what order would you deploy?
Read the worked answer
One VLAN per plant fixes almost nothing. In 2019 the path that mattered was not office-to-plant at a perimeter, it was east-west once the trojan was inside: it scanned the /16 and reached the historian. Per-plant VLANs at a core firewall leave every controller, engineering workstation, and historian inside the plant talking freely to each other, and the firewall becomes a single inspection point for the whole company.
Design zones by function and trust, mapped to the Purdue levels: controllers and safety systems at the lowest level, supervisory and HMI above them, site operations, a control-system DMZ holding the historian mirror, patch repository, jump host, and antivirus server, and the enterprise zone above that. Define conduits as allow-lists of specific source, destination, and port per application, documented in a zone-and-conduit matrix that plant engineering signs off. Deny by default; block-list rules do not survive contact with a scanner.
History matters: the historian that the trojan reached should never have been directly reachable from the office. A read-only replica in the DMZ, with the authoritative historian behind it, removes that path.
Sequence. Passive discovery first, no inline changes: span ports and flow data to inventory assets and protocols, because engineering owns the addressing and you cannot guess it. Then insert firewalls in monitor mode to build the allow-list from observed traffic. Then enforce one zone per maintenance window, smallest and least risky first, with a tested rollback. Put a redundant firewall pair between core zones, managed out of band, and never route control traffic through the corporate data center.
2. What are the risks of putting 802.1X on OT devices in the same phase, and how would you handle contractor ports?
Read the worked answer
802.1X assumes a supplicant. Most PLCs and many analyzers have none, so the fallback is MAC authentication bypass, and MAB authenticates a claim that is trivially spoofable. MAB is only meaningful when the port is nailed to one MAC, the port sits in a physically controlled space, and the assigned VLAN is the least-privilege one. It is a weak identity, not a strong one.
The bigger risk in this environment is availability. If the RADIUS infrastructure, the switch configuration, or the certificate chain fails during a maintenance window, a line stops, which breaches both the four-hour constraint and the rule that engineering approves control-system changes. Authentication failures become production outages.
So split the phase. Deploy 802.1X first on IT endpoints and contractor ports, where supplicants exist and a lockout costs an inconvenience. For contractor devices, require registration through a network access control portal with sponsor approval, posture check, and a quarantined VLAN until it passes; physical wall ports in plant areas get administratively disabled unless requested. Make the fail-open versus fail-closed decision per port and document it: fail-open with alerting on critical lines during transition, fail-closed with a break-glass process on office ports.
For OT devices, rely on the zoning and conduit work plus physical port control and switch port security. Revisit 802.1X for OT only when the asset inventory shows supplicant support.
3. How would you validate the segmentation before and after enforcement, given that engineering controls the change windows?
Read the worked answer
Validation is the part that gets skipped, and it is the part that decides whether the program survives its first incident.
Before enforcement: build the zone-and-conduit matrix from measured traffic, not assumptions. Span ports at the intended choke points for at least two weeks, including a month-end or production-change period, so you capture the batch jobs and engineering tools that only run occasionally. Anything not captured becomes a false block later. Where feasible, replicate the rule set in a lab against copies of the same controller and HMI configurations, then test the exact flows.
During enforcement: deploy in monitor mode first and compare blocked-candidate traffic against the matrix daily. Then enforce one zone per window with a written rollback that engineering has approved, and have the plant controls engineer on the call, not just IT. Define objective success criteria in advance: no unknown denied flows after 24 hours, control-loop latency unchanged, historian data continuity with no gaps.
After enforcement: prove the security property, do not assume it. Run a scan from an office VLAN to confirm the historian and controllers are unreachable, and repeat the 2019 path as a tabletop exercise with the EDR and network teams. Add continuous verification: firewall rule hit counts, alerts on denies between zones, and a quarterly review of rules added since the last review, because segmentation decays through exception requests faster than through design error.