operational-technology

# Operational Technology Security Skill

OT/ICS security is fundamentally different from IT security. Safety takes
priority over confidentiality. Availability is the highest priority (C-I-A
becomes A-I-C in OT). Never perform active scanning on live OT networks
without explicit change control approval and maintenance window scheduling.


## ot-asset-discovery

# OT Asset Discovery

## Purpose
Build and maintain an accurate OT asset inventory using passive and carefully controlled active techniques, classified by Purdue model zone.

---

## 1. Critical OT Discovery Constraints

**NEVER perform active network scanning on live OT networks without:**
- Written change control approval
- Maintenance window scheduled during low-production period
- Process safety team sign-off
- Rollback plan documented
- OT engineer on-site during scan

Reason: Active scans can crash PLCs, disrupt SCADA communications, and cause
process upsets. Some legacy OT devices cannot handle any unsolicited network traffic.

---

## 2. Passive Discovery Techniques

### Network TAP/SPAN Port Monitoring
```
Method: Mirror OT switch traffic to monitoring device without any active injection

Setup:
  1. Request SPAN port configuration from OT network engineer (change control)
  2. Connect monitoring device (Claroty/Dragos/Nozomi sensor) to SPAN port
  3. Monitoring device passively analyses traffic for device identification
  4. Asset discovery from protocol analysis (no active scanning)

Tools:
  Claroty Continuous Threat Detection (CTD)
  Dragos Platform
  Nozomi Networks Guardian
  SecurityMatters/Forescout eyeSight OT
  
  Open source: Zeek + OT protocol plugins, Snort with OT rules
```

### Passive Asset Fingerprinting from Traffic
```
OT devices announce themselves via protocol traffic:
  Modbus TCP:       Function code 43 (Device ID) in responses
  EtherNet/IP:      Device identity object (ENIP list identity packets)
  PROFINET:         DCP (Discovery and Config Protocol) packets
  Siemens S7:       S7comm device info in handshake
  OPC-UA:           GetEndpoints response contains server info
  BACnet:           I-Am broadcast contains device info

Capture passively and extract:
  - IP address, MAC address, OUI (manufacturer from first 3 bytes)
  - Protocol(s) used
  - Vendor/model from protocol-specific fields
  - Firmware version (if exposed in protocol)
```

---

## 3. Purdue Model Zone Classification

### Purdue Reference Model Zones
| Level | Name | Devices | Description |
|-------|------|---------|-------------|
| Level 0 | Field Level | Sensors, actuators, motors, valves | Physical process devices |
| Level 1 | Control Level | PLCs, DCS controllers, RTUs, safety controllers | Automated process control |
| Level 2 | Supervisory Level | HMI workstations, SCADA servers, DCS servers | Human-machine interface |
| Level 3 | Operations Level | Historian servers, MES, engineering workstations | Site-wide operations |
| Level 3.5 | DMZ | Data historians (read-only copy), jump servers, remote access | IT/OT boundary |
| Level 4 | Business Network | ERP, email, corporate IT | Enterprise systems |
| Level 5 | Enterprise | Internet, cloud | External connectivity |

### Classification Criteria
```
For each discovered device, determine:
  1. Primary function: control, supervisory, operational, or enterprise
  2. Protocols used: OT protocols (Levels 0-3) vs IT protocols (Levels 4+)
  3. Communication patterns: talks to PLCs = Level 1-2 range
  4. Physical location: control room, substation, plant floor
  5. Owner: OT engineering vs IT

Document in asset register with Purdue level for zone and conduit design.
```

---

## 4. OT Protocol Reference

| Protocol | Default Port | Layer | Common Use |
|----------|-------------|-------|-----------|
| Modbus TCP | 502 | TCP | PLC/RTU polling; manufacturing, utilities |
| Modbus RTU | Serial | Serial | Same as Modbus TCP over serial |
| DNP3 | 20000 | TCP/UDP | SCADA/RTU comms; electric/water utilities |
| EtherNet/IP | 44818 | TCP/UDP | Allen-Bradley PLCs; manufacturing |
| Siemens S7 | 102 | TCP | Siemens PLCs (S7-300/400/1200/1500) |
| OPC-UA | 4840 | TCP | Interoperability; historian to SCADA |
| OPC-DA | 135 (DCOM) | TCP | Legacy OPC; Windows-based |
| PROFINET | 34962-34964 | UDP | Siemens/Phoenix Contact; manufacturing |
| BACnet | 47808 | UDP | Building automation (HVAC, lighting) |
| IEC 61850 | 102 (MMS) | TCP | Substation automation; power systems |
| IEC 60870-5-104 | 2404 | TCP | SCADA; power grid |
| ICCP (TASE.2) | 102 | TCP | Control centre to control centre; power |

---

## 5. Asset Register Template

```
Asset ID:          OT-<YYYY>-<nnn>
Hostname/Tag:      <device tag or hostname>
IP Address:        <IPv4>
MAC Address:       <MAC + OUI lookup>
Purdue Level:      0 / 1 / 2 / 3 / 3.5 / 4
Manufacturer:      <vendor>
Model:             <model>
Firmware Version:  <version>
Serial Number:     <serial>
Protocols:         <Modbus TCP, S7, EtherNet/IP, etc.>
OS:                <Windows XP SP3 / VxWorks 6.4 / N/A>
Function:          <PLC for Reactor A / HMI for Unit 3 / Historian>
Physical Location: <Building, Floor, Panel ID>
Network VLAN:      <VLAN ID>
Owner:             <OT Engineering contact>
Supported By:      <Vendor name + contract expiry>
Last Updated:      <YYYY-MM-DD>
Patch Status:      <Current / Behind / EOL/Unsupported>
NERC CIP BES:      <Yes/No — is this a BES Cyber System?>
```

