Testing the Waters — NIST’s First Water Sector Guidance

NIST’s National Cybersecurity Center of Excellence (NCCoE) has finalized NIST SP 1800-45, Cybersecurity for the Water and Wastewater Sector: Build Architecture. This is the first practice guide for secure remote access to OT in water and wastewater utilities — fifteen CSF-mapped considerations and three reference architectures. It's voluntary guidance and a starting point. Here's what it says, and where to go further. 

In June, the U.S. National Institute of Standards and Technology (NIST) released its first practical guidance for the water and wastewater sector in Special Publication 1800-45 “Cybersecurity for the Water and Wastewater Sector: Build Architecture (Operational Technology Remote Access)”. The initial of a four-part series, the government and its industry advisors wisely chose to prioritize secure remote access as the focus in this first installment.  

In this practitioner’s brief, we review the timely importance of this publication, what it says, and how to apply its recommendations to your utility. 

NIST SP 1800-45’s release could not have come at a better time. While cyberattacks against the U.S. water sector have long been portended—and periodic incidents have garnered attention even by the public—the cadence of state-sponsored attacks on the sector has worryingly increased. 

In November 2023 a group calling itself CyberAv3ngers, which America’s Cybersecurity and Infrastructure Security Agency (CISA) attributes to Iran’s Islamic Revolutionary Guard Corps, shut down a booster pump serving two townships outside Pittsburgh. The controller it seized at the Municipal Water Authority of Aliquippa was sitting on the open internet behind a factory-default password with no gateway in front of it. The same campaign reached at least 75 devices across America, Israel, Britain and Ireland, where one district lost running water for days.

The pattern has not gone away; it has scaled. Over a weekend this July more than 30 Minnesota community water systems were struck at once. Braham’s treatment plant went offline and the city asked residents to stop using water until it came back. Plymouth lost cellular communications to two water towers and several lift stations and ran them by hand. Maple Plain declared a local emergency. Within days the FBI and the Environmental Protection Agency were warning utilities in at least seven states, and CISA’s acting director urged operators to take publicly exposed controllers off the internet as fast as they could manage. Attribution remains unsettled, though the attacks began four days after CISA widened an advisory on Iranian-affiliated actors working through internet-facing controllers. 

None of these attacks required much skill. At Aliquippa, a default password and an exposed internet connection were enough. Water and wastewater utilities are, as a rule, chronically underfunded in the United States, and by political nature not generally unified into state or federal operations with all the shared resources that implies. Federal support has been inconsistent, and EPA enforcement around cybersecurity has receded rather than grown. Utilities are being asked to hold a line against nation-state actors on the staff and budget of a municipal department. Absent means or mandate, the current state of affairs is not a mystery. 

SP 1800-45 arrives into all of this and provides a sensible, scaled set of example architectures and practical security recommendations. Acknowledging that most water utilities are, in fact, quite small—more on this later—the publication opens by pointing out that a utility might reasonably decide the right amount of remote access is none. A drive out to the site is still a legitimate answer where the simplicity of the system outweighs the convenience of skipping the trip. For everyone else, NIST provides its recommendations. 

The Checklist 

The heart of the guide is a list of fifteen things water and wastewater utilities should implement around remote access to protect their infrastructure. We have grouped them below by the question each one answers. The numbering is ours rather than NIST’s; anyone checking against the published table should look items up by name. 

Who Gets In 

1. Authenticate all remote users and systems. Every session should trace to a named person. That means individual accounts rather than a shared “operator” or “vendor” login, tied to a central directory if the utility has one and to the access system’s own user store if it does not. 

2. Use multi-factor authentication. A PLC cannot do MFA, and neither can most HMIs, so do not try to put it on the devices. Installed agents do not work well in this situation. Enforce it once at the entry point, before the session reaches anything operational. An authenticator app is sufficient; a hardware token is better for vendors. 

3. Restrict remote access to authorized users or systems only. Start from default-deny and work back. Write down the roles that actually exist—operator, systems integrator, SCADA vendor, consulting engineer—and the permissions each role needs. 

4. Employ least privilege. Many plant networks are flat; once a connection lands inside, it can reach everything or pivot on connected nodes. Re-segmenting the network is a multi-year project few small utilities will finish, so enforce least privilege at the access point instead and then monitor for lateral movement. The user connects to a gateway, and the gateway opens a path to one device on one protocol, not a route onto the network. Done properly, a vendor servicing a chlorine analyzer can reach that analyzer and cannot see the SCADA server at all, even though the two share a subnet. 

How Far They Get

5. Terminate remote access at a protected network segment. The inbound session should stop at a gateway in a demilitarized zone, and a separate connection should carry on inward from there. In practice this means no port forwarding to a device, and no VPN that drops a user straight onto the plant network. Nothing operational should be reachable directly from outside. 

6. Restrict access based on operational requirements. Allow only the protocols needed and deny everything else. “Allow all TCP to the plant subnet” is unfortunately more common than might be expected. Overly permissive access control lists (ACLs) turns one compromised session into a much larger blast radius. 

7. Protect the confidentiality and integrity of communications. Encrypt anything crossing a network the utility does not own, which includes the internet, cellular links, and leased lines between sites. Process traffic between stations counts here as much as human sessions do. 

