Flat Plant Network, One Budget Line
A manufacturer operates a plant network with 40 programmable logic controllers, 12 engineering workstations, and a historian, all on a single flat VLAN shared with corporate desktops. A systems integrator and two equipment vendors share one VPN account with a static password to troubleshoot; their session logs are not collected. Last quarter corporate IT ran an authenticated vulnerability scan from a plant laptop and faulted a controller, halting a packaging line for four hours. The plant manager has ruled out any change requiring production downtime. The CISO has budget for exactly one project this year and must choose between microsegmentation software, an OT-aware intrusion detection sensor, and a hardware-enforced vendor access gateway.
1. Which of the three options do you fund first, and what material risk does your choice leave unaddressed?
Read the worked answer
Fund the vendor access gateway.
Reasoning by likelihood × impact rather than by technical elegance:
- The shared static credential is the most probable path to a plant-impacting event: it is remote-reachable, unmonitored, shared across three external parties, and cannot be attributed to a person. It also scales badly - one leak compromises every vendor relationship at once.
- A gateway is out-of-band and non-disruptive: it can be inserted in front of the existing VPN without touching PLCs or requiring downtime, satisfying the plant manager's constraint.
- It converts an anonymous shared credential into per-person, MFA-protected, time-boxed, recorded sessions - which is also the control auditors and insurers ask about first.
What it does not fix: the flat Layer 2 domain. Every engineering workstation and corporate desktop can still reach every controller directly, so a phishing email on a plant laptop remains a path to the PLCs. The gateway protects the vendor door, not the internal corridors.
The correct framing to the CISO: this is sequencing, not exclusion. The gateway is phase one because it is the highest-likelihood path and the only one deliverable without downtime; segmentation is phase two and should be funded in the next cycle, with the residual risk documented in the interim.
2. A colleague proposes simply moving the PLCs into their own VLAN as a quick fix. Explain why that alone is weak here, and what would have to accompany it to make segmentation real.
Read the worked answer
A VLAN is an addressing/scope construct, not an enforcement boundary. Without enforcement it changes almost nothing:
- Hosts in different VLANs still route through a device that, if it permits inter-VLAN routing broadly (the usual default during migration), provides no more restriction than before. The control is the policy on the conduit, not the VLAN tag.
- Devices deliberately dual-homed (an engineering workstation with one NIC on plant and one on corporate - common in practice) bridge the two segments and dissolve the boundary.
- Layer 2 weaknesses - VLAN hopping via switch-port negotiation, ARP spoofing, CAM table exhaustion - mean a determined attacker on the corporate side is not reliably stopped by tagging.
What must accompany it:
- Conduit model - a small number of defined, documented paths between zones (e.g., historian → DMZ replica → corporate), each with an explicit allow-list of protocols, source/destination, and direction, enforced on a firewall or industrial firewall.
- Default deny between plant zones and corporate, with deny logged.
- Port security and no dual-homing on access switches; disable unused ports; separate management VLAN.
- Change control with the plant - OT segmentation is validated in a maintenance window with the vendor present, never during a live run.
Without items 1–4, the VLAN is paperwork. With them, it is the same architecture the microsegmentation product would sell you, minus the licence.
3. How should the scanning incident change your testing approach for this environment, and what would you refuse to authorize?
Read the worked answer
The incident is a governance failure as much as a technical one: an IT process was applied to an OT asset base without the plant's consent, and the consequence was availability loss - which in OT is the crown jewel, ahead of confidentiality.
Changes:
- No active scanning from production OT hosts, ever, without written plant-owner authorization and a defined window. Put this in the testing policy, not in tribal knowledge.
- Prefer passive discovery - span/mirror port to a passive asset-identification sensor identifies devices and protocols without injecting traffic. This is why the IDS sensor remains valuable even though it is not the first purchase.
- Test against a replica - vendor lab, spare PLC on a bench, or a staged line - for anything that probes protocol behaviour.
- Use the safety settings that exist - 'safe checks'/low-concurrency modes, and exclude fragile device classes by address range.
- Two-key authorization: IT security plus the plant manager sign off on any active test, with a rollback/abort criterion and a named person on the floor during the window.
What I would refuse: any authenticated or aggressive scan of live controllers outside a change window, and any scan whose abort criteria are undefined. 'We scanned and it was fine last time' is not authorization, and the four hours of lost packaging is the cost of treating OT as if it were a data centre.