---

## 6. Asset Discovery Checklist

- [ ] Change control approved for any active techniques
- [ ] SPAN port configuration documented and approved
- [ ] Passive monitoring sensor deployed and capturing
- [ ] Protocol analysis running (Claroty/Dragos/Nozomi or equivalent)
- [ ] All discovered assets classified by Purdue model level
- [ ] Asset register populated with all required fields
- [ ] Network topology diagram updated (Layer 2 and Layer 3)
- [ ] VLAN segmentation documented
- [ ] Unsupported/EOL assets flagged for risk assessment
- [ ] NERC CIP BES Cyber System categorisation completed (if applicable)



## risk-and-vulnerability-assessment

# Risk and Vulnerability Assessment

## Purpose
Assess OT/ICS specific risks, map ICS-CERT advisories, analyse CVEs in OT context, and evaluate legacy system and air-gap risks.

---

## 1. ICS-CERT Advisory Mapping

### Monitoring ICS Advisories
```
Primary source: CISA ICS Advisories
  URL: https://www.cisa.gov/uscert/ics/advisories

RSS Feed:
  https://www.cisa.gov/uscert/ncas/current-activity.xml

Advisory categories:
  ICS-ADVISORY: Vulnerability advisories for ICS products
  ICS-ALERT:    Active threats targeting ICS
  ICS-CERT-ALERT: Immediate threat information

For each advisory:
  1. Identify if affected vendor/product in your asset register
  2. Check CVSS score AND OT-specific context
  3. Assess exploitability in your environment
  4. Determine if exploit code is public
  5. Create risk register entry if affected asset exists
```

### Vendor Security Advisories to Monitor
- Siemens ProductCERT: cert.siemens.com
- Schneider Electric: security.schneider-electric.com/security-advisories
- Rockwell Automation: rockwellautomation.com/security-notices
- Honeywell: honeywell.com/productcert
- ABB: new.abb.com/about/cybersecurity/product-security
- GE Digital: digitalsupport.ge.com/hc/en-us/categories/security-advisories

---

## 2. CVE Analysis in OT Context

### OT-Specific CVSS Assessment
```
Standard CVSS scoring often understates OT risk because:
  - Confidentiality impact is LESS critical in OT (process data is less sensitive)
  - Availability impact is MORE critical in OT (production/safety depends on it)
  - Physical consequences must be added to financial/data impact

OT-adjusted risk assessment:
  CVE with CVSS 4.0 (low standard) but affects process availability = treat as HIGH
  CVE with CVSS 9.8 (critical standard) but requires physical access = treat as MEDIUM

Example: CVE affecting HMI availability but requiring network access:
  Standard CVSS: 7.5 (High)
  OT context: Production halt for 24h = $2M loss; safety implications
  OT-adjusted risk: Critical
```

### Legacy System Risk Assessment
```
Common legacy systems in OT (frequently encountered in 2026):
  Windows XP: End of Support April 2014 — no patches available
  Windows 2003: End of Support July 2015
  Windows 7: End of Support January 2020
  Windows Server 2008: End of Support January 2020

Risk factors for unpatched legacy:
  1. Known exploits: EternalBlue (MS17-010) exploitable on unpatched Win7/2008
  2. No vendor patches: cannot be remediated in-place
  3. Production dependency: cannot be replaced without process redesign

Compensating controls for legacy:
  - Network isolation (dedicated VLAN, no internet access, no enterprise network access)
  - Application whitelisting (Claroty/TXOne endpoint protection for OT)
  - Read-only mode where possible (prevent unauthorised writes to PLC)
  - Monitoring (Dragos/Claroty anomaly detection)
  - Documented exception with risk owner sign-off and annual review
```

---

## 3. Air-Gap Integrity Assessment

### Common Air-Gap Violations
```
Inadvertent connections:
  Remote support tools: TeamViewer, RDP, Citrix left installed by vendor
  Dual-homed engineering workstations: laptop with both OT NIC and WiFi enabled
  USB from untrusted source: maintenance personnel bringing in infected USB
  Historian connections to enterprise: OSIsoft PI server accessing both OT and IT
  Business intelligence: Excel macros pulling live data from SCADA server

Assessment steps:
  1. Review all network interface configurations on Level 2-3 devices
  2. Identify all remote access tools installed (check registry, running services)
  3. Verify historian/mirror server configuration (one-way data flow only)
  4. Audit USB port status (hardware disabled vs software disabled)
  5. Verify no WiFi interfaces enabled on OT devices
  6. Check for dual-homed devices (netstat on each endpoint if possible)
```

---

## 4. Consequence-Based Risk Assessment

### OT Risk Dimensions (Different from IT)
| Risk Dimension | IT Priority | OT Priority |
|----------------|-------------|-------------|
| Confidentiality | High | Low-Medium |
| Integrity | High | High |
| Availability | Medium | Critical |
| Safety | N/A | Critical |
| Environmental | N/A | High (in regulated industries) |
| Production impact | Low | Critical |

### Consequence Levels for OT Risk
| Level | Safety | Environmental | Production | Duration |
|-------|--------|---------------|-----------|---------|
| 1 Negligible | No injury | No release | < 1h disruption | Seconds-minutes |
| 2 Minor | First aid | Contained, minor | 1-4h | Hours |
| 3 Moderate | Lost time injury | Reportable release | 4-24h | Day |
| 4 Major | Serious injury/hospitalisation | Significant release | 1-7 days | Week |
| 5 Catastrophic | Fatalities | Major environmental incident | > 1 week | Weeks/permanent |