8. Provide endpoint security for the machines people connect from. Either check the connecting machine before letting it in—patch level, disk encryption, endpoint protection running—or side-step the problem by giving the vendor a controlled environment to work inside, so their own laptop never touches the plant. In reality, utilities aren’t going to do the former. Extending your security envelope out to a vendor’s devices is generally unfeasible, not cost-effective, and will meet with serious vendor resistance. Over ten years have taught us that disposable, containerized or virtualized environments that are hardened and monitored are the answer here. 

How Long They Stay 

9. Restrict access based on temporal requirements. Access should carry an expiry and revoke itself. The goal is that no vendor has a standing account that works at three in the morning on a Sunday because somebody enabled it in 2019. 

10. Coordinate scheduled maintenance and activity. Keep a shared calendar of planned remote work that whoever watches alarms can see. A session inside a window is expected; a session outside one is a question that needs answering that day. This requires a logging component (below) and a proper alerting system. 

What Is Known, and What Is Left Behind 

11. Maintain logs of remote user and system actions. Log at the gateway rather than the device, because most older operational equipment cannot log usefully and will overwrite what it does record. Capture who connected, when, from where, to what, and — if the system supports it — a recording of the session itself. 

12. Implement inventory management. List everything reachable from outside: cellular modems, vendor appliances, radio links, that laptop in the pump house with a static route. Asset discovery will find most, and scanning for wireless devices will help you detect unauthorized vendor-access 4G chips. 

13. Update remote access services regularly. The gateway becomes a critical node, so patch it on a schedule and know when it was last done. If a vendor operates it, put the patch cadence in the contract. 

14. Use change and configuration management. Record changes to firewall rules, accounts, and gateway configuration, and review them periodically. Access rules tend to grow over time and must be pruned regularly—typically once per quarter. 

And the Vendors 

15. Set security requirements for third-party remote access in advance. Put them in the contract before the first session: named individuals rather than a shared account, multi-factor authentication, access limited to a window, session recording, notice when their staff change, and the utility’s unconditional right to revoke. Our template requirements you can modify and use yourselves may be found at: https://legal.dispel.com/supplier-policies/trust-and-accountability/vendor-data-protection-addendum 

Fifteen Items, 49,680 Utilities

None of the fifteen is exotic, and any competent engineer could implement any of them. That is not the difficulty. The difficulty is who, precisely, is meant to do it. 

The United States has 49,680 community water systems. Of these, 13,321 serve between 501 and 3,300 people, and more than half—26,897—supply somewhere between 25 and 500 people apiece. At the other end of the scale, under 1% of utilities cover nearly half the U.S. population.  

One might suppose the prime targets are therefore the 1% of utilities, and an attack on a smaller utility would have a smaller blast radius of affected people—but this assumption is a mistake. Large utilities do have more resources given their scale and can better defend themselves. Smaller utilities, with no full-time cybersecurity staff, outsource to vendors who service large numbers of smaller regional utilities. An attack on one vendor can affect a wide territory. 

Thus, regardless of utility size all of them are targets; scattered across a country that is geographically vast and administratively fragmented, and in which the resources of most local communities are quite small. 

That is the problem NIST had to solve. 

Who Runs It 

Having said what to enforce, the guide turns to where those controls live, and sketches three arrangements. What separates the first two is not technology. It is ownership. 

In the first, simplest model, everything belongs to the utility: firewalls, a demilitarized zone, and a remote access server standing between the outside world and the process network. Acting as a zone boundary controller, the inbound session stops at that server and a second connection carries on inward. The server decides who may touch what, brokers the connection, and logs actions. Every part of it is the utility’s to buy, patch, and keep patching. 

In the second model, we turn to third-party providers for economy of scale. Identity and policy run at a cloud-based provider while the gateway inside the perimeter carries out the verdict. There is far less to own. In exchange, part of the plant’s security now lives in a contract, which is why NIST specifies what that contract must cover: end-to-end encryption, access control, intrusion detection, vulnerability management. A utility that cannot get those terms in writing has not transferred the risk. 

Set that choice against the arithmetic and it stops being a choice. Twenty-seven thousand systems serving fewer than five hundred people each are not going to staff a hardened access server, and no volume of guidance will make them. NIST admits this in the publication: lower-capacity utilities may prefer infrastructure managed by a third-party.

The third model NIST covers data streaming—a component of remote access often overlooked because it does not inherently involve humans. A pump station reports to a treatment plant, one controller signals another across a leased line, and no person is involved at any point. Every multi-site utility has this traffic whether or not it has thought about it. This data streaming must also be taken into consideration for hardening the same as the human access program. 

Where to Begin 

NIST’s guide is practical, high-impact, and straight forward. We endorse and recommend its guidance to water and wastewater utilities. The control families selected in the publication are sensible and minimalist. Once implemented, they form a foundation of best practices for bringing other control families into compliance and enforcement. 

Because NIST used well-established controls, there are, of course several built-to-purpose solutions on the market that will fill all of the guide’s requirements. Dispel is one such solution. But however utilities achieve implementing NIST 1800-45’s controls, we and our communities will all be the better for it. 

Dispel Community Power & Water Program 

We live and work in the communities served by your utilities and we want to help.  

The Dispel Community Power & Water Program gives approved utilities exceptional discounts on a Dispel Zero Trust Engine configuration that ringfences critical equipment, deployed by your own staff in under a day with little to no change to your existing network. 

Learn more and apply for pricing built for the smallest security budgets. Apply today.