Segmentation Requirements Under a 90-Day Insurer Deadline at a Water Utility
NorthBridge Water Utility operates 14 treatment plants on a flat OT network with 1,200 programmable logic controllers and 60 Windows Server 2008 HMIs. An insurer-sponsored penetration test showed that a compromised business laptop could reach the plant historian in three hops, and that one shared local administrator password is used on every HMI. The utility has a 99.99% uptime obligation, no OT security specialists, and a predictive-maintenance vendor that insists on unattended remote access through a persistent VPN. Operations has refused a full network rebuild during the four-month wet season. You are the business analyst engaged to write requirements for phase one of segmentation. The CISO wants "zero trust everywhere" by year end; the plant manager wants "nothing that requires a reboot." Phase-one budget is capped at $400,000, and the insurer requires evidence of compensating controls within 90 days.
1. How do you turn the CISO's and the plant manager's positions into requirements that can actually be verified?
Read the worked answer
Neither statement is a requirement; both are positions that hide a solution and a constraint.
Steps I would take:
- Separate the categories. "Nothing requiring a reboot during the wet season" is a business constraint, recorded with its rationale (uptime obligation, seasonal demand) and its expiry date. "Zero trust everywhere by year end" is a goal statement that must be decomposed. Mixing them produces untestable requirements.
- Recast goals as measurable outcomes. Instead of "zero trust," elicit the observable outcome: for example, the historian shall be reachable only from a defined set of source hosts, with each connection authenticated per-session and logged. Each clause has a fit criterion a tester can check.
- Trace upward. Every requirement links to the insurer's control objective (the compliance driver) or the uptime obligation (the business driver), so the 90-day evidence pack is traceable.
- Use a context/data-flow view first. Diagram which zones must talk to which, then write interface requirements for each allowed flow. This exposes where the vendor VPN and shared admin password actually sit before anyone argues about products.
- Record stakeholder disagreement explicitly in a decision log rather than smoothing it over; where operations and security genuinely conflict, the requirement states the trade-off and who accepted the residual risk.
2. Given a $400,000 cap and 90 days, how do you prioritize, and what do you do about the persistent vendor VPN?
Read the worked answer
Prioritization basis: risk reduction per dollar per week of effort, filtered by the constraint that nothing may force a plant reboot inside the wet season.
- Score each candidate against two axes: likelihood/impact from the pen-test findings, and delivery feasibility inside 90 days. Shared local administrator credentials on all HMIs and the three-hop path to the historian both score high on risk; a full zone rebuild scores low on feasibility.
- Sequence: (a) replace the persistent vendor VPN with brokered, session-recorded, MFA-protected access to named hosts, with an allow-list of the telemetry destinations; (b) remove the shared HMI password via a managed local-password mechanism, scheduled plant-by-plant in the dry window or applied where a maintenance restart is already planned; (c) interpose a firewall/one-way data path between business and OT so the three-hop path is broken even before full segmentation.
- Document what $400k does not buy. The remaining rebuild becomes a phased roadmap item, with the residual risk and its owner named. The insurer's evidence pack is built from the acceptance criteria of the phase-one items, not from a promise of full zero trust.
- Watch the vendor dependency: the persistent-VPN requirement is contractual, so the replacement must be negotiated as a contract change, not merely specified as a technical requirement.
3. Write the acceptance criteria you would attach to the "compensating controls" requirement so the insurer will accept the evidence pack.
Read the worked answer
Acceptance criteria must describe observable evidence, not intent. For each control I would specify:
- What is demonstrated: e.g. "a connection attempt from the business VLAN to the historian on port 502 is denied and logged, demonstrated by a dated packet capture and the firewall log line."
- Where the evidence lives: named system, report or screenshot, retention period, and who signs it.
- Who validates: an independent party (the analyst, internal audit, or the insurer's assessor) - not the team that built the control.
- Pass condition: binary and unambiguous, e.g. "100% of HMI hosts show a unique local administrator credential in the inventory extract" or "zero successful direct connections from business zone to OT zone in a 14-day sample."
- Exception handling: a documented, time-bound, risk-accepted exception list - the insurer will ask, and an undocumented exception looks like a failed control.
- Traceability: each criterion carries the ID of the requirement and the control objective it satisfies, so the evidence pack maps one-to-one to the insurer's framework.
The test of a good criterion here: could a third party with no project history verify it from the artifacts alone in under an hour?