---

## 5. MITRE ATT&CK for ICS

### Key ICS Technique Categories
```
Initial Access:
  T0817: Drive-by Compromise
  T0865: Spearphishing Attachment
  T0866: Exploitation of Remote Services (remote access to OT)
  T0817: Drive-By Compromise

Execution:
  T0807: Command-Line Interface
  T0871: Execution through API
  T0823: Graphical User Interface (HMI manipulation)

Collection:
  T0801: Monitor Process State
  T0802: Automated Collection
  T0811: Data from Information Repositories (historian)

Impact:
  T0813: Denial of Control (T1499 equivalent for OT)
  T0816: Device Restart/Shutdown
  T0826: Loss of Availability
  T0827: Loss of Control
  T0828: Loss of Productivity and Revenue
  T0829: Loss of View
  T0831: Manipulation of Control
  T0835: Manipulate I/O Image
  T0836: Modify Parameter
  T0837: Modify Control Logic (reprogram PLC — Stuxnet technique)
  T0880: Loss of Safety (SIS manipulation — Triton/TRISIS attack)
```

---

## 6. Risk Assessment Checklist

- [ ] ICS-CERT advisory mapping completed (affected assets identified)
- [ ] All CVEs with CVSS > 7.0 assessed with OT-specific context
- [ ] Legacy/EOL systems inventoried and risk-accepted with compensating controls
- [ ] Air-gap integrity assessed (remote tools, dual-homed devices, historian connections)
- [ ] Consequence-based risk assessment completed for top 10 risks
- [ ] ATT&CK for ICS technique mapping completed
- [ ] OT-specific risk register created (separate from IT risk register)
- [ ] Process safety team consulted on consequence ratings
- [ ] Risk register shared with plant manager and OT owner



## network-security

# Network Security

## Purpose
Design and implement OT network security using ISA/IEC 62443 zone and conduit model, DMZ architecture, and unidirectional data flow for IT/OT convergence points.

---

## 1. ISA/IEC 62443 Zone and Conduit Model

### Security Levels (SL)
| Level | Protection Against | Typical Controls |
|-------|-------------------|-----------------|
| SL 1 | Accidental or incidental violation | Basic authentication, logging |
| SL 2 | Intentional violation with simple means, low motivation | Strong auth, network segmentation, monitoring |
| SL 3 | Intentional violation with sophisticated means | Multi-factor auth, intrusion detection, encryption |
| SL 4 | Sophisticated attack with extended resources (nation-state) | Advanced cryptography, physical isolation, HSMs |

### Zone Design Principles
```
Zone = group of logical or physical assets that share the same security requirements
       and have common threat exposure and acceptable risk

Zone design steps:
  1. Group assets by function AND security level requirement
  2. Define Security Level Target (SL-T) for each zone
  3. Identify existing controls; determine Security Level Capability (SL-C)
  4. Gap: SL-C < SL-T → remediation required

Example zones:
  Safety Zone (SL-T 3-4):    SIS, safety PLCs — highest isolation
  Control Zone (SL-T 2-3):   PLCs, DCS controllers
  Supervisory Zone (SL-T 2): HMI servers, SCADA
  Operations Zone (SL-T 2):  Historians, engineering workstations
  DMZ (SL-T 2-3):            Data diodes, jump servers, remote access
```

### Conduit Security
```
Conduit = communication path between zones
          Each conduit must have controls matching the LOWER SL-T of the two zones

Conduit controls:
  Firewall/DMZ:         Filter traffic at zone boundaries (whitelist protocols)
  Data diode:           Hardware-enforced one-way flow (highest assurance)
  Application proxy:    Only approved protocols pass; deep inspection
  Encryption:           TLS 1.2+ for conduits crossing zone boundaries
  Authentication:       All conduits require authentication (no anonymous connections)

Document each conduit:
  Source zone, Destination zone, Protocol allowed, Direction, Firewall rule ID
```

---

## 2. IT/OT Convergence Risk Points

### High-Risk Convergence Points
| Convergence Point | Risk | Mitigation |
|------------------|------|-----------|
| Historian server (reads from OT, accessible by IT) | IT compromise reaches OT | Data diode; read-only historian; DMZ placement |
| Engineering workstation (programs PLCs, has IT access) | Malware path from IT to PLC | Dedicated OT laptop; no IT network connection; removable media policy |
| Remote access (VPN/RDP to OT network) | Direct OT network access | Jump server in DMZ; MFA; session recording; time-limited |
| Business intelligence (BI tools reading SCADA data) | OT data exposure; reverse connection | One-way data diode; data mirror in IT DMZ only |
| Patch server (WSUS for OT Windows machines) | Malicious patch or connection path | Dedicated WSUS in OT zone; no direct internet; tested patches only |

---

## 3. DMZ Design for IT/OT

### Recommended OT DMZ Architecture
```
Enterprise Network (IT)
        |
   [IT Firewall]
        |
   [ OT DMZ ]
   ┌────────────────────────────────────────────────────┐
   │  Jump Server (MFA required; session recording)      │
   │  Data Historian Mirror (read-only copy; passive)    │
   │  Remote Access Gateway (with MFA)                   │
   │  Patch Management Server (tested patches only)      │
   │  Antivirus Update Server (signature distribution)   │
   └────────────────────────────────────────────────────┘
        |
   [OT Firewall] (whitelist rules only; deny-all default)
        |
   OT Network (Levels 0-3)
```

