~/f4n6 $ grep -r "Your security program knows about the firewall, but does it know about the elevator?" ./investigations/ --include="*.md"

Your security program knows about the firewall, but does it know about the elevator?

Jeff Davies 24 Sep 2026 6 min read

1. Executive summary

Attackers remotely accessed internet-facing programmable logic controllers at water systems in at least seven US states by early August 2026, causing operators to lose monitoring or control and degrading water operations in some cases, according to the FBI and EPA. Federal investigators are examining possible links to Iran-backed hackers; the verified reference data holds no MITRE ATT&CK profile for that actor, so the attribution is unconfirmed and should not be used for blocking or escalation decisions. No CVE, CVSS score or CISA KEV entry is associated with this item in the verified reference data, so the exposure here is configuration and visibility driven, not patch driven. A Honeywell survey of 603 critical-infrastructure security, risk and operations leaders, run in May and June 2026, found that only 16% continuously monitor more than three quarters of their building automation systems, only 20% do so for connected IoT devices, and only 21% hold a complete asset inventory. For EMEA financial services the read-across is the same device class: chillers, fire panels, badge readers, elevators and cameras that sit one layer above the OT estate, are often outside both the inventory and the monitoring scope, and in the case of a chiller can take down the servers it was cooling.

2. Regulatory framing

Article Trigger (the fact in this item) Practical impact
DORA Art. 28: ICT third-party risk, general principles The source states that patching legacy controllers "can mean planned downtime or a call to the vendor", so maintenance of in-scope building and OT systems depends on third-party providers Clients must be able to name those providers, confirm that support, patch and response obligations are contracted, and assess concentration where one vendor covers many sites

No incident-reporting article is engaged. The intrusions described occurred at US water utilities, not at client organisations, and this item reports no incident at a client. DORA Art. 17, 18 and 19 and NIS2 Art. 23 are therefore not triggered by anything in the source material.

3. Technical analysis and attack chain

Confirmed steps, as stated by the FBI and EPA and reported by Help Net Security:

  1. Intruders identified programmable logic controllers that were reachable from the internet. PLCs are the small industrial computers that run pumps and valves.
  2. They accessed those controllers remotely, over that internet-facing path.
  3. Operators lost monitoring or control of the affected process, and in some cases water operations degraded.

That is the full extent of the confirmed chain. The source does not describe the access protocol, the authentication state of the exposed controllers, any credential use, any payload, any persistence mechanism, any command-and-control infrastructure, or any lateral movement. Nothing in the source indicates data theft or extortion, and nothing supports describing this as ransomware.

The defender-relevant content in this item is the visibility gap around the layer above the PLCs. Honeywell surveyed 603 security, risk and operations leaders in critical infrastructure in May and June 2026. Sixteen percent continuously monitor more than three quarters of their building automation systems, the software running heating, cooling and lighting across a facility; for connected IoT devices such as cameras and thermostats the figure is 20%. Continuous monitoring here means something watches a device's traffic and behaviour all the time, not only during an audit. Eighty-eight percent of respondents describe their programmes as planned or design-led, and 21% report a complete asset inventory, meaning a full list of what is connected to their networks. A programme can have a plan, a budget and a working relationship with IT and still miss the chiller controller that keeps an on-site data centre cool.

The recovery numbers are worth reading with their caveats attached. Respondents' most significant incidents averaged 16.2 hours of downtime. Among those with a full or substantial inventory, 42% were back up within six hours; among those with a moderate, limited or no formal inventory, 25% were. The weaker group is 91 respondents against roughly 350 in the stronger one, and the survey shows an association, not proof that an inventory shortens an outage. Organisations with good inventories may simply do many other things well. The operational logic still holds: a responder who does not know a device exists cannot isolate it, and one who does not know what depends on it cannot predict what shutting it off will break.

Audit status did not separate the populations. Organisations that passed every compliance audit reported significant incidents at nearly the same rate as those with failures or findings, 74% against 73%. The report is explicit that this does not show compliance has no preventive value, only that audit status did not distinguish who reported an incident. Clean-audit organisations were more confident they could recover, and the survey attributes that to tested backups, documented response procedures and clear ownership, which count as audit evidence and also help a team restore systems under pressure. Thirty-one percent of respondents call themselves fully ready; most of the rest say they are mostly ready, meaning some part of the plan has not been put in place or tested. Old equipment is the most-cited barrier. Many legacy controllers were built to run in isolation and use protocols with no authentication or encryption, and patching them can mean planned downtime or a call to the vendor.

