Split View: 자산 목록에 없는 것은 스캔되지 않는다 — 상수도 PLC 사건이 알려 주는 OT 노출 관리

What Is Not in the Asset Inventory Never Gets Scanned — OT Exposure Management, From the Water Utility PLC Case

• Introduction — the road to a notice telling people to boil their water
• What the alert observed and what it did not
• Reading attribution claims separately from technical recommendations
• The cellular modem that is not in the asset inventory
• Why the mitigations are in that order
• The recovery precondition nobody prepares
• The ability to run manually is a security control, not a drill
• Where IT security habits fail in OT
• References

Introduction — the road to a notice telling people to boil their water

On 30 July 2026, CISA in the United States issued an alert for the water and wastewater sector. The first sentence runs like this: threat actors targeting PLCs in the water and wastewater sector are currently being observed in sharply increasing numbers, and publicly exposed PLCs and other operational technology should be removed from the internet as quickly as possible.

What makes this alert different from other security news is that the outcome is not data but water. The original writes that this activity led to boil water notices and prolonged manual operation.

This post is written from reading the CISA alert and the CISA fact sheet it references directly. It is not a news summary; it follows the order and the reasoning written into the advisory and tries to explain why that order is what it is.

What the alert observed and what it did not

First, let me carry over the facts exactly. The alert observed two threat behaviors.

Actors targeting exposed PLCs changed passwords to lock out operators, and changed IP addresses to cut PLCs off.

These two sentences matter because there is no exploit in them. No zero-day, no memory corruption, no sophisticated payload. Accessing the management interface of a device exposed to the internet and changing settings was the whole of it.

The alert lists the risks to exposed OT assets like this: defacement, configuration change, operational disruption, and in severe cases physical damage.

And on the scope of targeting it writes this: threat actors are going after water utilities of every size without discrimination, and even organizations with mature cybersecurity processes need to validate their own external connections.

Reading attribution claims separately from technical recommendations

Press coverage followed this matter. On 7 August 2026 The Register ran an article under a headline to the effect that a former NSA director said water system controllers should not be on the internet, and the headline mentions suspected Iranian involvement.

Two things need to be made clear here.

First, I was not able to read the body of that article myself. Access was blocked, and it was not preserved in archives either. So this post does not restate that article's specific claims.

Second, and more importantly, the CISA alert itself does not name any country or organization. Only the observed behaviors and the recommendations are written down.

This distinction has practical meaning. Attribution is the domain of intelligence and law enforcement agencies, public statements come out in the form of conference talks or interviews, and confidence levels differ from document to document. Whereas the actions you have to take are identical regardless of attribution. There is no benefit whatsoever in leaving an exposed PLC in place while waiting for who did it to be settled.

When you read reports, I recommend the habit of keeping three separate columns: what this document observed, what this document inferred, and what somebody else asserted. In the security field these three get mixed together frequently as they circulate.

The cellular modem that is not in the asset inventory

The most practically useful sentence in the alert is this one.

This targeting activity includes cellular modems installed by operators, vendors, or system integrators, which may be undocumented or may not be included in routine attack surface scans.

That single sentence compresses the structural problem of OT security.

An attack surface scan generally starts from the asset inventory. It sweeps the IP ranges you know, the domains you know, the circuits you know. But a cellular modem receives a carrier IP. It is not in your company's IP range. It does not pass through your firewall. It is not on the network diagram either.

On top of that, this modem was generally not installed by you. An engineer from the pump manufacturer attached it for remote diagnostics, or an integrator put it on for convenience during commissioning and never removed it, or a site technician fitted it themselves to reduce night callouts. All three are good intentions, and in all three the IT department does not know.

The way to find them is investigation, not scanning.

• Demand in writing, from every vendor with a remote support contract, a list of the communications equipment they installed on site.
• Check the carrier invoices. Line charges do not disappear, so they are the surest trace of a forgotten modem.
• Physically inspect each site. An antenna inside a cabinet may not be on the diagram, but it is visible to the eye.
• Search on engines such as Shodan or Censys using the organization name, city name, and known device banners. CISA guides the same approach on its Stuff Off Search page.

This work needs authority more than it needs tools. You have to be in a position to ask vendors, a position to visit sites, and a position to see the invoices.

Why the mitigations are in that order

The alert has four recommendations, and the order has meaning.

1. Disconnect PLCs from the internet. Remote access for operational purposes must go through a VPN or a gateway device rather than directly to the PLC.

2. Enable password protection and change default passwords.

3. Apply IP allowlisting. Restrict remote access so that it works only from known engineering laptops or other core OT assets.

