Industrial Control Systems

Key Control Areas

• Network Segmentation and Boundary Protection (SC-07, AC-04; IEC 62443-3-3 SR 5.1, SR 5.2, SR 5.3): Boundary protection is the foundational architectural control for ICS environments, and the core of the IEC 62443 zones and conduits model. Implement network segmentation following the Purdue Enterprise Reference Architecture (ISA-95/IEC 62443) with industrial-aware firewalls between IT and OT zones. SR 5.1 (Network Segmentation) requires logical separation of control system networks into zones based on criticality and function, with physical segmentation (SR 5.1 RE 1) for the highest security levels. The DMZ between enterprise and process control networks should host historian servers, jump servers, and data replication services -- never allow direct connectivity from corporate networks to control system components. SR 5.2 (Zone Boundary Protection) mandates deny-by-default, allow-by-exception (RE 1) with fail-close behaviour (RE 3) at zone boundaries. Deploy data diodes for unidirectional data flows where the process network only needs to send telemetry outbound. SR 5.3 restricts general-purpose person-to-person communications within the control system network. Boundary protection extends to microsegmentation within the OT network to limit lateral movement between control system zones.
• Access Control and Least Privilege (AC-03, AC-06, AC-17, AC-18; IEC 62443-3-3 SR 1.1, SR 1.13, SR 2.1, SR 2.2): Access enforcement in ICS must account for both logical and physical access paths. SR 1.1 (Human User Identification and Authentication) requires unique identification with multi-factor authentication for access via untrusted networks (RE 2) and all networks at higher security levels (RE 3). SR 2.1 (Authorization Enforcement) mandates role-based access control on all HMI and engineering workstations, with least privilege ensuring that operators cannot modify controller configurations and engineers cannot bypass safety systems without authorised change procedures. Dual approval (SR 2.1 RE 4) should be enforced for safety-critical configuration changes. Remote access via SR 1.13 (Access via Untrusted Networks) is particularly critical -- vendor remote maintenance sessions should use dedicated jump servers in the DMZ with multi-factor authentication, session recording, and time-limited access windows with explicit access request approval (RE 1). SR 1.6 and SR 2.2 (Wireless Access Management and Use Control) require tight control in OT environments; rogue wireless access points in a plant environment can bypass all network segmentation. Disable all unnecessary wireless capabilities on ICS components and conduct regular wireless surveys of facility perimeters.
• Configuration and Change Management (CM-02, CM-03, CM-05, CM-07, CM-08; IEC 62443-3-3 SR 7.6, SR 7.7, SR 7.8): ICS environments require rigorous configuration management because unauthorised changes to controller logic or HMI configurations can have immediate physical consequences. SR 7.6 (Network and Security Configuration Settings) requires documented baseline configurations for all PLCs, RTUs, DCS controllers, HMIs, and engineering workstations -- including firmware versions, ladder logic programs, setpoint values, and network configurations, with machine-readable reporting (RE 1) at higher security levels. All changes must go through formal change control (CM-03) with OT engineering review, safety impact assessment, and rollback procedures tested before implementation. Access restrictions for change (CM-05) should ensure only authorised engineers can modify controller programs, and all modifications should be logged and auditable. SR 7.7 (Least Functionality) means removing unnecessary services, protocols, and software from ICS components -- disable unused communication ports, remove web servers from PLCs where not required, and restrict engineering software installation to designated workstations. SR 7.8 (Control System Component Inventory) requires maintaining a complete inventory of all ICS hardware and software assets, essential for vulnerability management and incident response in environments where undiscovered devices are a common finding.
• Physical Security of Control Infrastructure (PE-03, PE-04, PE-06): Physical access control for ICS goes beyond server room locks. Control equipment is frequently distributed across large geographic areas -- substations, pump stations, remote sites -- each requiring proportionate physical protection. Implement layered physical access using fencing, locked cabinets, and access logging at unmanned facilities. Access control for transmission medium (PE-04) protects the cabling and wireless infrastructure connecting control systems; cable runs between buildings should be in secured conduit, and fibre optic connections should be used where electromagnetic interference or tapping is a concern. Physical access monitoring (PE-06) at remote sites should include tamper detection on control cabinets, CCTV with remote viewing capability, and intrusion detection systems that alert the control centre when facility access occurs outside normal maintenance windows.
• Vulnerability and Patch Management (RA-05, SI-02, SI-05): Vulnerability management in ICS is fundamentally different from IT. Many ICS components cannot be patched without vendor qualification testing, scheduled maintenance windows may be months apart, and applying patches to running process control systems carries inherent risk. Vulnerability scanning (RA-05) must use ICS-aware tools that understand industrial protocols and will not crash sensitive controllers -- never run standard IT vulnerability scanners against production OT networks. Flaw remediation (SI-02) requires a risk-based approach: prioritise vulnerabilities that are remotely exploitable and affect components in higher Purdue levels first, use compensating controls (network segmentation, monitoring) for vulnerabilities that cannot be immediately patched, and coordinate all patching with OT engineering and production scheduling. Security alerts and advisories (SI-05) should include ICS-CERT advisories, vendor-specific notifications, and sector-specific threat intelligence feeds.
• Incident Response for Cyber-Physical Systems (IR-02, IR-04, IR-05, IR-07): ICS incident response requires specialised capabilities beyond standard IT IR. Incident response training (IR-02) must include OT-specific scenarios -- responding to a compromised PLC, identifying manipulated process setpoints, and safely isolating control systems without causing process upsets. Incident handling (IR-04) procedures must account for the physical consequences of containment actions: disconnecting a compromised controller may cause a process to enter an unsafe state. Develop response playbooks for ICS-specific scenarios in collaboration with process engineers and safety personnel. Incident monitoring (IR-05) should correlate IT and OT security events to identify attacks that traverse the IT/OT boundary. Incident response assistance (IR-07) should include pre-established relationships with ICS-CERT, sector ISACs, ICS forensics specialists, and the control system vendor's security response team.
• System Integrity and Malicious Code Protection (SI-03, SI-07, SI-10; IEC 62443-3-3 SR 3.2, SR 3.4, SR 3.5): ICS-targeted malware represents an existential threat to industrial operations. SR 3.2 (Malicious Code Protection) must account for the reality that traditional antivirus is often impractical on ICS endpoints -- compensating controls include application whitelisting, removable media scanning stations, and network-based malware detection at zone boundaries. SR 3.4 (Software and Information Integrity) requires mechanisms to detect unauthorised changes to controller firmware, ladder logic, and HMI configurations with automated notification (RE 1) when integrity violations occur. SR 3.5 (Input Validation) is critical for systems that accept commands via industrial protocols -- Modbus, DNP3, and OPC Classic were designed without authentication, making input validation at protocol gateways essential. Deterministic output (SR 3.6) ensures control systems produce predictable outputs even under degraded conditions, a safety-critical property unique to OT environments.
• Continuous Monitoring and Audit (AU-02, CA-02, CA-07; IEC 62443-3-3 SR 2.8, SR 6.1, SR 6.2): Monitoring in ICS environments must cover both cybersecurity events and process anomalies that may indicate compromise. SR 2.8 (Auditable Events) should include authentication attempts on HMIs and engineering workstations, controller configuration changes, firmware uploads, new device connections to the OT network, and unusual process variable changes, with centralised audit trails (RE 1) at higher security levels. SR 6.2 (Continuous Monitoring) should deploy ICS-aware network monitoring tools that perform deep packet inspection of industrial protocols (Modbus, DNP3, EtherNet/IP, OPC UA) to detect anomalous commands or configuration changes. Passive monitoring is preferred over active scanning in production OT networks. SR 6.1 (Audit Log Accessibility) with programmatic access (RE 1) enables automated correlation of IT and OT security events. Security assessments (CA-02) should include regular penetration testing of the IT/OT boundary and tabletop exercises involving both cybersecurity and OT engineering teams.
• Backup, Recovery, and Resilience (CP-09, CP-10; IEC 62443-3-3 SR 7.1, SR 7.3, SR 7.4): ICS resilience requires capabilities beyond standard IT disaster recovery. SR 7.3 (Control System Backup) must cover not just data but controller configurations, ladder logic programs, HMI screens, historian databases, and network device configurations, with backup verification (RE 1) and automation (RE 2). SR 7.4 (Control System Recovery and Reconstitution) must account for the physical consequences of recovery -- restoring a controller to a previous configuration while a process is running requires coordination with operations to prevent unsafe conditions. SR 7.1 (Denial of Service Protection) is critical because availability is the paramount concern in OT; even brief communication disruptions can cause process upsets, and ICS protocols have minimal built-in DoS resistance. Recovery procedures must be tested during maintenance windows with OT engineering oversight, and recovery time objectives must align with process safety requirements.

