#14.14 OT and ICS Incident

Playbook ID: PB-OT | Default severity: SEV-1 (the only downgrade path is a written engineering finding that no control system, safety function or process-network asset is in scope — downgrade to SEV-2, never lower, and record who signed it) | Owner: Incident Commander, paired with a named Engineering Authority who co-signs every OT action

#When to run this

• Any confirmed or suspected adversary activity on a host with a path into the process network: an OT jump host, a system in the OT DMZ, a vendor remote-access concentrator, a cellular or serial gateway, or a historian that spans both sides.
• Engineering workstation anomalies — an unexpected program download to a controller, a project file whose hash no longer matches the offline master, configuration or alarm data being read or copied by something that is not the engineering tool. VOLTZITE was elevated to Stage 2 of the ICS Cyber Kill Chain specifically for manipulating engineering workstation software to extract configuration files and alarm data (Dragos 2026 OT/ICS Year in Review).
• Operators reporting that the process is not behaving as the HMI says it is — readings that disagree with local gauges, alarms that stopped arriving, a valve or drive that will not respond to a command.
• Ransomware or intrusion confirmed in IT at an organization that operates a physical process, even with no OT indicator yet. This is not paranoia; it is the Colonial Pipeline case, where the operational shutdown decision had to be made before anyone knew what OT had touched.
• A KEV listing or vendor advisory naming a control-system product, an HMI, an engineering suite, or a remote-access appliance you run.
• Detection on remote-access or edge infrastructure serving an operational site — SYLVANITE operates at scale as an initial access provider for VOLTZITE by exploiting exactly this class of asset (Dragos).

Not for: IT-only ransomware at an organization with no physical process — use 14.1. An exploited perimeter appliance with no route to an operational site — use 14.12. A compromised badge or camera system is in scope here only if its failure has a physical consequence; otherwise treat it as ordinary IT.

#What you are dealing with

Two adversary populations share this space and they want opposite things. The first is criminal and indiscriminate: 119 ransomware groups impacted 3,300 industrial organizations in 2025, up 49% from 80 groups the year before (Dragos). Those actors are usually not in your OT at all. They encrypt IT, and you shut the process down yourself because you cannot run it blind. The second population is patient and state-directed and is not trying to make money. CISA, NSA, FBI and Five Eyes partners documented Volt Typhoon pre-positioning on the IT networks of communications, energy, transportation and water utilities to enable disruption of OT functions, using living-off-the-land techniques with minimal malware and dwell times of at least five years in some victims (CISA AA24-038A).

Five years. Not a typo. That is a tenant, not an intruder.

What changed in 2026 is intent moving from access to understanding. Dragos named three new groups — AZURITE, PYROXENE, SYLVANITE — alongside continued ELECTRUM, KAMACITE, VOLTZITE and BAUXITE activity, and reported that KAMACITE systematically mapped control loops across US infrastructure through 2025 while ELECTRUM targeted distributed energy systems in Poland with deliberate attempts to affect operational assets. VOLTZITE compromised Sierra Wireless AirLink gateways to reach US midstream pipeline operations before pivoting to engineering workstations. AZURITE targets engineering workstations for operational data and long-term access (Dragos). Stolen control-loop documentation is not data theft. It is the design phase of an attack that has not run yet.

And here is the mistake teams make, every time, and it is a good-faith mistake made by competent people: an IT responder sees adversary traffic crossing into a process network and does what they have been trained to do for fifteen years — isolates the segment. In IT, a wrong containment call costs you an afternoon. In OT, you have just slammed a moving vehicle into park because you found malware in the infotainment system. Control loops lose their supervisory layer mid-sequence, operators lose view of a process that is still running, and a plant that was safe becomes a plant nobody can see. Actionable takeaway: the entry condition for every OT containment action in this playbook is a named Engineering Authority on the bridge who agrees the action is safe in the current process state. Not consulted afterwards. On the bridge, before.

#Roles for this incident

Markings used below: `EVIDENCE destroys or degrades evidence — capture first. TIP-OFF is visible to the adversary. (S) **requires the Engineering Authority's sign-off and may not be executed by an IT responder alone.** Where a step carries (S)`, an IT responder executing it unilaterally is a reportable safety event regardless of outcome.

