Municipal Water Utility: Shared Remote Zone Proposal
A mid-sized municipal water utility operates a 120 MLD treatment plant, 14 remote pumping stations, and 9 reservoirs. The SCADA master at the plant polls RTUs over licensed UHF radio and 4G VPN links. Six RTUs run firmware from 2011 and cannot support TLS, per-user accounts, or logging. A tabletop exercise showed that a compromised vendor laptop at a pump station could reach the plant historian and the corporate email subnet. The utility has an ISA/IEC 62443-2-1 CSMS but no formal zone and conduit inventory. Operations insists that any segmentation change must not interrupt 24/7 supply and must fit a 10-week maintenance window. The board has funded firewalls and a managed security service but not PLC or RTU replacement. A consultant proposes one perimeter firewall around all remote assets and a single shared 'remote' zone for all 14 stations.
1. Evaluate the consultant's single shared 'remote' zone proposal. Using ISA/IEC 62443-3-2 reasoning, define a zone and conduit model you would recommend and explain how you would set SL-T for the remote stations.
Read the worked answer
Reject a single shared 'remote' zone. 62443-3-2 groups assets by common function, criticality and security requirements, not by geography. The 14 stations differ: a reservoir overflow or a high-service pump trip has different consequences, and vendor access paths differ. I would create: (1) a plant control zone containing SCADA/historian and the plant RTUs; (2) a remote pumping zone for stations with similar consequence and connectivity; (3) a separate reservoir zone if telemetry and local control differ; (4) a remote-access conduit zone for vendor and staff access; and (5) conduits from each zone to the DMZ/historian. SL-T is set from the risk assessment, using worst credible consequence and threat, not from what the RTU can do. For example, if a station can cause loss of supply to 8,000 customers, its zone may need SL-T 3 for FR5 and FR6 even though SL-C is 1. I would document the SL vector, the gap, and the compensating controls. The consultant's design would let a compromise at one low-criticality station reach all stations and the plant historian, so it fails the conduit restricted-data-flow requirement.
2. The six legacy RTUs cannot meet the authentication and encryption requirements you would normally assign. Recommend compensating controls and state how you would treat the resulting SL gap in the CSMS.
Read the worked answer
The legacy RTUs cannot meet authentication or encryption, so do not pretend they meet SL-T. First, reduce exposure: put each RTU behind a station gateway/firewall, use private APN or VPN with certificates at the gateway, deny inbound internet, and allow only the SCADA master to poll the RTU. Where telemetry is one-way, use a one-way gateway or data diode so the RTU cannot be used as a pivot. Add compensating controls: physical locks, disable unused ports, change default credentials, restrict vendor access to a jump host with MFA and time limits, monitor flows and logs at the gateway, and back up configurations. Record SL-C below SL-T in the risk register, state the compensating controls and residual risk, and get a time-bound risk acceptance from the asset owner. The CSMS should track this as a gap with an owner and replacement date. This is consistent with 62443-3-3: the requirement is not waived, but the gap is managed and not hidden.
3. Sequence the first 10 weeks of work so that uptime is protected. Identify which changes are low-risk enough for normal windows and which need a shutdown.
Read the worked answer
Sequence by risk and reversibility. Weeks 1-2: build a passive asset inventory and flow map from span ports; no inline changes. Weeks 3-4: stand up a remote-access jump host in a DMZ, individual vendor accounts, MFA, session logging; move vendor access off the flat network. Weeks 5-6: install firewalls in monitor mode and validate rules against the flow map; fix the most dangerous any-any rules. Weeks 7-8: pilot segmentation at one pump station during a normal maintenance window with rollback; use redundant paths and bypass for the RTU. Weeks 9-10: roll out to remaining stations in batches, with change approval and operations on the bridge. Changes that touch RTU configuration, radio addressing, or SCADA polling need a planned outage or bypass; firewall ACL changes and monitoring are lower risk. Do not do a big-bang cutover. Keep a rollback plan and a communication tree for each window.