@blamejs/exceptd-skills 0.9.1

package/skills/ot-ics-security/skill.md

@@ -0,0 +1,340 @@
+---
+name: ot-ics-security
+version: "1.0.0"
+description: OT / ICS security for mid-2026 — NIST 800-82r3, IEC 62443-3-3, NERC CIP, IT/OT convergence risks, AI-augmented HMI threats, ICS-specific TTPs (ATT&CK for ICS)
+triggers:
+  - ot security
+  - ics security
+  - scada
+  - plc security
+  - operational technology
+  - industrial control
+  - iec 62443
+  - nist 800-82
+  - nerc cip
+  - it ot convergence
+  - hmi security
+  - air gap
+  - level 0
+  - level 1
+  - purdue
+data_deps:
+  - cve-catalog.json
+  - atlas-ttps.json
+  - framework-control-gaps.json
+  - cwe-catalog.json
+  - d3fend-catalog.json
+atlas_refs:
+  - AML.T0010
+attack_refs:
+  - T0855
+  - T0883
+  - T1190
+  - T1068
+framework_gaps:
+  - NIST-800-82r3
+  - IEC-62443-3-3
+  - NERC-CIP-007-6-R4
+  - NIS2-Art21-patch-management
+rfc_refs: []
+cwe_refs:
+  - CWE-287
+  - CWE-798
+  - CWE-306
+  - CWE-1037
+d3fend_refs: []
+last_threat_review: "2026-05-11"
+---
+
+# OT / ICS Security (mid-2026)
+
+## Threat Context (mid-2026)
+
+OT is no longer air-gapped. The "air gap" is a label on a Visio file, not a property of the production network. IT/OT convergence is a fait decompli at every Tier-1 operator and most Tier-2/3 manufacturers, utilities, and water authorities:
+
+- **Production planning / MES / historian systems** routinely cross the IT/OT boundary. SAP, OSIsoft PI / AVEVA PI, Wonderware / AVEVA System Platform, GE Proficy — all collect from L2/L3 and surface to L4 enterprise reporting, often via cloud.
+- **Remote-vendor maintenance access** is the operational norm. Siemens, Rockwell, Schneider Electric, ABB, GE Vernova, Emerson, Honeywell all ship remote-support tooling. A typical mid-size plant has 5–20 active vendor jump paths.
+- **Cloud-hosted OT telemetry** is mainstream. AWS IoT SiteWise, Azure Industrial IoT, GCP Manufacturing Data Engine, plus vendor-specific clouds (Siemens Insights Hub, Rockwell FactoryTalk Hub, Schneider EcoStruxure) ingest L2 telemetry at scale.
+
+**AI-augmented HMI is the new wrinkle.** Operators are increasingly fed LLM-generated summaries of plant state ("3 alarms in the last hour, two transient pressure-relief actuations on PT-204, one sustained temperature deviation on TIC-117 trending toward HH"). LLM-assisted engineering tools draft ladder logic, generate alarm-handling logic, propose setpoint adjustments. Prompt injection into an AI HMI assistant — via crafted historian tags, malicious vendor-document upload to an engineering workstation RAG, or polluted plant-state context — could lead to physical-process consequences: operator misled into ignoring a real alarm, engineering assistant inserting subtly wrong logic into a generated PLC routine, autonomous closed-loop adjustment of a setpoint outside safe range. The classical IEC 62443 zone-and-conduit model assumes deterministic data flows between trust zones; LLM-generated content is non-deterministic content sourced from a trust-conduit that does not exist in the standard.
+
+**State-sponsored OT targeting is continuous, not episodic.** Volt Typhoon pre-positioning against US critical infrastructure (water, energy, transport) was confirmed by CISA/NSA/FBI in 2023–2024 and re-affirmed in 2025 joint advisories. Sandworm continues active operations against Ukrainian grid through 2025 (Industroyer2, Pipedream/Incontroller-derived tooling, and bespoke OT-aware wipers). 2025 saw the first publicly attributed AI-assisted OT reconnaissance campaign — adversaries using LLMs to triage exfiltrated engineering documents at scale.
+
+**The exemption posture inverts vs. AGENTS.md rule #9.** Hard Rule #9 is about ephemeral and AI-pipeline environments where some controls are architecturally impossible. OT is the opposite: OT systems are LONG-LIVED, often 10–30 year service lives. PLCs in service today were commissioned when Windows XP was current; HMIs running Windows 7 are routine; safety-instrumented systems (SIS) are deliberately frozen. The exemption that applies is reversed: "patch within 30 days" is architecturally impossible not because the workload is ephemeral but because the workload is fossilised, change-controlled, and physically dangerous to disturb. Recommendations must explicitly acknowledge multi-decade lifecycles and provide compensating-control paths (segmentation, allowlisting, unidirectional gateways, virtual patching at the L2/L3 boundary) rather than handwave "update the firmware."
+
+---
+
+## Framework Lag Declaration
+
+| Framework | Control | Designed For | Fails Because |
+|---|---|---|---|
+| NIST 800-82r3 (Oct 2023) | Guide to OT Security | OT architecture and segmentation; converged IT/OT environments | Predates the AI-augmented-HMI threat class. Treats AI as "future consideration." No guidance on LLM-as-a-conduit between trust zones; no requirement that AI assistant integration appear in the zone/conduit drawing. |
+| IEC 62443-3-3 (System Security Requirements) | SR 1–7 with Security Levels SL 1–4 | Industrial automation control system security, method-neutral | Method-neutral on AI integration — neither prohibits nor scopes LLM-assisted HMI, leaving SL claims silent on a real attack surface. Conduit definitions assume deterministic protocol-level flows; LLM-generated content is non-deterministic content over a conduit that the standard does not name. |
+| NERC CIP-007-6 R4 (Security Event Monitoring) | BES Cyber Systems logging, alerting, response, retention | North-American bulk electric system (BES) High/Medium impact assets | R4 logging assumes a small, enumerable set of event sources. AI-assistant interactions (prompts, completions, tool calls) are neither in scope nor excluded — operators have no audit trail for AI-mediated operator decisions. Patch SLA in adjacent CIP-007-6 R2 is workable for IT, hard for OT firmware. |
+| NIS2 Directive Art. 21 | Risk management measures for essential/important entities (energy, transport, water, manufacturing, food, waste, digital infra) | EU-wide cybersecurity baseline | Silent on OT-specific controls. "Appropriate measures" leaves Member State authorities to fill the OT gap unevenly. Patch-management language treats IT and OT identically — operationally indefensible for 25-year PLC fleets. |
+| EU DORA + CRA | Financial-sector ICT resilience + product cybersecurity for digital elements | EU financial services; products with digital elements placed on EU market | DORA out of scope for most pure-OT operators (covers financial sector ICT). CRA applies to OT products placed on the EU market post-Dec 2027 — does not retroactively fix the deployed brownfield fleet. |
+| UK NIS Regulations + CAF (Cyber Assessment Framework) | OES (Operators of Essential Services) including energy, transport, water | UK-equivalent of NIS2; outcome-focused | CAF outcomes are sound but lack specific OT-aware operational definitions; AI-assistant integration into HMI is not a CAF outcome. |
+| AU SOCI Act 2018 (as amended 2022) + AESCSF | Security of Critical Infrastructure across 11 sectors; energy-sector cybersecurity maturity | AU critical infrastructure regulation; sector-specific maturity | AESCSF is OT-aware but its AI dimension is treated as monitoring scope, not as a new conduit type. SOCI risk-management programmes do not specifically require AI-HMI threat modelling. |
+| JP NISC Critical Infrastructure Policy (14 sectors) | National critical-infrastructure cybersecurity policy | JP CI sectors | Policy-level; operational specifics defer to sector guidelines (METI for energy, MLIT for transport). AI-augmented OT not specifically addressed in current guidance. |
+| IL INCD Critical Infrastructure Directives | National CI cyber directives | IL critical-infrastructure operators | OT-aware but does not yet codify AI-assistant integration as a regulated surface. |
+| ID BSSN Critical Infrastructure Rules | National cybersecurity for vital information infrastructure | ID critical-infrastructure operators | Maturing framework; OT specifics evolving; AI integration not yet codified. |
+| TW CSMA (Cyber Security Management Act) | National critical-infrastructure cyber-security management | TW critical infrastructure including semicon fabs and energy | Strong on segmentation and reporting; AI-assistant integration into operator workflows not specifically scoped. |
+| ISO 27001:2022 + ISO/IEC 27019 (energy utilities) | Generic ISMS + energy-sector extension | Organisation-level ISMS | A.8.8 vulnerability management is IT-flavoured; ISO/IEC 27019 adds energy specifics but predates AI-augmented HMI. |
+
+**Cross-jurisdiction posture (per AGENTS.md rule #5):** Any OT/ICS gap analysis for a multi-jurisdiction operator must cite at minimum EU NIS2 + DORA + CRA, UK NIS+CAF, AU SOCI+AESCSF, JP NISC, IL INCD, ID BSSN, TW CSMA, alongside ISO 27001:2022 + ISO/IEC 27019. US-only (NIST 800-82r3, NERC CIP) is insufficient for any operator with multinational exposure.
+
+---
+
+## TTP Mapping
+
+ATT&CK for ICS is a separate matrix from Enterprise. Many IT-rooted SOCs do not track ICS TTPs — that gap alone is a finding.
+
+| Surface | TTP | Matrix | Variant in mid-2026 | Gap Flag |
+|---|---|---|---|---|
+| Internet-exposed control-system asset | T0883 — Internet Accessible Device | ATT&CK for ICS | HMI/PLC reachable via Shodan/Censys; default-cred VNC; vendor remote-support tooling exposed | IEC 62443-3-3 SR 5.1 (network segmentation) presumes a perimeter that does not exist for vendor-mediated remote access |
+| Unauthorized control command | T0855 — Unauthorized Command Message | ATT&CK for ICS | Modbus/TCP, DNP3, S7, EtherNet/IP write to coil/register without authentication | CWE-306 (Missing Authentication) and CWE-287 (Improper Authentication) baked into protocols; IEC 62443-3-3 SR 1.1/1.2 (identification & authentication) cannot be enforced at L1 protocol layer |
+| Lateral movement within OT | T0867 — Lateral Tool Transfer | ATT&CK for ICS | Engineering workstation → HMI → PLC programming-software pivot | NIST 800-82r3 segmentation guidance does not specify L2/L1 micro-segmentation; AESCSF MIL-1 tolerates flat L2 |
+| OT scripting | T0853 — Scripting | ATT&CK for ICS | PowerShell on engineering workstation; vendor-tool macro; LLM-generated PLC code reviewed only by overworked engineer | No framework requires diff-review of AI-generated control logic |
+| IT-side initial access pivoting to OT | T1190 — Exploit Public-Facing Application | ATT&CK Enterprise | Historian (PI Vision), MES web UI, vendor remote-portal web app | NIST 800-53 SC-7 perimeter assumption does not address IT→OT pivot chain |
+| HMI host LPE | T1068 — Exploitation for Privilege Escalation | ATT&CK Enterprise | Windows 7/10 HMI host; un-rebootable; Copy Fail (CVE-2026-31431) on any Linux HMI; Print Spooler / win32k LPE family on Windows HMIs | IT patch SLAs (30 day) inapplicable to HMI hosts; no compensating-control baseline in NIST 800-82r3 |
+| Hard-coded / shared credentials | CWE-798 | CWE | Vendor default creds on PLC web UI; shared "operator" account across HMI fleet | IEC 62443-3-3 SR 1.5 (authenticator management) cannot land on devices that lack per-user accounts; NERC CIP-007-6 R5 password-management partially addresses but exempts cyber-asset classes lacking user-account features |
+| Firmware-image integrity | CWE-1037 (Processor Optimization Removal or Modification of Security-Critical Code) and CWE-345 family (insufficient verification of data authenticity, captured via cve-catalog supply-chain entries) | CWE | Unsigned firmware accepted by L1 device; vendor-side build pipeline compromise | NERC CIP-010 baseline-change management does not require firmware-image signature verification at install time |
+| AI-assistant prompt injection in HMI/engineering workflow | AML.T0010 — ML Supply Chain Compromise (closest existing ATLAS entry) | ATLAS v5.1.0 | Crafted historian tag value or vendor PDF poisons context; LLM proposes unsafe setpoint or misleads operator | No ATT&CK for ICS technique for AI-mediated operator deception; no IEC 62443 control on AI conduit; NIST 800-82r3 silent |
+
+**Note on ATT&CK for ICS ID format.** ATT&CK for ICS uses `T0xxx` IDs (e.g., T0855, T0883, T0867). The linter regex `^T\d{4}(\.\d{3})?$` accepts this shape. For IT/OT convergence techniques (the IT side of the pivot), ATT&CK Enterprise IDs (T1190, T1068, T1078) are cited alongside.
+
+**Note on ATLAS coverage.** AML.T0010 (ML Supply Chain Compromise) is the closest current ATLAS v5.1.0 mapping for AI-augmented-HMI threats; it does not specifically cover prompt-injection-as-operator-deception in a control room. This is a tracked ATLAS gap — see `forward_watch`.
+
+---
+
+## Exploit Availability Matrix
+
+| Surface / CVE Class | CVSS | RWEP | CISA KEV | PoC Public | AI-Discovered | Active Exploitation | Patch Available | Live-Patchable | OT-Aware Detection |
+|---|---|---|---|---|---|---|---|---|---|
+| IT/OT bridge — HMI Linux host hit by Copy Fail (CVE-2026-31431) | 7.8 | 90 | Yes (2026-03-15) | Yes — 732-byte script | Yes | Confirmed | Yes | Yes (kpatch/livepatch/kGraft) on supported distros; rare in OT brownfield | Partial — auditd/eBPF rules apply if deployable on HMI host |
+| IT/OT bridge — HMI Windows host LPE (Print Spooler / win32k family) | varies | varies | Some entries KEV-listed | Yes | Mixed | Confirmed | Yes for in-support; out-of-support HMIs are exposed permanently | No — Windows live-patch is limited to Hotpatch on supported builds | EDR if deployable; many OT EDR carve-outs |
+| Vendor-side OT CVEs (Siemens, Rockwell, Schneider, ABB, GE Vernova) | varies | varies | Several KEV listings 2024–2026 | Mixed — vendor disclosures only sometimes accompanied by PoC | Increasing AI-assisted RE | Targeted exploitation by Sandworm-aligned and Volt-Typhoon-aligned actors | Vendor-dependent — typical lag 60–180 days; deploy lag 1–5 years | No — firmware updates require change windows | ICS-aware IDS (Claroty, Nozomi, Dragos, Tenable OT) detection signature lag varies |
+| AI-HMI prompt injection (no CVE-class yet) | n/a | risk-modelled, not CVSS | n/a | Demonstrated in research and 2025 incident-response engagements | n/a (vector is the AI conduit itself) | Suspected in 2025 advanced campaigns | Mitigation only — design-time controls on the AI integration | n/a | Requires LLM-aware telemetry — almost never present |
+
+**Honest gap statement (per AGENTS.md rule #10).** This project's `data/cve-catalog.json` does not yet contain an exhaustive inventory of vendor-side OT CVEs (Siemens SSAs, Rockwell SD advisories, Schneider Electric Security Notifications, ABB CSAs, GE Vernova advisories). The authoritative source for current OT/ICS CVEs is the CISA ICS-CERT advisory feed at https://www.cisa.gov/news-events/cybersecurity-advisories/ics-advisories — captured in `forward_watch` for inclusion in the catalog as part of the next data refresh. Do not invent CVE IDs to fill this matrix.
+
+---
+
+## Analysis Procedure
+
+This procedure threads the three foundational design principles required by AGENTS.md skill-format spec (defense in depth, least privilege, zero trust) through every step.
+
+**Defense in depth.** Purdue Enterprise Reference Architecture layers (L0 physical I/O → L1 PLC/RTU/BPCS → L2 SCADA/HMI → L3 site operations/MES → L3.5 IDMZ → L4 enterprise → L5 cloud/enterprise edge). Controls required at every layer, with the IDMZ (L3.5) acting as the policy-enforcement boundary between OT and IT. Network segmentation (D3-NI), unidirectional gateways for OT→IT data egress, ICS-aware IDS at L2/L3 boundary (D3-NTA), signed-firmware enforcement at L1 where vendor supports it, executable allowlisting (D3-EAL) on engineering workstations and HMI hosts.
+
+**Least privilege.** Engineering-workstation privileges strictly separate from HMI operator. Vendor remote access scoped to specific assets, specific actions, and specific time windows (jump host with session recording; no standing VPN). AI HMI assistants run with read-only context by default; any tool-use that writes to historian, setpoint, alarm-suppression list, or PLC must require explicit operator approval with non-AI-mediated confirmation. SIS engineering workstations are not the same workstation as BPCS engineering, and neither has internet egress.
+
+**Zero trust.** Never assume the OT network is trustworthy because it sits behind a firewall. Identity-bind every command — Modbus write, DNP3 control, S7 download — through an authenticated proxy where the protocol does not natively support it. Every vendor-remote-access session verified per-action, not per-session. AI-assistant outputs treated as untrusted content from a non-enumerable producer until cross-checked against a deterministic source (historian raw data; SIS independent reading).
+
+### Step 1 — Inventory OT assets per Purdue level
+
+Capture (ideally from a passive ICS-aware sensor such as Claroty CTD / Nozomi Guardian / Dragos Platform / Tenable OT; failing that, from a documented walkdown):
+
+- L0 (sensors, actuators, field instruments): count, vendor, communication protocol (4–20 mA, HART, Profinet, EtherCAT, IO-Link).
+- L1 (PLCs, RTUs, BPCS controllers, SIS logic solvers): vendor, model, firmware version, last firmware update date, network address, supported protocols.
+- L2 (SCADA front-ends, HMIs, engineering workstations, OPC servers, alarm servers): host OS + patch level, application + version, account model, exposed services.
+- L3 (site MES, historians, batch managers): host OS, application + version, exposed services, data flows into and out of the zone.
+- L3.5 (IDMZ): all assets, all conduits, all data flows enumerated.
+- L4 (enterprise integration points): all systems that pull from L3 or push to L3.
+
+### Step 2 — Classify each zone against IEC 62443-3-3 Security Levels
+
+For each zone identified in Step 1, determine target SL (1–4) based on consequence of compromise:
+
+- SL 1: protection against casual or coincidental violation
+- SL 2: protection against intentional violation using simple means
+- SL 3: protection against intentional violation using sophisticated means
+- SL 4: protection against intentional violation using sophisticated means with extended resources
+
+SIS and HIPPS zones target SL 3 or SL 4. BPCS typically SL 2 minimum, SL 3 if process consequence is severe.
+
+Score actual SL achieved against target across all seven Foundational Requirements (FR 1–7). Document deltas.
+
+### Step 3 — Map IT/OT convergence surfaces
+
+Enumerate every IT→OT and OT→IT data flow:
+
+- Historian/MES ↔ ERP/SAP
+- Engineering workstation ↔ vendor cloud / patch server
+- Vendor remote-support paths (jump host, VPN, vendor-cloud-mediated)
+- Cloud-OT telemetry pipelines
+- Operator workstation ↔ enterprise email, browsing, document collaboration (a frequent finding: HMI used as a general workstation)
+- Backup pipelines into the OT environment
+- AV/EDR signature update paths
+
+For each, identify the conduit, the policy enforcement point, the authentication model, the audit/logging coverage.
+
+### Step 4 — Audit AI-assistant integration with HMI / engineering workflow
+
+Specifically ask:
+
+- Is there an LLM-generated content surface visible to operators (alarm summary, shift report, plant-state synopsis)? If yes — what is the source data, what is the prompt template, who controls the model endpoint, where are prompts and completions logged?
+- Is there an engineering assistant generating or suggesting PLC code, ladder logic, function-block diagrams, alarm-handler logic, or setpoint adjustments? If yes — what is the review gate, who signs off, is the diff visible to the SIS team?
+- Is there a control-room copilot with tool-use access (read/write to historian, alarm-suppression list, OT-asset registry, PLC programming software)? If yes — what are the writable tools, what is the approval workflow, what is the kill switch?
+- Is there a vendor-supplied AI feature in the HMI software itself (Siemens Industrial Copilot, Rockwell FactoryTalk Optix AI extensions, Schneider EcoStruxure assistant)? If yes — what is the data-residency posture, what is the trust boundary, who has prompt-injection liability?
+
+If "no AI integration" is the answer but operators have ChatGPT / Copilot / Gemini open on the same workstation: that is a shadow-AI integration, not the absence of one. Cross-reference with `mcp-agent-trust` and `ai-attack-surface`.
+
+### Step 5 — Verify network segmentation (D3-NI + D3-NTPM)
+
+- Produce the network diagram with Purdue levels, zones, conduits, and IDMZ explicitly drawn.
+- Verify conduit enforcement: is the L3↔L3.5 firewall ruleset readable, current, and audited?
+- Verify directional flow at the IDMZ: are unidirectional gateways used for OT→IT export of historian data where feasible (Waterfall, Owl, Siemens ScalanceLPE-RUGGEDCOM, Hirschmann Tofino)?
+- Are vendor remote-support paths terminated at a jump host inside the IDMZ with session recording, or do they tunnel directly to L2/L1? Direct tunnels into L2/L1 violate the zone-and-conduit model regardless of how the firewall is configured.
+
+### Step 6 — Audit vendor remote access (zero-trust application)
+
+- Maintain a vendor-access ledger: vendor, contracted scope, technical scope, account model, MFA enforcement, session-recording, time-window restrictions, last actual access.
+- Each session per-action verified (jump-host command policy, just-in-time credential issuance) rather than per-session (open VPN tunnel with vendor-side credential).
+- Confirm vendor accounts deprovisioned within 24h of contract termination.
+
+### Step 7 — Audit patch posture against NERC CIP-007 (where applicable) and SLAs against OT reality
+
+For BES Cyber Systems subject to NERC CIP-007-6 R2:
+
+- 35-day evaluation requirement: when did the entity last evaluate available patches against current installed software?
+- Patch source identification documented and current.
+- Mitigation plan filed for patches not yet applied within 35 days, with target installation date.
+
+For non-NERC OT assets, document the actual OT-realistic patch SLA (often quarterly during planned shutdowns, sometimes annual). If the documented IT SLA is 30 days but OT reality is 365+ days, the IT SLA is theater for the OT assets and a separate documented compensating-control programme is required (segmentation, allowlisting D3-EAL, ICS-IDS detection, virtual patching D3-PSEP at the boundary).
+
+### Step 8 — Build OT-aware incident response
+
+- OT incident response playbook must explicitly answer: "is process shutdown the safe response to a suspected compromise, or is it the dangerous response?" The answer is process-dependent — for some processes shutdown is the safest available action; for others (continuous-cracker chemical processes, certain power-generation modes, blast furnaces, certain water treatment phases) an unplanned shutdown is catastrophically worse than the suspected compromise.
+- Pre-decision authority: who, in advance, has authority to direct OT-side response? (Plant manager? OT lead? SIS engineer? Process safety?)
+- IR playbooks reviewed and exercised against ICS-specific scenarios (Sandworm-style, Volt-Typhoon-style pre-positioning, ransomware that hit the IT side and is approaching the IDMZ).
+
+### Step 9 — Compliance Theater Check (see dedicated section below for the concrete tests)
+
+### Step 10 — Cross-jurisdiction output reconciliation
+
+For each jurisdiction the operator is exposed to (EU, UK, AU, JP, IL, ID, TW, US, and sector-specific equivalents), produce a single mapping of the same control findings to that jurisdiction's regulatory language. Disparate findings for the same control deficiency across jurisdictions are themselves a finding.
+
+---
+
+## Output Format
+
+Produce this structure verbatim:
+
+```
+## OT / ICS Security Posture Assessment
+
+**Assessment Date:** YYYY-MM-DD
+**Site / Operator:** [name]
+**Process(es) in scope:** [e.g., crude distillation unit; 500kV substation; water treatment Train A]
+**Regulatory jurisdictions:** [US/NERC, EU/NIS2, UK/CAF, AU/SOCI+AESCSF, ...]
+
+### Purdue-Level Asset Inventory
+| Level | Assets (count + class) | OS / Firmware Range | Avg Age (years) | Patch Posture |
+|-------|------------------------|---------------------|-----------------|----------------|
+| L0    | ...                    | ...                 | ...             | n/a            |
+| L1    | ...                    | ...                 | ...             | ...            |
+| L2    | ...                    | ...                 | ...             | ...            |
+| L3    | ...                    | ...                 | ...             | ...            |
+| L3.5  | ...                    | ...                 | ...             | ...            |
+
+### IEC 62443-3-3 SL Scorecard (per zone)
+| Zone | Target SL | Actual SL | FR Deltas (FR1–FR7) | Notes |
+
+### IT/OT Bridge Inventory
+| Source | Destination | Conduit | Auth Model | Logging | Risk |
+
+### AI-HMI Integration Audit
+| Surface | Vendor / Model | Read or Write | Approval Gate | Prompt + Completion Logging | Kill Switch |
+
+### Network Segmentation Map
+[Diagram or textual representation of Purdue zones, conduits, IDMZ, vendor jump paths]
+
+### Vendor Remote-Access Ledger
+| Vendor | Scope | Account Model | MFA | Session Recording | Time Window | Last Access |
+
+### NERC CIP / NIS2 / SOCI / CAF Mappings
+[Per-jurisdiction control-status matrix]
+
+### Compliance Theater Findings
+[Outcome of the four tests in the Compliance Theater Check section]
+
+### Defensive Countermeasure Plan (D3FEND)
+[D3-NI, D3-NTPM, D3-NTA, D3-EAL, D3-PSEP — concrete control placements by Purdue layer]
+
+### Priority Remediation Actions
+1. ...
+2. ...
+3. ...
+
+### RWEP-Prioritised CVE Exposure
+[IT/OT bridge CVEs ranked by RWEP, not CVSS; see `exploit-scoring` skill for recalculation]
+```
+
+---
+
+## Compliance Theater Check
+
+Run all four tests. Any "fail" is a theater finding documented with the evidence (or absence thereof).
+
+**Theater Test 1 — Network diagram and conduit enforcement.**
+Ask: "Show me the network diagram with Purdue levels and the conduits between them, dated within the last 12 months."
+
+- If no diagram exists: zone enforcement cannot be claimed; IEC 62443-3-3 SR 5.1 evidence is fabricated.
+- If diagram exists but is older than the most recent IT/OT change (new vendor remote path, new cloud telemetry pipeline, new AI assistant integration): the segmentation claim covers a network that no longer exists.
+- If diagram exists and is current but no conduit policy artifact (firewall ruleset, allowlist, signed-conduit-policy document) corresponds to each conduit: drawing is documentation theater, not control.
+
+**Theater Test 2 — HMI host patch posture.**
+Ask: "What is the time-since-last-patch for each HMI Windows / Linux host, and what is the documented compensating control set for those that cannot be patched within the corporate SLA?"
+
+- If the answer is "we don't patch HMI" with no compensating-control documentation: patch-management policy compliance is theater for the OT subset.
+- If the answer references "segmentation" without specifying which segmentation (L2 VLAN? L3 firewall? Unidirectional gateway? Air-gap that is not actually air?) and without an executable allowlist (D3-EAL) and ICS-IDS detection (D3-NTA) as joint compensating controls: the compensating-control claim is theater.
+- Acceptable answer: "HMI hosts patched at next planned shutdown (Q3); in the interim D3-EAL deployed via [tool], D3-NTA via [ICS-IDS], host-based network restriction to specific L1 conduit only."
+
+**Theater Test 3 — AI-assistant integration disclosure.**
+Ask: "Is there any AI assistant integration with any HMI, engineering workstation, or operator workflow — including shadow IT?"
+
+- If "no" is the answer, ask the follow-up: "Do operators or engineers have ChatGPT / Copilot / Gemini / vendor-AI tooling open on the same workstation they use for HMI or PLC programming?"
+- If the follow-up answer is "yes" but the original answer was "no": shadow-AI integration is the actual state; the formal "no AI in HMI" claim is theater.
+- If formal AI integration exists but is not documented in the IEC 62443-3-3 zone-and-conduit diagram: the AI conduit is an unmapped trust path — the diagram is theater for AI risk.
+
+**Theater Test 4 — Asset inventory currency.**
+Ask: "Show me the SOCI / NIS2 / NERC CIP / CAF evidence for OT asset inventory, with the source-of-truth and the date of last reconciliation against the actual network."
+
+- If asset inventory source-of-truth is a Visio file last edited 18 months ago: regulatory asset-inventory evidence is theater.
+- If asset inventory comes from a passive ICS-aware sensor (Claroty / Nozomi / Dragos / Tenable OT) but the reconciliation between sensor view and the formal regulatory submission is unscheduled or absent: the regulatory submission is theater.
+- Acceptable: passive ICS-aware sensor is the source of truth; reconciliation against regulatory submission documented quarterly; deltas explained.
+
+---
+
+## Defensive Countermeasure Mapping
+
+Per AGENTS.md optional 8th section (required for skills shipped on or after 2026-05-11). Maps OT/ICS offensive findings to MITRE D3FEND IDs from `data/d3fend-catalog.json`, with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and the inverted ephemeral/AI-pipeline applicability per Hard Rule #9.
+
+| D3FEND ID | Technique | Purdue Layer Position | Least-Privilege Scope | Zero-Trust Posture | OT-Realistic Applicability |
+|---|---|---|---|---|---|
+| D3-NI | Network Isolation | L3.5 IDMZ as the primary policy-enforcement boundary; secondary L2↔L1 micro-segmentation | Per-zone, per-conduit; no flat L2 between BPCS and SIS | Conduit policy applied per-flow, not per-VLAN; default-deny conduit posture | Universally applicable; the foundational OT control. Brownfield retrofit constrained by L1 device limits — supplement with L2.5 enforcement points where L1 cannot enforce. |
+| D3-NTPM | Network Traffic Policy Mapping | L3.5 IDMZ; L2/L3 boundary; vendor-jump-host conduits | Conduit-level allowlist of source/destination/protocol/port/direction | Continuous verification of conduit conformance; deviation → alert | Applicable. Requires ICS-protocol-aware policy expression (Modbus function codes, S7 PDU types, DNP3 object groups) not just TCP/UDP. |
+| D3-NTA | Network Traffic Analysis | Passive sensor at L2/L3 span ports; L3.5 IDMZ choke; L1 where feasible (some devices, some protocols) | Operator-visible alerts scoped to that operator's zone; SOC-visible aggregated | Detection assumes the network is hostile until proven otherwise per-flow | Applicable. ICS-aware IDS (Claroty CTD, Nozomi Guardian, Dragos Platform, Tenable OT, SCADAfence) is the deployed control; signature/anomaly lag is a tracked metric. |
+| D3-EAL | Executable Allowlisting | L2 HMI hosts; L2 engineering workstations; L3 historian/MES hosts | Per-host allowlist of signed executables; vendor-tooling exceptions explicit | Default-deny execution; only enumerated binaries run | Applicable to Windows/Linux HMI and engineering workstation hosts. Cannot apply directly to L1 PLC/RTU devices — for those, signed-firmware enforcement (where vendor supports) is the analogue. |
+| D3-PSEP | Process Segment Execution Prevention | L2 HMI hosts; L2 engineering workstations | Per-process memory-execution policy; non-exec data segments | Memory regions and process behaviour continuously verified at execution time | Applicable where host OS supports modern memory protections. Brownfield Windows 7 / WinCC older versions have weaker support — compensating control: tighter D3-EAL + D3-NTA. |
+
+**Inverted ephemerality posture (per Hard Rule #9, reversed).** OT assets are long-lived (10–30 year service lives). Controls that assume rapid patching are unrealistic; controls that assume rebuild-on-change are catastrophic. The OT-appropriate posture: virtual patching at L3.5 / L2 boundaries, executable allowlisting on hosts that cannot be re-imaged, ICS-IDS detection as the primary control where prevention is architecturally unavailable, signed-firmware enforcement where supported, and explicit documentation of multi-decade compensating-control programmes where the device itself cannot be hardened. Recommendations that read "patch the PLC firmware" without specifying the change window, the vendor's signed-firmware support status, and the rollback plan are operationally indefensible.
+
+---
+
+## Hand-Off / Related Skills
+
+After producing the OT/ICS posture assessment, chain into the following skills.
+
+- **`kernel-lpe-triage`** — for every L2/L3 Linux HMI / historian / engineering-workstation host, run kernel-lpe-triage to score Copy Fail (CVE-2026-31431) and Dirty Frag (CVE-2026-43284 / -43500) exposure. The HMI host class is the most operationally constrained patch surface in the enterprise; the live-patch-vs-reboot decision tree applies with the additional constraint that reboot during continuous operation is often unacceptable.
+- **`supply-chain-integrity`** — for vendor-supplied firmware, engineering software, and AI features. SLSA-style provenance, SBOMs (CycloneDX or SPDX), signed-firmware verification, in-toto attestations, and Sigstore verification all apply to OT vendors with widely varying maturity. The OT supply chain is the single most under-controlled surface in most operators.
+- **`identity-assurance`** — engineering workstation privileges, vendor remote-access account model, jump-host MFA, just-in-time credentialing, and the separation of engineering vs. operator identities. This is where least-privilege gets concrete; many OT operators have a single shared "Engineer" account on the engineering workstation, which is identity theater.
+- **`attack-surface-pentest`** — OT-scoped pen-test with explicit safety boundaries. The pen-test rules of engagement must spell out: no production-effecting actions on live processes, no PLC writes outside an isolated test bench, no DoS testing on live conduits, presence of an OT-aware authoriser with stop-test authority, and explicit identification of any SIS-adjacent or SIL-rated asset that is out of scope. TIBER-EU / DORA TLPT for EU financials, CBEST for UK financial sector, and AESCSF red-team activities for AU energy all need OT-specific carve-outs.
+- **`defensive-countermeasure-mapping`** — to deepen the D3FEND mapping above into a layered remediation plan rather than a single-control patch ticket; the OT-realistic compensating-control programme typically combines five or more D3FEND techniques in a defence-in-depth stack.
+- **`compliance-theater`** — to extend the four theater tests above with general-purpose theater detection on the operator's wider GRC posture.
+- **`framework-gap-analysis`** — for any multi-jurisdiction operator, to produce the per-jurisdiction reconciliation called for in Analysis Procedure Step 10.
+- **`global-grc`** — alongside framework-gap-analysis when EU NIS2 + DORA + CRA, UK NIS+CAF, AU SOCI+AESCSF, JP NISC, IL INCD, ID BSSN, TW CSMA all apply.
+- **`ai-attack-surface`** and **`mcp-agent-trust`** — when AI-HMI integration is in scope; ai-attack-surface for prompt-injection and operator-deception threats, mcp-agent-trust for tool-use governance on copilots with write access to historian / alarm-suppression / setpoint surfaces.
+- **`policy-exception-gen`** — to generate defensible exceptions for OT assets where corporate IT SLAs (30-day patch) are architecturally infeasible. The exception evidence is the documented compensating-control programme: D3-NI conduit policy, D3-EAL allowlist, D3-NTA detection coverage, change-window patch schedule, and vendor support status.
+
+**Forward watch (per skill-format spec).** ATT&CK for ICS coverage expansion to LLM-mediated operator deception; ATLAS additions covering control-system AI integration; CISA ICS-CERT advisory feed (https://www.cisa.gov/news-events/cybersecurity-advisories/ics-advisories) for OT vendor CVE inclusion in `data/cve-catalog.json`; IEC 62443-4-2 SR refinements for AI-integrated components; NIST 800-82r4 (in development) for AI-augmented HMI guidance; vendor signed-firmware roadmaps (Siemens, Rockwell, Schneider Electric, ABB, GE Vernova) for D3-EAL-analogue coverage at L1.