The Flat Network That Cannot Be Split
Meridian Fabrication runs four plants on a flat /16 carrying both corporate IT and plant-floor traffic. Last month a contractor laptop with commodity malware was plugged into a floor switch and reached the corporate print server in nine minutes; nothing else happened only because the malware was untargeted. There are roughly 12,000 OT devices, including 40 press controllers from 2003 that speak a proprietary protocol with no authentication and cannot be patched or replaced before 2028. Full Purdue-model segmentation requires taking lines down at $180K per hour, and you get one six-hour maintenance window per quarter. The approved budget is $700K for the first 12 months. Plant managers trust the network they have and still blame security for a missed shipment in 2022.
1. Lay out the first 12 months of work and defend the sequencing.
Read the worked answer
Sequence by (probability × blast radius) per dollar, not by architectural elegance.
Months 1–3, mostly no downtime:
- Passive OT asset discovery and traffic baselining. Do not active-scan fragile PLCs - you will drop a press and lose the plant managers permanently.
- Disable unused switch ports and enforce port security on floor switches; kill the contractor-laptop path first, because that is the path that already fired.
- Stand up an IT/OT conduit at the boundary (firewall or existing switch ACLs) restricting plant traffic to the small set of flows it actually needs to corporate. This is the single highest-value cut and it can be done in one window for the four plants' uplinks.
- Replace shared remote-access with a jump host plus MFA for vendors and engineers.
Months 4–9: segment within OT cell by cell, pre-staging configuration ahead of each six-hour window so the window is a cutover, not a design session. Conduits between cells, not a mesh.
Months 10–12: passive monitoring with alerting on new cross-zone flows; USB control; documented device inventory with named owners.
Defence: the first quarter is spent where the last incident actually happened and where a change is reversible in minutes. You are buying time and evidence, not a finished architecture.
2. Where do you deliberately accept risk, and what makes that acceptance defensible?
Read the worked answer
Accept that the 40 press controllers remain flat and unauthenticated inside their own cell until 2028. Trying to fix them is how the program dies.
It is defensible only if you narrow the risk rather than ignore it:
- Containment, not protection. The controllers keep their flat segment, but that segment has exactly one exit: a conduit to the cell's own HMI/supervisor, and no route to IT, to other cells, or to the internet. The risk being accepted is "an attacker already inside this cell can talk to the press," which is much smaller than "any floor port reaches the corporate print server."
- Physical and access control on the cabinets and floor ports serving those cells.
- Detection - a passive sensor on that segment, and an alert on any new talker.
- Explicit, dated acceptance signed by plant operations, not just security, because operations owns the production loss.
- A 2028 replacement commitment with a budget line, so this does not become permanent by default.
Compare against the alternative you rejected: forcing a shutdown now costs $180K/hour plus the credibility you need for the next three windows. Accepting a bounded, monitored, documented residual to preserve the programme is a legitimate engineering judgement.
3. How do you measure whether this is working, given you cannot yet claim full segmentation?
Read the worked answer
Measure exposure and reachability, not "percent segmented" - that metric will sit near zero for years and will kill the programme's support.
Useful measures:
- Reachable corporate hosts from a floor port. Probe from representative floor ports to a fixed target list (print server, DC, ERP, file shares). This number should fall from "everything" to a defined small set. It is directly tied to the incident that actually happened.
- Count of allowed cross-zone flows versus baseline, and the number of new flows detected per month. New flows are either change you approved or something you did not.
- Time to detect a new device or a new talker on a floor segment.
- Percentage of OT devices with an owner, a documented role, and a baseline - the boring metric that makes everything else possible.
- Contractor and vendor access requests routed through the jump host (should trend to 100%).
Report these alongside the business metric the plant managers care about: unplanned downtime attributable to security changes (should be zero) and windows used versus windows available. A security programme in OT survives on the second number as much as the first.