Water system controllers don't belong on the internet, says ex-NSA chief

An exchange over an ex-NSA chief’s warning about internet-connected water system controllers highlights how fragile much critical infrastructure security remains. Commenters describe decades-old PLCs, flat networks, weak physical and RF security, and ad‑hoc practices that make utilities easy targets for nation-states and criminals, while also noting the operational pressures that drove systems online in the first place. Proposals range from strict air‑gapping and data diodes to hardened VPNs and formal engineering standards, with broad agreement that “naively” exposing control systems to the public internet is indefensible.

Scope of the Debate: Should Water Controllers Be Online?

  • Strong camp saying critical infrastructure (water, power) should never touch the public internet; true air‑gaps and no routable paths to controllers.
  • Others argue full isolation is unrealistic: distributed sites, staffing limits, and remote monitoring needs make connectivity economically necessary.
  • Middle-ground proposals: strictly no direct exposure, only access via hardened VPNs, firewalled jump hosts, or read‑only mechanisms (data diodes, webcams showing gauges).

Security vs. Practicality and Cost

  • Recurrent theme: “if it’s connected, assume it’s compromised,” especially against nation‑state adversaries; even updates can be attack vectors.
  • Counterpoint: strong network security and modernized gear materially improve safety versus today’s “ancient PLC on the internet” reality.
  • Dedicated private links are expensive and brittle; tunneling over shared infrastructure increases resilience but enlarges attack surface.

Systemic Weaknesses in PLC/SCADA Ecosystem

  • Industrial control environments described as decades behind mainstream IT:
    • Outdated OSes (even Windows 3.1/2008), flat networks, weak backup/DR, no version control.
    • Ladder logic and proprietary binary formats make diffing, branching, and automated testing difficult.
    • Deployment culture: laptop folders full of customer projects, risky copy/paste between clients, ad‑hoc tools from random sites.
  • Vendors criticized for expensive, closed, insecure stacks and late adoption of secure protocols and virtualization.
  • Pay, working conditions, and culture discourage skilled software engineers from staying, perpetuating low maturity.

Physical and Wireless Attack Surfaces

  • Many water and gas facilities rely on insecure RF links and minimally protected field sites (towers, lift stations, compressor stations).
  • Physical access often easy; RTUs/PLCs are implicitly trusted by central SCADA.
  • Some argue physical‑presence requirements still reduce foreign remote risk; others note cheap drones, local proxies, or mailed devices erode that barrier.

Governance, Standards, and Government Role

  • Lack of binding security standards or “network inspectors” contrasted with strict building codes.
  • Suggestions that openly exposed critical equipment should be criminalized.
  • Debate over NSA/DHS/CISA responsibility:
    • Some blame them for prioritizing exploits and backdoors over defense and foresee a “9/11‑scale” cyber incident.
    • Others stress they mainly provide guidance; ultimate responsibility lies with local operators and political willingness to fund security.