Attribution caveat. The possible link to Iran-backed hackers is under examination by federal investigators and is single-sourced to that reporting. The verified reference data contains no MITRE ATT&CK profile for the actor named, so treat the attribution as unconfirmed. Do not build detection, blocking or escalation logic on it.

4. Mitigation and containment

The source names no vendor fix, no patch and no affected product version, so the actions below are exposure and visibility controls rather than remediation of a specific flaw.

P1, within 24 hours

  • Enumerate every PLC, RTU, building automation controller and building IoT device that is reachable from the internet. Anything answering on a public address without an authenticated broker should be taken off direct exposure or placed behind a VPN or jump host that enforces MFA. The water intrusions in this item came through internet-facing PLCs.
  • Reconcile that list against the asset inventory. The survey found only 21% of organisations hold a complete inventory, so expect gaps.
  • Confirm whether the building layer (chillers, fire panels, badge readers, elevators, cameras) is inside the scope of continuous monitoring. If it is not, say so in writing to the risk owner rather than leaving it implicit.

P2, within 72 hours

  • Map dependencies before you isolate anything: which servers, trading desks or branch functions lose cooling, power or physical access if a given chiller, fire panel or badge reader is taken offline.
  • Establish the vendor contact and support path for each legacy controller. Where patching requires a vendor call, record the contractual response time and the named contact.
  • Segment building automation and building IoT onto their own VLANs, deny inbound traffic from corporate networks and the internet by default, and permit only the flows the system needs.

P3, within 7 days

  • Test recovery for the building layer, not just for IT systems. Tested backups, documented procedures and clear ownership are the three items the survey links to faster restoration.
  • Extend continuous monitoring coverage to the devices identified in P1, starting with anything whose failure has a direct dependency on a revenue or client-facing system.
  • Plan replacement or compensating controls for controllers that only speak protocols with no authentication or encryption, and budget the planned downtime that patching them requires.

5. Indicators of compromise

No indicators of compromise available in the source material. The source contains no hashes, domains, IP addresses, file paths, registry keys or command lines.

The source does describe observable behaviours, so the following are offered as behavioural indicators rather than atomic ones. None of these are machine-pivotable and none belong in a blocklist.

Behavioural indicators

Behaviour Where to observe Confidence
Inbound session to an internet-facing PLC or building controller from an external address Perimeter firewall logs, OT network flow data, PLC and HMI management interface logs Medium. The source states remote access occurred; it gives no telemetry specifics
Loss of monitoring or control at a controller with no corresponding maintenance window SCADA/HMI alarms, operator shift logs Medium. Stated by the FBI and EPA as the observed effect
A building automation or IoT device generating network traffic while absent from the asset inventory Passive network discovery, DHCP and DNS logs, switch MAC tables Low. Derived from the survey's inventory findings, not from observed activity

6. Detection

Insufficient indicators to author detection rules.

7. Sources

  • Help Net Security, "Your security program knows about the firewall, but does it know about the elevator?", 2026-09-24, https://www.helpnetsecurity.com/2026/09/24/ot-asset-visibility-challenges/
  • Honeywell Technologies survey of 603 security, risk and operations leaders in critical infrastructure, conducted May and June 2026, as cited within the Help Net Security article above. No direct URL for the survey was provided in the source material.

8. Adverse Trace position

We do not assign a severity to this item. The verified reference data carries no CVE, no CVSS score and no CISA KEV entry, and the source gives no affected product or version, so any severity number would be invented. The risk is real but it is exposure and visibility risk: internet-facing controllers with no authentication, and a building layer that most organisations neither inventory nor monitor. The attribution to Iran-backed hackers is unconfirmed and single-sourced, and we will not treat it as established until a MITRE ATT&CK profile or a government statement names the actor. For EMEA financial services clients we assess the direct impact as low today and the latent impact as material, because the same unmonitored device class sits in branch, data centre and office estates across the region, and a chiller failure is an availability incident with a DORA Art. 28 third-party dimension attached. We will monitor FBI, EPA and CISA statements on the water system intrusions and re-issue this advisory if a CVE, a KEV entry or a named actor appears. Clients who want help enumerating internet-facing OT and building devices should contact their Adverse Trace account lead.


Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.

Post this to LinkedIn
Formatting is converted automatically — headings, bullets, a link back & hashtags. Paste straight in.
J
Jeff Davies