Security & Risks
Chapter 6 — Threat landscape analysis, risk assessment methodology, attack vectors, and mitigation strategies for OT/IT network segmentation
6.1 OT Threat Landscape
The threat landscape facing industrial OT networks has evolved dramatically over the past decade. What was once a domain of isolated, proprietary systems with limited connectivity has become a target of sophisticated nation-state actors, ransomware groups, and opportunistic attackers. The convergence of OT and IT networks, driven by the need for operational data integration and remote management, has dramatically expanded the attack surface. Understanding the full threat landscape is the first step in designing an effective segmentation architecture.
Figure 6.1: OT Cybersecurity Threat Landscape — Four threat categories (External, Internal, IT-OT Boundary, Physical) with attack vectors and paths targeting the Industrial Control System hub. Color-coded by threat category: red (external), orange (internal), yellow (IT-OT boundary), purple (physical).
| Threat Category | Attack Vector | Likelihood | Impact | Primary Mitigation |
|---|---|---|---|---|
| External — APT | Spear phishing → IT network → lateral movement to OT | Medium | Critical | IT-OT segmentation, DMZ, no direct IT-OT path |
| External — Ransomware | IT network compromise → OT historian/SCADA encryption | High | High | OT network isolation, offline backups, incident response plan |
| External — Supply Chain | Compromised vendor software/firmware update | Medium | High | File transfer gateway with AV scan, vendor access control |
| Internal — Insider | Authorized user abusing access to modify setpoints | Low-Medium | High | PAM/Bastion, session recording, command whitelist |
| Internal — Misconfiguration | Firewall rule error creating unintended path | Medium | Medium-High | Change management, firewall rule review, automated compliance check |
| IT-OT Boundary — Lateral Movement | Compromised DMZ host used to pivot to OT Core | Medium | Critical | DMZ host hardening, micro-segmentation, IDS on OT side |
| IT-OT Boundary — Protocol Exploitation | Malformed OT protocol packets bypassing DPI | Low | High | DPI with protocol validation, firmware updates on DPI engine |
| Physical — Rogue Device | Unauthorized device connected to OT switch port | Low-Medium | High | 802.1X port authentication, MAC address whitelisting, port security |
6.2 Risk Assessment Methodology
Risk assessment for OT/IT segmentation projects must adapt standard IT risk methodologies to account for the unique characteristics of OT environments: the primacy of availability over confidentiality, the presence of safety-critical functions, and the long lifecycle of OT equipment. The recommended approach combines the IEC 62443 security level framework with a consequence-based risk assessment that explicitly accounts for physical process impacts.
| Risk Level | Likelihood × Impact | OT Consequence Examples | Required Response | IEC 62443 SL Target |
|---|---|---|---|---|
| Critical | High × Critical | Safety system compromise, explosion, grid blackout | Immediate remediation; escalate to CISO and plant manager | SL 3–4 |
| High | High × High or Medium × Critical | Production shutdown, product quality failure, data breach | Remediate within 30 days; assign owner | SL 2–3 |
| Medium | Medium × Medium or Low × High | Partial production impact, unauthorized monitoring | Remediate within 90 days; track in risk register | SL 2 |
| Low | Low × Low or Low × Medium | Minor operational disruption, non-critical data exposure | Accept or remediate within 180 days | SL 1 |
6.3 Common Design Vulnerabilities and Mitigations
Many OT/IT segmentation implementations contain design vulnerabilities that undermine the intended security posture. These vulnerabilities often arise from operational convenience requirements that were not properly balanced against security requirements during the design phase. The following table documents the most frequently observed design vulnerabilities and their recommended mitigations.
| Vulnerability | Description | Detection Method | Mitigation |
|---|---|---|---|
| Direct IT-OT Path | A firewall rule or routing entry allows direct traffic between IT and OT zones, bypassing the DMZ | Firewall rule audit, penetration test | Remove direct rules; enforce all traffic through DMZ services |
| Overly Permissive DMZ Rules | DMZ firewall rules allow broad IP ranges or protocols instead of specific hosts and ports | Firewall rule review, traffic analysis | Implement least-privilege rules; review all rules quarterly |
| Shared Credentials | Multiple users share a single account for OT system access, preventing individual accountability | User account audit | Individual accounts with MFA; PAM for privileged access |
| Unencrypted Management | Firewall or switch management uses Telnet, HTTP, or SNMPv1/v2 instead of encrypted protocols | Protocol scan, configuration review | Enforce SSH, HTTPS, SNMPv3 for all management; disable legacy protocols |
| Unsecured USB Ports | USB ports on OT workstations or servers are enabled and unmonitored, allowing unauthorized media | Endpoint configuration audit | Disable unused USB ports; use USB write blockers; log all USB events |
| Missing OT IDS Coverage | No passive monitoring on OT network segments, making anomalous behavior invisible | Network architecture review | Deploy passive OT IDS sensors on all critical OT segments |
| Unpatched DMZ Systems | DMZ servers and appliances are not included in the patch management process | Vulnerability scan, patch status audit | Include DMZ systems in patch management; test patches in staging |
6.4 Incident Response for OT Environments
OT incident response requires a fundamentally different approach from IT incident response. The primary constraint is that containment actions (such as isolating a compromised system) may have direct physical process consequences. The incident response plan must define the decision authority for containment actions and must include pre-approved isolation procedures that can be executed without disrupting safety-critical functions.
| IR Phase | OT-Specific Considerations | Decision Authority | Target Timeframe |
|---|---|---|---|
| Detection | OT IDS alerts, historian anomalies, operator reports of unexpected behavior | OT Security Team | <15 minutes from alert |
| Triage | Assess process impact of potential containment; consult process engineer | OT Security + Process Engineer | <30 minutes |
| Containment | Isolate affected zone without disrupting safety systems; use pre-approved isolation runbooks | Plant Manager + CISO | <60 minutes |
| Eradication | Remove malware from OT systems using validated, offline tools; restore from known-good backups | OT Security Team + Vendor | Hours to days |
| Recovery | Restore OT systems in controlled sequence; validate process behavior before resuming production | Plant Manager + OT Engineering | Days to weeks |
| Post-Incident | Root cause analysis; update firewall rules, IDS signatures, and runbooks; regulatory notification if required | CISO + Compliance | Within 30 days |