4. After disconnecting the PLC from the internet, secure a PLC image backup verified to be clean, in preparation for being locked out by a changed password.

That 1 comes before 2 is the key. We usually do the opposite. Harden passwords first, add multi-factor authentication, and then tidy up the network. For IT assets that is reasonable.

In OT it is not. The reason is written in CISA's OT mitigation fact sheet (dated 6 May 2025, jointly from CISA, the FBI, the EPA, and the DOE). OT devices lack authentication and authorization methods capable of withstanding modern threats at all, and are quickly discovered simply by scanning public IP ranges for open ports. The same document writes that threat actors use "simple, repeatable, and scalable tooling available to anyone with a browser."

That is to say, hardening the password does not fundamentally change the nature of the risk as long as that interface is on the internet. Conversely, pull it off the internet and the difficulty of all three remaining items goes down. Removing exposure is the precondition that makes the other controls effective.

The recovery precondition nobody prepares

The fourth recommendation is worth reading again.

"After disconnecting the PLC from the internet, secure a PLC image backup verified to be clean, in case you are locked out by a changed password."

Why that sentence is needed becomes clear when you read it paired with the observed attack behavior. What the attacker did was change the password and lock the operators out. Which means what you have to get back is not data but access to the equipment.

The alert even attaches a specific reference for this. Owners, operators, and integrators of the Rockwell Automation MicroLogix 1400 PLC are told to consult a Rockwell notice on how to recover controller access when the password is unknown. The mere fact that a specific model name appears in an advisory shows that this scenario is not hypothetical but actually occurring.

In practical terms, here is what has to be prepared.

• The current program and configuration of each PLC as a downloaded file, plus a record of when and in what state it was taken
• A history of verifying that the file can actually be restored (a backup that has only ever been taken and never restored is not a backup)
• The password recovery procedure for each vendor, and whether that procedure requires a factory reset
• If a factory reset is required, how long it takes to load the program back in afterwards, and the operating plan for that period

The last item is where this differs most from IT backups. A server can have its service stopped while it is being restored. A water treatment plant has to keep sending water even while it is being restored.

The ability to run manually is a security control, not a drill

Which brings us to the fifth mitigation in the CISA fact sheet. Train and maintain the ability to operate OT systems manually.

In the wording of the original, the ability to revert to manual control is essential for restoring operations quickly after an incident, and business continuity plans, disaster recovery plans, failsafe devices, islanding capability, software backups, and spare systems should be tested regularly so that safe manual operation is possible during an incident.

If putting this item on a list of security controls feels unfamiliar, look again at what the alert observed. The actual impact of this event was boil water notices and prolonged manual operation. Water supply did not stop precisely because manual operation was possible.

When we talk about security investment we generally spend the budget on prevention. Yet in OT what actually determines the damage is not the completeness of prevention but how long you can hold out once you have lost automatic control. And that capability is not secured on paper. It is secured by people having done it with their hands.

Where IT security habits fail in OT

Finally, let me set out what can be generalized from this event.

First, patch-first thinking does not work. There was no exploit in the observed attack. However well you run a vulnerability management program, the problem "default password on an exposed management interface" does not have a CVE number.

Second, the asset inventory is the ceiling on control. As the cellular modem case shows, no control applies to an asset you do not know about. And asset inventories in OT environments are wrong far more often than in IT, because there are multiple installing parties, lifetimes run to decades, and documentation practices differ.

Third, the supply chain is the access path. The CISA fact sheet states that misconfiguration can be introduced during standard operations, by system integrators, by managed service providers, or as a manufacturer's default product setting, and recommends communicating with these parties regularly. A remote support contract is not a convenience feature; it is an extension of the trust boundary.

Fourth, recovery objectives have to be defined by physical outcome rather than by service level. Not 99.9 percent system availability but "can we lift the boil water notice within a few days?" Without that translation, the conversation with executives does not happen.

There really are things that must not be attached to the internet. And that judgment should start not from an argument about convenience but from what happens when that piece of equipment misbehaves.

References

• CISA Urges Water and Wastewater Systems Sector to Protect OT Against Activity Targeting PLCs — CISA Alert, 2026-07-30
• Primary Mitigations to Reduce Cyber Threats to Operational Technology — CISA/FBI/EPA/DOE fact sheet, 2025-05-06
• Stuff Off Search — CISA
• Secure Connectivity Principles for Operational Technology — UK NCSC
• Hacker News discussion thread

Every quotation in this post is carried over from the two CISA documents above. The attribution claims that appeared in press coverage were not restated, because I could not confirm the original.