Smart Water Meters: Unlocked Bootloader and Shared Vendor VPN
A municipal water utility has installed 25,000 smart water meters using NB-IoT. Each meter reports hourly consumption and valve status to a head-end system. The meters are firmware-signed, but a field audit found that one production batch of 300 units left the bootloader unlocked and has a debug port accessible once the physical seal is removed. Field technicians use handheld readers with a shared maintenance login. The meter vendor also has a remote VPN into the head-end for support, using a shared account and no time restriction. The utility's OT network is flat: head-end, billing, and corporate IT share one VLAN. A security consultant warns that a meter with an unlocked bootloader could be reflashed to report false consumption or open valves remotely, and that the vendor VPN is an uncontrolled path.
1. Map the most significant risk sources in this scenario and rank them. Justify your ranking.
Read the worked answer
Reasoning. Rank by likelihood times impact. The vendor VPN plus a flat OT/IT network is the highest risk: a shared, always-on remote account creates a path from the internet to the head-end and potentially to valve commands, affecting safety and availability. The 300 unlocked meters are next: physical access and seal removal are required, but reflashing could falsify billing or actuate valves. Shared field-technician logins are third because they weaken accountability and incident attribution. The flat VLAN amplifies every other source.
Risk sources: supply chain (bootloader), network (VPN, flat VLAN), human (shared accounts), physical (debug port and seal), software (firmware).
Conclusion. Treat remote access and segmentation as urgent; treat the 300 meters as a contained but high-consequence supply-chain issue.
2. Specify controls for the unlocked-bootloader batch and the vendor remote access. Distinguish immediate, short-term and structural controls.
Read the worked answer
Immediate: locate and quarantine the 300 units; verify seals; disable the debug interface where possible; restrict field access; monitor for reflash or anomalous valve commands; suspend the vendor VPN. Short-term: named vendor accounts with MFA, time-bound jump-host sessions and logging; per-technician credentials; segment head-end from billing and corporate; deny inbound internet. Structural: require locked bootloaders, secure boot and signed firmware in procurement; device identity; SBOM and vulnerability disclosure; contract audits. If the batch cannot be locked, replace it or accept risk with isolation and monitoring.
Conclusion. Controls must address both the device batch and the remote path; neither alone is sufficient.
3. The utility wants to keep the flat network because segmentation 'costs too much.' How would you argue the case in ISO 27400 terms, and what minimum segmentation would you propose?
Read the worked answer
Reasoning. A flat network violates least privilege and defence in depth and turns a head-end compromise into an OT safety event. Network exposure is a risk source, and layered controls are expected.
Minimum segmentation: separate VLANs and firewalls for head-end, billing and corporate; a DMZ jump host for vendor access; allow-list only required protocols and destinations; no direct internet from meters or head-end; logging to a SIEM. Phased use of existing firewall capabilities reduces cost. Compare the cost with the impact of false billing or valve actuation.
Conclusion. Argue from blast radius and safety, not from a generic 'best practice', and propose a minimum viable segmentation rather than a full redesign.