<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
---
name: implementing-ics-incident-response
description: >-
  Execute ICS-specific incident response procedures including OT evidence preservation,
  safety system verification, PLC forensics, coordinated IT/OT containment, and
  process recovery for industrial control system security incidents.
domain: cybersecurity
subdomain: ot-ics-security
tags:
  - incident-response
  - ics
  - scada
  - forensics
  - containment
  - recovery
  - ot-security
version: "1.0"
author: defconxt
license: AGPL-3.0
compatibility: Designed for Claude Code, GitHub Copilot, OpenAI Codex, Cursor, Gemini CLI, and any agentskills.io-compatible agent.
metadata:
  mitre-attack: ["T0800", "T0882", "T0879"]
  nist-csf: ["RS.RP-1", "RS.AN-1", "RS.MI-1", "RC.RP-1"]
  iec-62443: ["SR 6.1", "SR 6.2", "SR 7.1"]
  uuid: a1b2c3d4-1008-4000-a008-000000000008
---

# Implementing ICS Incident Response

## Overview

ICS incident response differs fundamentally from IT IR — availability and safety take
precedence over confidentiality. You cannot simply isolate a PLC running a chemical
reactor. Evidence must be collected while processes continue running. Coordination between
IT security, OT engineering, and plant operations is mandatory. Containment actions must
be vetted for physical safety impact before execution.

Mode: `[MODE: INCIDENT]` primary; safety verification always active.

## Prerequisites

| Requirement | Details |
|---|---|
| ICS IR plan with roles | IT Security, OT Engineering, Plant Operations, Safety |
| Pre-staged forensic toolkit for OT systems (USB-bootable, tested offline) | Required |
| Network architecture diagrams with Purdue Model zones | Required |
| PLC program backups and golden images | Required |
| Communication plan (including out-of-band channels) | Required |

## Key Concepts

### ICS IR Priority Order

```
1. SAFETY    — Verify Safety Instrumented Systems are functioning
2. STABILITY — Maintain process stability (avoid uncontrolled shutdown)
3. EVIDENCE  — Preserve forensic artifacts before they rotate
4. CONTAINMENT — Isolate threat without disrupting safe operations
5. ERADICATION — Remove attacker presence from OT environment
6. RECOVERY  — Restore to known-good state with verification
```

### Triage Phase (0-15 minutes)

```bash
# IMMEDIATE: Verify safety systems are operational
# Check SIS/ESD status — NEVER disable safety systems during IR
# Coordinate with plant operator before any network changes

# Capture volatile evidence from OT network
tcpdump -i eth1 -w /evidence/ot_traffic_$(date +%Y%m%d_%H%M%S).pcap &
TCPDUMP_PID=$!

# Capture ARP table (identify devices on OT network)
arp -an > /evidence/arp_table_$(date +%Y%m%d_%H%M%S).txt

# Snapshot active connections from affected systems
ss -tunapl > /evidence/connections_$(date +%Y%m%d_%H%M%S).txt
netstat -rn > /evidence/routes_$(date +%Y%m%d_%H%M%S).txt

# Capture Zeek logs if available
cp /var/log/zeek/current/*.log /evidence/zeek_snapshot/
```

### Evidence Preservation (OT-Specific)

```bash
# PLC state capture (non-disruptive)
# Read PLC program and data blocks
python3 -c "
import snap7, json, datetime
client = snap7.client.Client()
client.connect('10.0.0.1', 0, 1)
state = {
    'timestamp': datetime.datetime.now().isoformat(),
    'cpu_state': client.get_cpu_state(),
    'blocks': {
        'OB': client.list_blocks().OBCount,
        'FB': client.list_blocks().FBCount,
        'DB': client.list_blocks().DBCount,
    }
}
print(json.dumps(state, indent=2))
" > /evidence/plc_state_$(date +%Y%m%d_%H%M%S).json

# Historian data export (process values around incident time)
# Export 24h before and after incident start
# Preserve trending data for process manipulation detection

# HMI workstation forensics (if Windows)
# Memory capture BEFORE any containment
# Use WinPMEM or DumpIt for memory acquisition
winpmem_mini_x64.exe /evidence/hmi_memory.raw

# Windows event logs
wevtutil epl Security /evidence/security.evtx
wevtutil epl System /evidence/system.evtx
wevtutil epl "Microsoft-Windows-Sysmon/Operational" /evidence/sysmon.evtx
```

