CTI for Small Water Systems: A Program Two People Can Run

Most of the water sector is not made of large metropolitan utilities with a security operations center and a threat intelligence team. It is made of small and very small systems: a few thousand connections, a couple of operators, one IT contractor who also handles billing, and a SCADA vendor who shows up twice a year. Those systems still treat drinking water, still run chemical dosing, and still sit on the internet in ways nobody documented.

This post is about doing real cyber threat intelligence work at that scale. Not a program with analysts and feeds, but a small, honest process that a two person shop can actually keep running.

Start with consequence, not with threats

Large programs start by asking who is targeting us. Small systems should start by asking what would hurt. The list is usually short and it is physical:

• Loss of chemical dosing control, including overfeed or underfeed of chlorine
• Loss of pressure or a distribution event that triggers a boil water notice
• Loss of visibility, where the HMI lies or goes blank and operators drive to sites
• Loss of billing and customer data, which is disruptive and reportable but not a public health event
• Extended manual operation that exhausts a staff of three

Rank those. Everything else in your intelligence process hangs off that ranking. If a piece of information cannot change how you prepare for one of those outcomes, it is news, not intelligence.

Write three requirements, not thirty

A small utility does not need a full priority intelligence requirement catalog. It needs three questions it can answer every month:

1. Is anything of ours reachable from the internet that should not be? HMIs, cellular routers, VPN appliances, vendor gateways, historian web portals.
2. Has a vendor we depend on published an advisory or been breached? Your SCADA integrator, your PLC maker, your remote access tool, your managed IT provider.
3. Is there active targeting of water systems that matches our exposure? Not water news in general, but activity that maps to the protocols, devices, and access paths we actually run.

Three questions is a program. Thirty questions is a wish list that nobody services.

Collection you can afford

Collection at this scale is mostly free and mostly scheduled. The trick is putting it on a calendar instead of relying on someone remembering.

• Sector alerts from your national and state channels, plus your water sector information sharing group. Read them for device and protocol names, not for adjectives.
• Vendor security pages and mailing lists for every product in the control room. Write down the list once. It rarely changes.
• Internet exposure checks on your public address ranges, done monthly. If a service appears that you did not expect, that is a finding.
• Your own firewall and remote access logs, reviewed for new source countries, new accounts, and off hours sessions.
• Your integrator. Ask them directly what they are seeing at other clients. This is the most underused source in the sector.

That is it. Five sources, one hour a month, and you are ahead of most peers.

Turn findings into two artifacts

Small teams drown in documents. Keep two.

The first is a one page exposure sheet. Every internet reachable asset, who owns it, why it exists, and when it was last verified. If an asset cannot justify its line on that page, it should be removed or moved behind a gateway.

The second is a running log of decisions. Date, what you learned, what you changed. A vendor advisory came out, you disabled a service, you scheduled a firmware update for the fall shutdown. Six months of that log is the evidence a regulator, an insurer, or a board member will ask for, and it is far more convincing than a policy binder.

Detection at this scale means noticing change

You are not going to build protocol aware detections with a staff of two. What you can do is baseline and notice change.

• Which engineering workstations normally talk to which PLCs, and at what times
• Which remote access accounts are used, and by whom
• What the normal dosing setpoint range looks like across a week
• Which cellular modems phone home, and where

Then arrange for something to tell you when that changes. A weekly export, a simple alert from the firewall, a vendor dashboard. Change detection catches the intrusions that matter in OT far more reliably than indicator matching does.

Practice the manual fallback

The most valuable resilience investment a small system can make has nothing to do with software. It is a written, rehearsed manual operations procedure. Who drives to which site, which valves are turned by hand, how dosing is verified with bench tests, how long the crew can sustain it, and who relieves them.

Intelligence supports that plan by telling you how long an outage might last and what an adversary is likely to touch first. A group that stages through remote access and disables visibility implies a different rehearsal than a commodity ransomware crew that encrypts the business network and leaves control alone.

Where honeypots fit

Decoy sensors are not just for large operators. A single protocol decoy placed on a network segment that should never see Modbus or DNP3 traffic is one of the cheapest high confidence alarms available. Nothing legitimate talks to it. Any hit is a real event, not a tuning exercise. For a utility with no dedicated monitoring, that is a meaningful improvement in signal for very little operational burden.

The realistic goal

You are not trying to build a threat intelligence team. You are trying to make sure that when something relevant happens in the sector, someone at your utility hears about it, understands whether it touches your equipment, and can point to what changed as a result.

Three requirements. Five sources. Two artifacts. One rehearsed fallback. That is a defensible water sector intelligence practice at a scale that fits the plants that most Americans actually drink from.