When to Use

Any commercial or government organisation operating industrial automation equipment should implement this pattern. Typical applications include process control for production lines, energy generation and distribution (power plants, substations, smart grid), oil and gas (upstream, midstream, downstream), water and wastewater treatment, transportation infrastructure (rail signalling, traffic management, aviation), manufacturing, healthcare (building management, medical gas systems), shipping and port operations, mining, and emergency services. This pattern should apply in the majority of cases given the cost of securing versus the cost of equipment and the impact from process downtime or safety incidents. Regulatory drivers include NERC CIP for energy, TSA Security Directives for pipeline operations, NIS2 Directive for essential services in Europe, and sector-specific regulations for nuclear, water, and chemical facilities.

When NOT to Use

This pattern may be inappropriate where the automated process has genuinely low impact if it operates outside specified tolerance levels, there are very low availability requirements, and there is verified certainty that the system is isolated with strong logical and physical access controls. First-generation panel-based equipment with no network connectivity and no use of commercial off-the-shelf software typically falls outside the scope of this pattern. However, the threshold for applying this pattern should be low -- even seemingly low-impact processes may have upstream or downstream dependencies that amplify the consequences of compromise, and air-gapped claims should be rigorously verified as true isolation is increasingly rare.

Typical Challenges

The most persistent challenge is the shortage of personnel with expertise spanning both cybersecurity and OT engineering -- ICS security requires understanding of industrial protocols, process safety, control theory, and cybersecurity principles simultaneously. Legacy ICS equipment often runs end-of-life operating systems (Windows XP, Windows Server 2003) and proprietary firmware that cannot be patched or upgraded without replacing hardware, creating permanent vulnerability exposure that must be mitigated through compensating controls. It can be difficult to distinguish system failures from behaviour under attack, making baseline behaviour profiling essential -- organisations must invest in OT network monitoring tools that can establish normal traffic patterns and alert on deviations. Vendor dependency is significant: many ICS components have restrictive licensing that prohibits installing third-party security software or modifying system configurations, and patching often requires vendor certification that lags months behind vulnerability disclosure. The cultural divide between IT and OT teams creates organisational friction -- OT engineers may view cybersecurity controls as threats to system availability, while IT security teams may not understand the safety implications of their recommended controls. Budget justification is challenging because ICS security investments protect against low-frequency, high-impact events where the return on investment is difficult to quantify until an incident occurs.