### Containment (Safety-Aware)

```bash
# ⚠️ CRITICAL: All containment actions require OT engineering approval
# Never disconnect a PLC without verifying safe shutdown procedures

# Option 1: Network-level isolation (preferred — no PLC impact)
# Block specific IPs at zone firewall while maintaining PLC-to-PLC comms
iptables -I FORWARD -s 10.5.0.0/24 -d 10.1.0.0/24 -j DROP  # Block IT→OT
iptables -I FORWARD -s 10.1.0.0/24 -d 0.0.0.0/0 -j DROP     # Block OT→Internet

# Option 2: VLAN isolation of compromised HMI (with operator coordination)
# Verify backup HMI available before isolating primary

# Option 3: ACL on OT switch (surgical containment)
# Block specific MAC address while maintaining network for other devices

# Document all containment actions with timestamps
echo "$(date -Iseconds) | Blocked IT-to-OT at zone FW | Approved by: [OT Engineer]" \
  >> /evidence/containment_log.txt
```

### Recovery

```bash
# Restore PLC from known-good backup
# Verify backup integrity first
sha256sum -c plc_golden_manifest.sha256

# Compare current PLC program with golden image
diff <(python3 dump_plc.py --target 10.0.0.1) golden/plc_001_program.txt

# Restore and verify
# Coordinate with plant operations for controlled process restart
# Monitor process variables during and after restoration
```

## Workflow

### Step 1: Activate ICS IR Team

```
Roles:
├── IR Lead (IT Security)     — Investigation coordination
├── OT Engineer               — Process safety, PLC operations
├── Plant Operator            — Process state monitoring
├── Safety Officer            — SIS verification, emergency stop authority
└── Communications            — Internal/external notification
```

### Step 2: Triage and Evidence Collection

```bash
# Execute evidence collection while maintaining operations
# Priority: network captures, PLC state, historian data, HMI forensics
```

### Step 3: Containment with Safety Verification

```bash
# All containment actions vetted by OT engineering
# Document approval chain for each action
```

### Step 4: Eradication and Recovery

```bash
# Restore from known-good images
# Validate process variables match expected ranges
# Monitor for 72h post-recovery
```

## Verification

- [ ] Safety systems verified operational throughout incident
- [ ] Evidence preserved with chain of custody documentation
- [ ] Containment actions approved by OT engineering
- [ ] PLC programs restored from verified golden images
- [ ] Process variables validated post-recovery
- [ ] 72-hour monitoring period completed without anomalies
- [ ] After-action report including detection gap analysis

## Detection Opportunities

- Timeline correlation between IT and OT events → attack path reconstruction
- Process value anomalies around incident time → scope of manipulation
- New network flows during incident window → lateral movement indicators
- PLC program changes not matching maintenance records → unauthorized modification

```yaml
title: Ics Incident Response Detection
id: fcf5981e-1419-4eb2-840f-1bfee4788be7
status: experimental
description: Detects suspicious activity related to implementing ics incident response techniques in ot ics security context
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine: "*implementing*ics*"
  condition: selection
level: medium
tags:
  - attack.t0800
  - attack.t0882
  - attack.t0879
  - attack.lateral_movement
falsepositives:
  - Industrial control system maintenance by authorized engineering staff
```

## References

- NIST SP 800-82 Rev 3 §7: ICS Incident Response
- IEC 62443-2-1 §4.3.4.5: Incident Planning and Response
- SANS ICS515: ICS Visibility, Detection, and Response
- CISA: ICS Incident Response Recommendations