### Firewall Rules (OT Firewall — Whitelist Approach)
```
Rule design: DEFAULT DENY ALL; allow only specific required communication

Example rules:
  ALLOW  Historian Mirror → OT Historian: TCP 5450 (OSIsoft PI OPC) — unidirectional via diode
  ALLOW  Jump Server → HMI: RDP TCP 3389 — only from jump server
  ALLOW  Patch Server → OT Windows: TCP 8530 (WSUS) — initiating from OT side
  DENY   IT Network → OT Network: ALL — except via jump server
  DENY   OT Network → Internet: ALL — no direct internet access from OT

Document every rule:
  Rule ID, Source, Destination, Protocol/Port, Direction, Justification, Owner, Date Added
```

---

## 4. Unidirectional Gateways (Data Diodes)

### When to Use Data Diodes
```
Use data diodes when:
  - Historian data must flow to IT/enterprise (one-way: OT → IT)
  - Threat intelligence feeds into OT SIEM (one-way: IT → OT)
  - OT audit logs sent to IT SIEM (one-way: OT → IT)

Vendors:
  Waterfall Security Solutions: Unidirectional Security Gateway
  Owl Cyber Defense (now part of Parsons): Owl Data Diode
  Nexor: Cyber Gateway
  Fox-IT: DataDiode

Key property: hardware-enforced one-way optical link; no software bypass possible
              Even if compromised software is installed, data cannot flow backwards
```

---

## 5. Remote Access Controls for OT

### Secure Remote Access Architecture
```
Requirements for all OT remote access:
  1. All access via jump server in OT DMZ — no direct connectivity
  2. MFA required for all remote access (hardware token preferred for vendors)
  3. Session recording for all privileged remote sessions
  4. Time-limited access windows (not 24/7 standing access)
  5. Vendor access: approved per maintenance request; auto-expire after task

Jump server configuration:
  - Hardened OS (Windows Server Core or Linux minimal)
  - No local admin for vendors (domain-controlled accounts only)
  - Application whitelisting (only approved OT tools available)
  - USB port disabled
  - Session recording: keystroke + screen (full capture)
  - Network access limited to specific OT assets for specific vendor

Vendor remote access SLA:
  Access request submitted: minimum 24h notice (emergency: 4h with manager approval)
  Access window: maximum 4h per session; renewable with approval
  Access logs: retained 12 months minimum
```



## incident-detection-and-response

# Incident Detection and Response

## Purpose
Deploy OT-specific monitoring, detect anomalies in process behaviour, and respond to incidents with safety-first procedures.

---

## 1. OT-Specific Monitoring Platforms

### Passive Monitoring Tools
```
Dragos Platform:
  - Network traffic analysis; OT protocol deep inspection
  - Threat behaviour analytics (Dragos threat intelligence)
  - Activity groups (threat actor tracking)
  - Vulnerability management for OT assets
  - Passive only: no traffic injection

Claroty Continuous Threat Detection (CTD):
  - Asset inventory from passive traffic
  - Anomaly detection (baseline normal traffic patterns)
  - Policy-based alerting (new connections, unusual commands)
  - Integration with Claroty xDome for enterprise

Nozomi Networks Guardian:
  - Passive network monitoring
  - AI-based anomaly detection
  - Asset visibility and software inventory
  - OT protocol support: 80+ protocols

Critical OT monitoring principle:
  ALL monitoring must be PASSIVE (SPAN/TAP only)
  NEVER deploy active scanning agents directly to OT devices
  Active monitoring requires change control and maintenance window
```

---

## 2. Behavioural Anomaly Detection

### Baseline Normal Behaviour
```
Establish baselines for:
  1. Network traffic patterns:
     - Normal devices that communicate (source/destination pairs)
     - Normal protocols per device pair
     - Normal traffic volumes (bytes/packets per time period)
     - Normal communication times (engineering activity may be 8am-5pm)
  
  2. Process values (if historian data available):
     - Normal operating ranges for process variables (temperature, pressure, flow)
     - Normal rate of change for each variable
     - Alarm states and frequency

  3. Control commands:
     - Normal write frequency to PLC registers
     - Expected command sequences (start/stop sequences)
     - Normal HMI operator login times and actions
```

### Anomaly Alert Types
| Alert Type | Description | Severity |
|------------|-------------|---------|
| New device detected | Unknown IP/MAC appeared on OT network | High |
| Unusual engineering command | Write to PLC outside maintenance window | Critical |
| Protocol violation | Malformed or unexpected OT protocol traffic | High |
| New connection | First time communication between two devices | Medium |
| Scan activity | Rapid connection attempts to multiple devices | Critical |
| Excessive write commands | Write frequency exceeds baseline 3× | High |
| Control logic download | Firmware/logic change to PLC | Critical |
| Remote access outside window | Vendor connecting outside approved time | High |
| Process value out of range | Process variable beyond expected limits | High |

---

## 3. OT Incident Response Procedures

### Safety-First Principle
```
CRITICAL: Safety takes absolute priority over forensic preservation and
          IT/security investigation objectives.

Before any OT incident response action:
  1. Consult process safety engineer: is it safe to continue the process?
  2. Define safe state: what is the safe position for valves, pumps, etc.?
  3. Production continuity: what is the minimum required to continue safely?
  4. Only AFTER safe state established: begin security investigation

OT IR team composition:
  Security incident responder (lead for security actions)
  Process safety engineer (lead for safety decisions)
  OT/control systems engineer (lead for OT technical actions)
  Plant manager (authorise business decisions)
  Legal/compliance (if regulatory implications)
```