Threat Resistance

This pattern addresses threats specific to the ICS/OT domain. Malicious code targeting industrial systems, including Stuxnet-class attacks that manipulate controller logic while displaying normal values to operators, and ransomware variants like EKANS/Snake specifically designed to kill ICS processes before encrypting systems. Compromise of process integrity through manipulation of setpoints, safety system bypasses, or injection of rogue commands via industrial protocols. Denial of service attacks against control networks that disrupt real-time process control communications. Man-in-the-middle attacks on unencrypted industrial protocols (Modbus TCP, DNP3) allowing command injection or telemetry manipulation. Insider threats from employees or third-party maintenance personnel with physical access to control equipment. Supply chain compromise through tampered firmware updates, counterfeit components, or compromised vendor remote access. Unauthorised wireless access through rogue access points deployed within the OT network perimeter. Reconnaissance and lateral movement from compromised IT networks into OT zones through inadequately segmented network architectures.

Assumptions

The organisation operates industrial automation equipment that uses standard networking technologies (TCP/IP over Ethernet) and has some degree of connectivity to the corporate IT network for management information and remote monitoring. Attacks on ICS enable real-world physical actions and are increasingly used by state-sponsored actors, criminal groups, and hacktivists to impact critical infrastructure. The knowledge and tools to attack ICS are becoming commoditised, with frameworks like Metasploit including ICS-specific modules. Financial motives for ICS attacks are growing due to the potential for extortion against high-value industrial processes. Management and monitoring of OT systems is increasingly provided by third-party vendors who supply equipment and supporting services, introducing additional supply chain risk.

Developing Areas

• State-sponsored pre-positioning in critical infrastructure OT networks represents the most significant strategic threat to ICS environments. Groups like Volt Typhoon have been documented maintaining persistent access to US critical infrastructure for years without conducting disruptive operations, positioning for potential activation during geopolitical conflict. Detecting this activity is extraordinarily difficult because the adversaries deliberately use living-off-the-land techniques that blend with normal administrative operations, and most OT environments lack the behavioural baseline monitoring needed to identify subtle anomalies over extended timeframes.
• IT/OT convergence security is accelerating as industrial organisations adopt cloud-connected IoT sensors, edge computing, and digital twin technologies, but the security architecture for converged environments remains immature. Traditional Purdue model segmentation assumes clear boundaries between IT and OT zones, yet modern IIoT deployments create data flows that bypass these boundaries entirely -- sensor data streaming directly to cloud analytics platforms, remote maintenance via vendor cloud portals, and AI-driven process optimisation that requires bidirectional communication. Emerging reference architectures from ISA/IEC 62443 and NIST are adapting but lagging behind deployment reality.
• OT asset visibility and inventory remains a fundamental gap in most industrial environments. Surveys consistently find that organisations are unaware of 20-40% of the devices connected to their OT networks, including legacy PLCs, unmanaged switches, and vendor-installed remote access devices. Passive network discovery tools have improved significantly, but many ICS protocols do not support passive identification, and active scanning of production OT networks remains risky due to the fragility of legacy controllers.
• ICS-specific detection and response capabilities are maturing rapidly but still require specialised expertise that is in critically short supply. Fewer than 5,000 professionals globally hold both OT engineering and cybersecurity qualifications sufficient to perform ICS incident response. Tools like Dragos and Claroty provide OT-aware detection, but interpreting alerts in the context of physical process behaviour requires domain knowledge that cannot be automated, and the consequence of a wrong containment decision in OT can be physical damage or safety incidents.
• Remote OT access security has become a permanent architectural concern since the pandemic normalised remote maintenance of industrial systems. Vendor remote access to PLCs and DCS systems, which was previously tightly controlled through on-site visits, is now routinely provided via cloud-based remote access platforms with varying security postures. Standardised approaches to secure remote OT access -- including jump server architectures, session recording, just-in-time access provisioning, and MFA for industrial remote sessions -- are emerging but adoption is inconsistent, particularly among smaller equipment vendors.