Segmenting a Flat Network That Stops Production When Touched
Nordhaven Precision manufactures components at three plants and runs a single flat /16 for everything: 380 engineering workstations, an ERP cluster, a 700-seat call centre, and 12 CNC cell controllers that run Windows XP and 7, are vendor-locked and cannot be patched. Last month a phished workstation spread ransomware over SMB to 40 servers in three hours, using one shared local administrator password unchanged since 2016. The maintenance vendor for the CNC cells connects through a site-to-site VPN with an any-to-any rule and a shared account named service. A segmentation programme has been proposed at USD 1.9M over three years. The CFO has approved USD 600k for the coming year and wants measurable reduction in the specific attack path seen, not a maturity score. The plants run 24/7, stopping a cell for network changes costs roughly USD 40k per hour of lost output, and a 20-minute maintenance window per cell per week already exists.
1. Draw the target zone boundaries and identify the enforcement points you would use in year one, given that a full microsegmentation build is unaffordable.
Read the worked answer
Zone by required communication and trust, not by org chart. Target zones: cell/OT (CNC controllers and their engineering laptops), ERP and MES, call-centre agents, general user workstations, server/management, and a small vendor-access DMZ. The rule is a documented allowlist of what must talk to what - for example controller to MES historian on a specific port, nothing else.
Enforcement in year one should be layered from cheapest to most expensive. At the existing L3 core, VLANs plus ACLs separate call centre, users and servers, and block workstation-to-workstation SMB outright; that alone breaks the propagation path seen in the incident. On hosts, Group Policy firewall rules and unique local administrator passwords remove the shared-credential lever. The OT boundary gets a dedicated industrial firewall pair, configured by exception, because ACLs on the core switch cannot inspect the OT protocols and cannot express the tight allowlist the cells need.
Be explicit about the readdressing cost: a flat /16 means subnet changes on devices that may not tolerate them. Where a controller cannot be readdressed, place it behind the firewall as a host rule rather than forcing a move. Document which zones are enforced, which are only monitored, and the residual flat areas.
2. Spend the USD 600k. Give the sequence, the justification, and what you would explicitly not fund.
Read the worked answer
Sequence by attack-path reduction per dollar and by speed to value:
- Weeks 0-8, well under USD 50k: unique local administrator passwords via a managed password solution, block workstation-to-workstation SMB, disable SMBv1, restrict service accounts, remove local admin rights from the 380 engineering workstations. This kills the exact mechanism that took 40 servers in three hours.
- Weeks 0-6: rework the vendor VPN. Terminate it at a jump host in a DMZ with MFA, per-ticket approval, session recording and named accounts, limited to specific controller addresses. Cost is mostly effort plus a PAM licence.
- Months 2-6, roughly USD 250-300k: OT boundary firewall pair per plant, designed and configured before the maintenance window, with rollback tested on one cell first. Budget the outage: 12 cells at 20 minutes, plus contingency, is a real cost and must be in the plan.
- Months 6-12: call-centre VDI and user-zone ACL refinement with the remainder.
Do not fund the first phase of a three-year, USD 1.9M programme if it delivers no enforcement for twelve months. Do not fund a full microsegmentation agent rollout before the network has zones. Hold a reserve for the outage costs.
3. How do you handle the unpatched XP and 7 controllers and their vendor access in the meantime, and what evidence would show the treatment is working?
Read the worked answer
Treat the controllers as untrusted-by-default assets that cannot be hardened in place, and compensate at the boundary and the host. On the boundary: deny internet egress, allow only MES and historian traffic on named ports, log all deny events and alert on them. On the host where the vendor permits it: application allowlisting, host firewall, disabled removable media, no email or browsing. Require a written vendor upgrade roadmap with contractual milestones and cost it into the renewal negotiation; a risk acceptance with no expiry and no vendor commitment is just a deferred decision.
For vendor access, remove network-level reachability entirely. Vendors should land on a jump host, authenticate as named individuals with MFA, be authorised per ticket and time-boxed, and be recorded. Shared accounts named service are unacceptable - they make attribution impossible and survive staff turnover.
Evidence of success: count of blocked workstation-to-workstation SMB attempts, number of hosts still sharing local administrator credentials (target zero), count of vendor sessions outside approved windows, alert-to-triage time on OT deny logs, and a re-run of the original attack simulation from an engineering workstation to confirm it no longer reaches the ERP cluster.