### OT IR Phases
```
Phase 1: Detection and Triage (0-2 hours)
  - Alert received from OT monitoring system
  - Verify alert: is this a security event or process event?
  - Assess safety impact: is the process in a safe state?
  - Activate OT IR team
  - Notify plant manager and CISO

Phase 2: Containment (2-8 hours)
  - Safety first: ensure safe state maintained
  - Network isolation: isolate affected OT zone from IT and internet
  - Remote access: suspend all remote access immediately
  - Preserve: take memory dumps and network captures before clearing
  - Assess production impact: can process continue safely?

Phase 3: Investigation (8-72 hours)
  - Analyse historian logs, HMI logs, network captures
  - Identify affected PLCs/HMIs (is logic modified?)
  - Verify process integrity: are sensor readings trustworthy?
  - Determine attack vector and timeline

Phase 4: Recovery
  - Restore from known-good PLC configuration backups
  - Verify restored logic against reference backups (hash comparison)
  - Gradual process restart with engineering supervision
  - Enhanced monitoring post-recovery (2-4 weeks)
```

---

## 4. OT Log Sources

### Available Log Sources by Level
| Source | Log Type | Key Information |
|--------|---------|----------------|
| HMI servers | Operator action logs | Who did what to which control |
| SCADA systems | Alarm and event logs | Process alarms, setpoint changes |
| Historians (OSIsoft PI, Aspentech IP21) | Process data + audit trails | Process values + access logs |
| Engineering workstations | Windows event logs | Who logged in, what tools used |
| Network devices (OT switches) | Syslog | New MAC addresses, port changes |
| Claroty/Dragos sensors | OT network events | All monitored OT network activity |
| Jump servers | Session logs + recordings | All remote access activity |

### Log Analysis for OT Incidents
```
Priority investigation areas:
  1. HMI audit logs: look for commands issued during the incident window
     - PLC write commands (setpoint changes, output commands)
     - Mode changes (manual vs automatic)
     - Alarm acknowledgements during incident

  2. Engineering workstation logs: look for:
     - PLC programming tool launches (STEP 7, RSLogix, etc.)
     - USB device insertions
     - Remote connections initiated
     - Downloads to PLCs (configuration change)

  3. Network captures: look for:
     - New connections established (especially from IT side)
     - Unusual OT protocol traffic (unexpected function codes)
     - Large data transfers from Level 0-2 devices
```

---

## 5. NERC CIP Incident Reporting

### Reporting Requirements
```
CIP-008-6: Incident Reporting and Response Planning

Reportable Incidents (to NERC/E-ISAC/CISA):
  - Any compromise or attempt to compromise the Electronic Security Perimeter (ESP)
  - Any compromise of an Electronic Access Control or Monitoring System (EACMS)
  - Any cyber incident impacting a BES Cyber System

Reporting timeline:
  Initial report: within 1 hour of discovery of a reportable cyber security incident
  to: electricity-isac@nerc.net and CISA at report@cisa.gov

  Note: "Reportable" includes attempted compromise, not just successful
```



## resilience-and-compliance

# Resilience and Compliance

## Purpose
Build OT operational resilience through business continuity planning, backup procedures, and compliance with ISA/IEC 62443 and NERC CIP requirements.

---

## 1. ISA/IEC 62443 Security Level Targets

### Security Level Requirements Per Zone
```
Assign Security Level Targets (SL-T) based on zone criticality:

SL 1 (Basic protection):
  - Protection from accidental or unintentional violation
  - Use for: non-critical peripheral devices, display-only systems
  - Controls: basic password, logging

SL 2 (Protection against low sophistication intentional attack):
  - Defence against script-kiddie level attacks
  - Use for: standard control zones, supervisory zones
  - Controls: network segmentation, MFA for admin, monitoring

SL 3 (Protection against sophisticated intentional attack):
  - Defence against targeted attack with insider knowledge
  - Use for: high-criticality process control, safety systems vicinity
  - Controls: defence in depth, IDS, encrypted communications, privileged access management

SL 4 (Protection against state-sponsored level attack):
  - Defence against highly sophisticated, well-resourced attacker
  - Use for: safety instrumented systems, critical infrastructure
  - Controls: HSMs, air-gap or unidirectional gateway, advanced monitoring
```

---

## 2. NERC CIP Requirements

### Applicable Standards for BES Cyber Systems
| Standard | Title | Key Requirements |
|----------|-------|----------------|
| CIP-002-5.1a | BES Cyber System Categorisation | Identify and categorise BES Cyber Systems (High/Medium/Low) |
| CIP-003-8 | Security Management Controls | Senior management security plan; policies; exceptions |
| CIP-004-6 | Personnel & Training | Background checks; training; access management |
| CIP-005-6 | Electronic Security Perimeters | Define ESP; control all electronic access points; remote access |
| CIP-006-6 | Physical Security | Physical security of BES Cyber Systems |
| CIP-007-6 | Systems Security Management | Ports/services, patch management, malware prevention, logging |
| CIP-008-6 | Incident Reporting | Incident response plan; reporting timeline |
| CIP-009-6 | Recovery Plans | BCP/DR plans for BES Cyber Systems |
| CIP-010-3 | Configuration Change Management | Baseline configurations; change control; vulnerability assessments |
| CIP-011-2 | Info Protection | BES Cyber System Information (BCSI) protection |
| CIP-013-1 | Supply Chain Risk Management | Vendor risk management; software integrity |

