<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
---
name: implementing-ics-patch-management
description: >-
  Design and operate a risk-based patch management program for ICS/SCADA systems
  that balances security updates with operational availability, including vendor
  qualification testing, rollback procedures, and compensating controls.
domain: cybersecurity
subdomain: ot-ics-security
tags:
  - patch-management
  - ics
  - scada
  - vulnerability-management
  - change-control
  - 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: ["T0866", "T0839"]
  nist-csf: ["PR.IP-12", "ID.RA-1"]
  iec-62443: ["SR 7.2", "SR 2.8"]
  uuid: a1b2c3d4-1001-4000-a001-000000000003
---

# Implementing ICS Patch Management

## Overview

ICS patch management differs fundamentally from IT patching. Production systems
may run 24/7 with annual maintenance windows. Patches require vendor qualification,
process impact analysis, and extensive rollback planning. Many legacy devices are
unpatchable — compensating controls are the only option.

Mode: `[MODE: BLUE]` for patch operations; `[MODE: ARCHITECT]` for program design.

## Prerequisites

| Requirement | Details |
|---|---|
| Complete ICS asset inventory with firmware/software versions | Required |
| Vendor patch notification subscriptions (Siemens ProductCERT, Rockwell, Schneider) | Required |
| Isolated test environment mirroring production PLC/HMI configurations | Required |
| Change management board with OT and IT representation | Required |
| WSUS/SCCM or OT-specific patch server on OT network | Required |
| Backup images of all PLC programs and HMI configurations | Required |

## Key Concepts

### Patch Classification for ICS

```yaml
critical_immediate:
  criteria: [Actively exploited (CISA KEV), RCE on Level 1/2, Safety impact]
  timeline: Next maintenance window (max 30 days)
  compensating: Network isolation + IDS signature

high_priority:
  criteria: [Remote exploit with public PoC, Affects HMI/historian]
  timeline: 60 days

low_deferred:
  criteria: [DoS only, Legacy device with no patch]
  timeline: Next scheduled outage
  compensating: Network segmentation + monitoring
```

### Asset Inventory and Vulnerability Tracking

```bash
# Export ICS asset inventory from Claroty
curl -s -H "Authorization: Bearer $CLAROTY_TOKEN" \
  "https://claroty.local/api/v1/assets?type=plc,hmi,rtu" | \
  jq '.[] | {name, ip, vendor, model, firmware}' > ics_assets.json

# Cross-reference with CISA KEV
curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" | \
  jq '.vulnerabilities[] | select(.vendorProject | test("Siemens|Rockwell|Schneider"; "i"))' > ics_kev.json

# Match assets to vulnerabilities
python3 -c "
import json
for a in json.load(open('ics_assets.json')):
    for k in json.load(open('ics_kev.json')):
        if a.get('vendor','').lower() in k.get('vendorProject','').lower():
            print(f'MATCH: {a[\"name\"]} -> {k[\"cveID\"]}')"
```

### Compensating Controls for Unpatchable Assets

```bash
# Firewall isolation for unpatchable PLC
iptables -A FORWARD -s 10.10.1.100 -d 10.10.2.50 -p tcp --dport 502 -j ACCEPT
iptables -A FORWARD -d 10.10.2.50 -j DROP

# Suricata IDS signature for known vulnerability
echo 'alert tcp any any -> 10.10.2.50 502 ( \
  msg:"CVE-2024-XXXX Exploit Against Unpatchable PLC"; \
  content:"|de ad be ef|"; sid:5000001; rev:1; )' >> /etc/suricata/rules/ics.rules
```

## Workflow

### Step 1: Vulnerability Identification

```bash
curl -s "https://www.cisa.gov/uscert/ics/advisories" | grep -oP 'ICSA-\d{2}-\d{3}-\d{2}' | sort -u
```

### Step 2: Risk Prioritization

```bash
python3 score_patches.py --assets assets.csv --kev kev_list.json --output priority.json
```

### Step 3: Test and Deploy

```bash
ansible-playbook -i ot_test patch_hmi.yml --check
ansible-playbook -i ot_test patch_hmi.yml
```

## Verification

- [ ] Asset inventory current with firmware/software versions
- [ ] Vendor advisory subscriptions active
- [ ] Test environment mirrors production
- [ ] Patch qualification completed before production
- [ ] Rollback procedures documented and tested
- [ ] Compensating controls for unpatchable assets
- [ ] Change management approval for each deployment
- [ ] Post-patch validation confirms functionality

## Detection Opportunities

- Unauthorized firmware changes → rogue patch or malware
- Deployment outside maintenance windows → policy violation
- Failed installations with reboots → potential DoS
- New connections from patched systems → misconfiguration
- Compensating control bypass → targeted attack

```yaml
title: Ics Patch Management Detection
id: b03a2db0-b23f-4ab9-ac64-41481710785a
status: experimental
description: Detects suspicious activity related to implementing ics patch management techniques in ot ics security context
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine: "*implementing*ics*"
  condition: selection
level: medium
tags:
  - attack.t0866
  - attack.t0839
  - attack.lateral_movement
falsepositives:
  - Industrial control system maintenance by authorized engineering staff
```

## References

- NIST SP 800-40 Rev 4: Patch Management
- IEC 62443-2-3: Patch Management in IACS
- CISA ICS-CERT Advisory Database
- ISA-TR84.00.09: Cybersecurity Related to SIS