#Phase 1 — Detection and Triage

# Passive capture at the IT/OT boundary. Run on a host attached to a SPAN/mirror
# port or a passive tap - never inline, and never on a control-system host.
# -i: the mirror interface. -s 0: full packets. -w/-C/-W: rotating 200MB files.
sudo tcpdump -i <mirror_iface> -s 0 -w /evidence/ot-boundary.pcap -C 200 -W 200

# Chain of custody: hash closed files only. Stop the capture and confirm no file
# is still being written before you run this - the file tcpdump had open will not
# hash the same way twice, and a hash that fails verification is worse than none.
# Record the output with the operator's name and the UTC time it was taken.
sha256sum /evidence/ot-boundary.pcap* > /evidence/ot-boundary.sha256

# Engineering workstation project-file baseline. Read-only.
# Compare this manifest against the offline master hash list, not against a
# network copy - a network copy is inside the blast radius you are investigating.
Get-ChildItem -Path '<project_root>' -Recurse -File |
  Get-FileHash -Algorithm SHA256 |
  Export-Csv -Path 'C:\evidence\ews-project-hashes.csv' -NoTypeInformation

#Phase 2 — Containment

The sequence here is the reverse of your instincts. Establish a safe, known process state first; contain IT at full speed; break the boundary next; work inward last. Starting at the process end — pulling a switch, blocking a protocol, isolating a segment — removes the supervisory layer from a process that is still physically running, and the people who then have to manage that process are the ones standing next to it.

#Phase 3 — Eradication

#Phase 4 — Recovery

#Phase 5 — Post-Incident

#Decision points

#Communications and notification triggers

Two clock families run in parallel here and they answer to different regulators. The cyber clock: if you are a TSA-designated pipeline or rail owner-operator, the Security Directives require reporting cybersecurity incidents to CISA within 24 hours of identification — a clock that is live today and shorter than CIRCIA's 72 hours will be when that rule is final (TSA ratification notice, 17 Jan 2025; CISA CIRCIA). Australian critical-infrastructure operators are commonly cited as facing a 12-hour SOCI Part 2B critical-incident clock; that figure was not confirmed against a primary Home Affairs or cyber.gov.au source for this book — verify it before encoding (see the verification note in Chapter 15). Every deadline, recipient and template is in Chapter 15; do not reconstruct them here and never quote one from memory.

The second family is the one IT teams forget entirely. A physical process incident may trigger safety and environmental reporting obligations that have nothing to do with cyber law, that are often faster, and that the plant already knows how to file. A release, an unplanned shutdown, an injury or a bypassed protective function has its own regulator and its own form. Your job is not to learn that regime during the incident — it is to make sure the Communications Lead is talking to the person at the site who owns it, in the first hour, before those two workstreams file inconsistent accounts of the same event.

#Automation notes

Automate freely — everything read-only. IT-side detection enrichment. Starting the passive capture at the boundary on a defined trigger. Exporting and hashing short-retention logs. Re-running the engineering workstation project-file hash manifest and diffing it against the offline master on a schedule, so that "did the logic change?" is a query rather than a two-day investigation. Refreshing the asset inventory from passive data. Alerting on any OT protocol traffic sourced from a host that is not an engineering workstation or an HMI. None of these write to anything, and the last two are the highest-value pre-positioned detections you can build for the KAMACITE and VOLTZITE patterns.

Automate behind a human gate. Disabling a vendor remote-access account, blocking a source at the enterprise egress, and isolating an IT-side host that sits adjacent to the boundary. Reversible, scoped, and a false positive costs a phone call. Gate them on a named approver who is reachable out of hours, and have the automation attach the artefact that justified the action.

Never automate — and design the system so it cannot. Anything that writes to a controller, changes a setpoint, isolates a process-network segment, restarts an OT asset, or interacts with a safety instrumented system. Make this structural rather than procedural: no SOAR platform, agent or service account should hold a credential capable of writing to Level 2 or below. If the automation physically cannot reach the control layer, the 03:00 mistake becomes impossible instead of merely forbidden. That is the single highest-value architectural decision in this playbook, it costs nothing but discipline, and small operators can implement it as easily as large ones. Chapter 17 has the gate design in full.

#Pitfalls