### CIP-007 Systems Security Management Key Controls
```
CIP-007-R1: Ports and Services
  - Disable all unnecessary TCP/UDP ports on BES Cyber Systems
  - Document all enabled ports with business justification
  - Review quarterly

CIP-007-R2: Security Patches
  - Track security patches within 35 days of release
  - Apply patches or document mitigation within 35 days of release
  
  Patch SLA: 35 calendar days from ICS-CERT/vendor advisory to patch or mitigate

CIP-007-R3: Malware Prevention
  - Deploy malware prevention on all applicable assets
  - Update signatures every 35 days (or document why not feasible)
  
CIP-007-R4: Security Event Monitoring
  - Generate alerts for: authentication failures, account activity, detected malware
  - Review alerts within 15 minutes of generation (for High/Medium BES systems)
  - Retain logs for 90 days minimum

CIP-007-R5: System Access Controls
  - Enforce minimum password/access requirements
  - Limit unsuccessful logins (lock after 3-6 attempts)
  - Change vendor-supplied default passwords before deployment
```

---

## 3. Business Continuity for OT

### RTO/RPO for Control Systems
```
Define per zone (typical targets):
  Level 0-1 (Field/Control):
    RTO: 0-4 hours (process safety dependent; may need manual operation)
    RPO: Last known-good configuration backup

  Level 2 (Supervisory/HMI):
    RTO: 4-8 hours (operators can run on manual with Level 1)
    RPO: Configuration backup + historian data from last checkpoint

  Level 3 (Operations/Historian):
    RTO: 8-24 hours
    RPO: Last successful backup (daily minimum)

  Level 3.5 DMZ:
    RTO: 2-4 hours (critical for remote access recovery)
    RPO: Configuration + user accounts

Manual operation procedures:
  CRITICAL: All OT systems must have documented manual operation procedures
  Assumes: all SCADA/HMI systems completely unavailable
  Operators must be trained annually on manual operation
```

### PLC/HMI Configuration Backups
```
Backup requirements:
  Frequency: After every change (change control mandated); monthly minimum
  Format: Vendor-specific project file (STEP 7 .s7p, RSLogix .ACD, TIA Portal .zap)
  Verification: Hash backup immediately after creation; verify hash quarterly
  Storage: Offline storage (USB/removable media), physically separate from OT network
  Access: Controlled access; stored in secure location
  Retention: Last 5 versions minimum; archive 3 years

Backup procedure for Siemens S7-1500 (example):
  1. TIA Portal: Download project from PLC (Online > Device > Backup)
  2. Save to offline workstation
  3. sha256sum <project.zap> > project_hash.txt
  4. Transfer to secure offline storage with evidence number

Spare parts inventory:
  Maintain critical spares: spare PLC CPU, spare HMI server, critical I/O modules
  Spare inventory review: annual; update after hardware changes
  Supplier contracts: maintain support contract for critical components
```

---

## 4. Patch Management for OT

### OT Patch Challenges
```
Constraints:
  - Vendor approval required before applying patches (some patches void warranty)
  - Testing in replica environment required (cannot test on live production)
  - Maintenance window requirement (patch during planned production shutdown)
  - Legacy systems: no patches available (EOL/EOS)
  - Long patch cycles: semi-annual or annual production shutdowns may be the only window

Compensating controls for unpatched systems:
  1. Network isolation (no unnecessary connectivity)
  2. Application whitelisting (TXOne, Claroty Edge, Trellix)
  3. Virtual patching (IDS/IPS rule to block exploit traffic)
  4. Enhanced monitoring (alert on exploit attempt indicators)
  5. Documented risk acceptance by OT/plant management
```

### OT Patch Management Process
```
Step 1: Advisory received (ICS-CERT or vendor)
Step 2: Check asset register — is affected product installed?
Step 3: If yes: assess severity with OT context
Step 4: Contact vendor: is patch available? Is it approved for your version?
Step 5: Test in replica environment (mirror of production system)
Step 6: Schedule maintenance window; notify operations management
Step 7: Apply patch during window with engineer on-site
Step 8: Verify: test process functionality after patching
Step 9: Update asset register (patch version, date applied)
Step 10: If unable to patch: document compensating controls and risk acceptance
```

---

## 5. Resilience Checklist

- [ ] ISA/IEC 62443 SL-T assigned to each zone
- [ ] Current SL-C assessed; gaps to SL-T documented
- [ ] NERC CIP BES Cyber System categorisation completed (if applicable)
- [ ] CIP-002 categorisation documentation complete (High/Medium/Low)
- [ ] CIP-007 ports and services documented and reviewed
- [ ] CIP-007 patch tracking log current (within 35 days of advisories)
- [ ] CIP-007 security event monitoring configured and alert SLA met
- [ ] Manual operation procedures documented and operator-trained
- [ ] PLC/HMI configuration backups taken, hashed, and stored offline
- [ ] Spare parts inventory documented and physically held
- [ ] Backup restoration tested (annual minimum for critical systems)
- [ ] Patch management procedure documented with vendor approval workflow
- [ ] Compensating controls documented for all unpatched systems
- [ ] CIP-008 incident response plan current and tested (tabletop annually)
- [ ] CIP-009 recovery plan current and tested



## ics-protocol-security

# ICS Protocol Security

## Purpose
Assess and harden the industrial protocols that carry control traffic between field devices, controllers, and supervisory systems. These protocols were designed for reliability on isolated networks and mostly lack authentication, integrity, or encryption — making protocol-aware attacks the core of ICS threat modelling under MITRE ATT&CK for ICS.

---

## 1. Industrial Protocol Threat Matrix

| Protocol | Transport | Auth | Encryption | Primary Attack | ATT&CK for ICS |
|----------|-----------|------|-----------|----------------|----------------|
| Modbus TCP | TCP/502 | None | None | Unauthorised command write to coils/registers | T0855 Unauthorized Command Message |
| DNP3 | TCP/UDP 20000 | Optional (SAv5) | None (native) | Spoofed control, replay, outstation flooding | T0856 Spoof Reporting Message |
| Siemens S7comm / S7comm-plus | TCP/102 (ISO-TSAP) | Weak (S7comm), token (plus) | None / weak | PLC stop/start, program upload/download | T0843 Program Download |
| EtherNet/IP (CIP) | TCP/UDP 44818, 2222 | None | None | Forward-open flooding, tag manipulation | T0855 |
| OPC-UA | TCP/4840 | Cert/user (if enabled) | TLS (if enabled) | Downgrade to None security policy, cert bypass | T0885 Commonly Used Port |
| IEC 61850 MMS/GOOSE | TCP/102, L2 GOOSE | None (GOOSE) | None | GOOSE spoofing → false trip of protection relays | T0832 Manipulation of View |
| PROFINET | L2 Ethernet | None | None | DCP device reset, real-time frame injection | T0814 Denial of Service |
| BACnet | UDP/47808 | None | None | Write-property to building controllers | T0855 |

---

## 2. Modbus Security Assessment

### Passive Identification (safe on live networks)
```
Passive Modbus discovery via SPAN/TAP — never active-scan live OT:
  - Capture TCP/502 with Zeek + ICSNPP-Modbus parser or Wireshark modbus dissector
  - Enumerate function codes in use:
      FC01/02  Read Coils / Discrete Inputs
      FC03/04  Read Holding / Input Registers
      FC05/06  Write Single Coil / Register    ← state-changing
      FC15/16  Write Multiple Coils / Registers ← state-changing
      FC08     Diagnostics                      ← can force listen-only / restart
  - Map unit IDs (slave addresses) to physical devices
```

### Risk Findings
| Finding | Risk | Remediation |
|---------|------|-------------|
| Write function codes (05/06/15/16) reachable from supervisory or IT zone | Attacker can actuate process (open valve, trip breaker) | Restrict writes to control zone; deploy Modbus-aware firewall (deep-packet function-code filtering) |
| No function-code filtering at conduit | Any client can issue any command | Whitelist read-only FCs across zone boundaries |
| Modbus over routable network to Level 0/1 | Direct field-device exposure | Terminate Modbus at a data-diode-fronted gateway |

---

## 3. DNP3 Hardening (Electric / Water Utilities)

```
DNP3 Secure Authentication (SAv5 / IEEE 1815-2012):
  - Enable challenge-response HMAC on critical control operations (SBO — Select Before Operate)
  - Rotate update keys; store in HSM where the outstation supports it
  - Enforce SBO for all direct-operate control points (Group 12 CROB)

DNP3 attack signatures to alert on (Zeek ICSNPP-DNP3):
  - Unsolicited responses from an outstation that was not configured for them
  - Cold restart (FC 13) / warm restart (FC 14) from an unexpected master
  - Disable unsolicited (FC 21) followed by control — hides operator view (T0856)
```

---

## 4. Siemens S7 / PROFINET

```
S7comm PLC protection:
  - Set PLC protection level 3 (write + read protection) in TIA Portal / STEP 7
  - Enable "know-how protection" and copy protection on program blocks
  - Disable the web server and OPC-UA server on the CPU if unused
  - Block TCP/102 across all conduits except the engineering-workstation conduit

TRITON/Stuxnet-class indicators:
  - Unexpected program download (T0843) outside a change window
  - Firmware version mismatch between running CPU and golden baseline
  - CPU mode change to STOP (T0813 Denial of Control) not tied to an operator action
```

---

## 5. OPC-UA Secure Configuration

```
OPC-UA is the modern, securable protocol — but ships insecure by default:
  [ ] Reject SecurityPolicy = None; require Basic256Sha256 or Aes256Sha256RsaPss
  [ ] Require application-instance certificates; disable "trust all"
  [ ] Enable user authentication (X.509 or username) — never Anonymous on control servers
  [ ] Turn off the discovery endpoint's anonymous session
  [ ] Monitor for downgrade attempts (client requesting None after negotiating signed)
```

---

## 6. Protocol-Aware Monitoring

| Sensor | Coverage | Deployment |
|--------|----------|-----------|
| Zeek + ICSNPP parsers | Modbus, DNP3, S7comm, EtherNet/IP, BACnet, PROFINET | SPAN/TAP at each zone conduit — passive only |
| Nozomi / Claroty / Dragos | Asset + protocol baseline, anomaly on new command | Passive collectors per Purdue level |
| Snort/Suricata ICS rulesets | Known exploit signatures (Talos ICS category) | Inline at IT/OT DMZ only, passive in OT |

**Golden rule:** all OT protocol assessment is **passive** (SPAN/TAP capture) unless an active test is explicitly change-controlled inside a maintenance window with the process in a safe state.

---

## 7. ATT&CK for ICS Technique Coverage

T0800 T0801 T0802 T0803 T0804 T0806 T0807 T0809 T0811 T0813 T0814 T0815
T0820 T0826 T0827 T0831 T0832 T0835 T0836 T0839 T0843 T0845 T0846 T0855
T0856 T0857 T0858 T0859 T0860 T0861 T0866 T0868 T0885 T0886 T0889



## safety-instrumented-systems

# Safety Instrumented Systems (SIS) Security

## Purpose
Protect the Safety Instrumented Systems that bring a process to a safe state when limits are exceeded. SIS is the last line of defence against physical harm — a compromised SIS (as in the TRITON/TRISIS attack on a Triconex controller) can disable safety functions while the process runs, risking loss of life. Security controls here must never degrade the safety function itself.

---

## 1. SIS Fundamentals

| Concept | Definition |
|---------|-----------|
| SIF (Safety Instrumented Function) | A single function that detects a hazard and moves the process to a safe state (e.g., close feed valve on high pressure) |
| SIL (Safety Integrity Level) | 1–4; probability the SIF performs on demand. SIL 3 = 99.9–99.99% availability |
| SIS | The engineered system (sensors + logic solver + final elements) implementing the SIFs |
| Logic Solver | Safety PLC (Triconex, HIMA, Siemens S7 F-series, Rockwell GuardLogix) |
| Safe State | The condition the process is driven to (usually de-energised / shut down) |

**IEC 61511** governs functional safety for the process industry; **IEC 62443** governs the security of the same systems. Security failures are now recognised as a cause of safety failures.

---

## 2. SIS Threat Model

| Threat | Impact | ATT&CK for ICS |
|--------|--------|----------------|
| Reprogram safety logic solver | Safety function silently disabled | T0843 Program Download, T0889 Modify Program |
| Force SIS into program/maintenance mode | SIFs bypassed during "engineering" | T0858 Change Operating Mode |
| Manipulate safety setpoints | Trip points moved outside safe envelope | T0836 Modify Parameter |
| Spoof sensor input to logic solver | SIS never sees the hazard | T0856 Spoof Reporting Message |
| Disable annunciation to operators | Hazard hidden from the control room | T0832 Manipulation of View |
| TRITON-style RAT on engineering workstation | Persistent access to reprogram Triconex | T0866 Exploitation of Remote Services |

### TRITON / TRISIS Case Reference
The 2017 TRITON attack targeted Schneider Triconex SIS controllers via a compromised Windows engineering workstation, using the proprietary TriStation protocol (UDP/1502) to inject a payload into the safety controller. Detection cues: unexpected TriStation traffic, controller keyswitch left in PROGRAM, firmware/logic checksum drift from baseline.

---

## 3. SIS Security Controls (Without Compromising Safety)

```
Architectural isolation:
  [ ] SIS on a dedicated safety zone (Purdue Level 1) — physically or logically
      separated from the Basic Process Control System (BPCS)
  [ ] No routable path from IT or supervisory zones to the logic solver
  [ ] Engineering access to SIS only from a dedicated, hardened, offline-capable
      Safety Engineering Workstation (SEWS) — never a shared IT laptop

Keyswitch and mode discipline:
  [ ] Physical keyswitch on the logic solver kept in RUN; PROGRAM only during
      change-controlled maintenance, key held by the safety authority
  [ ] Alert on any electronic mode change (T0858) not paired with a work order

Integrity monitoring:
  [ ] Golden baseline of safety logic + firmware checksums; compare weekly
  [ ] Passive monitor for the SIS engineering protocol (TriStation/UDP 1502,
      HIMA, etc.) — any occurrence outside a window is an incident
  [ ] Change-detection alert on setpoint / parameter writes (T0836)
```

**Never** apply security controls that add latency or failure modes to the safety loop itself. Security monitoring is passive and out-of-band; it must not sit inline in the SIF signal path.

---

## 4. SIS Incident Response (Safety-First)

```
If SIS compromise is suspected, the process safety authority leads — not IT security.

CONTAIN (without creating a hazard):
  1. Do NOT power-cycle or "clean" the logic solver — this may drop the safety function
  2. Verify the SIS is still performing its SIFs (independent proof test if needed)
  3. Move keyswitch to RUN; revoke engineering-workstation access
  4. Isolate the engineering workstation (the usual entry point), not the SIS

INVESTIGATE:
  5. Capture logic-solver program + firmware; diff against golden baseline
  6. Pull engineering-workstation forensic image (TRITON persisted here)
  7. Review SIS engineering-protocol captures for unauthorised sessions

RECOVER:
  8. Restore verified-good safety logic during a planned shutdown / safe state
  9. Independent SIL verification / proof test before returning SIF to service
  10. Root-cause the IT→OT→SIS path; close the conduit that allowed reach
```

---

## 5. Compliance and Verification

| Requirement | Standard | Evidence |
|-------------|----------|----------|
| Independence of SIS from BPCS | IEC 61511 | Architecture drawing showing separation |
| Security risk assessment of the SIS | IEC 62443-3-2 | Zone/conduit model with SIS as its own SL-4 zone |
| Access control to safety logic | IEC 62443-3-3 SR 1.1 | Named accounts, keyswitch procedure, access logs |
| Change management for safety logic | IEC 61511 MOC | Signed management-of-change records |
| Proof testing after any change | IEC 61511 | Proof-test records with SIL verification |

---

## 6. ATT&CK for ICS Technique Coverage

T0800 T0803 T0813 T0816 T0832 T0835 T0836 T0839 T0843 T0855 T0856 T0857
T0858 T0859 T0866 T0868 T0872 T0873 T0880 T0881 T0889