Industrial Control System (ICS) Network Security
ICS network security protects industrial control systems through Purdue Model zoning, protocol-aware firewalls, data diodes, and OT-specific monitoring for critical infrastructure.
Continue your mission
ICS network security protects industrial control systems through Purdue Model zoning, protocol-aware firewalls, data diodes, and OT-specific monitoring for critical infrastructure.
# Industrial Control System (ICS) Network Security
Industrial Control System (ICS) network security protects the communication infrastructure connecting supervisory control and data acquisition (SCADA) systems, programmable logic controllers (PLCs), remote terminal units (RTUs), and human-machine interfaces (HMIs) in critical infrastructure environments. These environments include electric utilities, water treatment facilities, oil and gas pipelines, chemical plants, and manufacturing operations where network-delivered commands translate directly into physical actions.
The discipline exists because traditional IT security controls were designed for data confidentiality and cannot account for the safety, availability, and real-time determinism requirements of industrial operations. A misconfigured firewall rule in an enterprise network causes a service ticket; the same error on an OT network can shut down a power grid or release toxic chemicals. ICS network security reconciles operational requirements with adversarial realities in environments where patching is difficult, equipment lifecycles span decades, and availability is non-negotiable.
ICS network security is distinct from general OT security, which encompasses endpoint hardening, vulnerability management, and physical security. It specifically addresses network-layer controls and communications pathways between industrial devices. It is also distinct from IT network security in its prioritization: where IT security follows the CIA triad (confidentiality, integrity, availability), ICS security inverts that ordering. Availability and integrity of process data come first, with confidentiality as a secondary concern. A security control that blocks legitimate process traffic to prevent data exfiltration is unacceptable in most ICS contexts.
ICS network security is implemented through a layered architecture, with each layer addressing different threat classes while avoiding disruption to process operations. The foundation is zone segmentation based on the Purdue Reference Model, which divides industrial environments into hierarchical zones with strict boundary controls.
The Purdue Reference Model provides the architectural framework for ICS network segmentation. Level 0 covers physical processes: sensors, actuators, and field devices. Level 1 covers basic control: PLCs and RTUs that issue commands to field devices. Level 2 covers supervisory control: SCADA servers and HMIs that monitor and direct Level 1 systems. Level 3 covers site operations: historians, engineering workstations, and site-level management systems. Levels 4 and 5 cover enterprise IT and external networks.
Security controls enforce strict boundaries between these zones. Traffic between Level 3 and Level 4 passes through a demilitarized zone (DMZ) containing one-way replication servers, data historians, and application proxies. No direct connection between an enterprise workstation and a PLC should exist. When defenders find direct connections, they represent critical findings requiring immediate remediation. Each zone boundary acts as a chokepoint where traffic can be inspected, filtered, and logged without impacting intra-zone communications.
Standard stateful firewalls cannot interpret industrial protocols. A firewall that only understands TCP/IP will allow any Modbus TCP packet on port 502 regardless of whether that packet contains a legitimate read command or a coil write that changes a valve position. Industrial protocol-aware firewalls understand the function code structures of Modbus, DNP3, EtherNet/IP, OPC UA, IEC 61850, and PROFINET.
These tools enforce rules at the protocol level, blocking unauthorized function codes, restricting which devices can issue write commands, and alerting when engineering-only operations occur during production hours. For example, in a water treatment facility, a Modbus-aware firewall can permit read operations (function codes 01-04) from the historian to any PLC while blocking all write operations (function codes 05-06, 15-16) from every source except the designated engineering workstation during defined maintenance windows. This single rule eliminates an entire class of attack where adversaries with historian access attempt to issue pump commands.
Where one-way data flow is sufficient, data diodes replace firewalls entirely. A data diode is a hardware device with a transmitting optical component on one side and a receiving optical component on the other, with no physical return path. Data can flow from the OT network to the IT network for historian replication, dashboards, and reporting, but no packet, command, or response can travel in the reverse direction.
This provides a physical guarantee that no IT-side compromise can reach the OT network through that pathway. Nuclear facilities, electric utilities, and chemical plants commonly deploy data diodes on historian replication paths. The trade-off is functionality: data diodes eliminate bidirectional protocols like OPC UA browsing, requiring application-layer proxies or protocol breaking to maintain operational capabilities.
Passive network monitoring sensors capture all traffic on ICS network segments without introducing latency or single points of failure. These sensors build baselines of normal communication patterns: which devices communicate with which, on which protocols, at what frequency, and with what function codes. Deviations from baseline patterns generate alerts.
Detectable anomalies include new devices appearing on the network (potential rogue devices or initial access), PLCs issuing commands to other PLCs (lateral movement), Modbus write commands from unexpected IP addresses (unauthorized command execution), or sudden increases in polling frequency (reconnaissance or disruption preparation). Platforms such as Claroty, Dragos, and Nozomi Networks perform this function specifically for ICS environments, maintaining protocol libraries covering hundreds of industrial protocols and understanding the operational context of industrial communications.
Third-party vendor access, remote engineering sessions, and emergency support connections create temporary openings in network boundaries. ICS-specific remote access solutions implement time-limited sessions, record all session activity, require multi-factor authentication at jump server boundaries, and prohibit direct connections to field devices from external networks. A vendor who needs PLC access must authenticate to a jump server in the DMZ, from which a proxied session to the device is established with all commands logged and reviewable.
The consequences of inadequate ICS network security extend beyond data breaches to physical damage, safety incidents, and infrastructure disruption. Adversaries with nation-state resources and criminal organizations have demonstrated the ability to cross IT/OT boundaries, traverse ICS networks, and deliver physical effects.
The December 2015 attack on Ukrainian power distribution companies illustrates the operational impact. Attackers compromised IT networks through spear-phishing emails, then pivoted to OT networks, took control of SCADA systems, and remotely operated breakers to cut power to approximately 230,000 customers. The attackers also overwrote firmware on serial-to-Ethernet converters to deny recovery and launched telephone denial-of-service attacks against customer service lines. The breach was possible because IT and OT networks lacked adequate segmentation. Once attackers had IT credentials, they could reach OT systems.
In 2021, an attacker accessed a water treatment facility in Oldsmar, Florida through a remote access tool and attempted to increase sodium hydroxide levels to dangerous concentrations. An operator observed the cursor moving and reversed the change. The facility had no network segmentation between remote access infrastructure and process control systems, allowing direct manipulation of safety-critical parameters.
Beyond targeted attacks, poor ICS network security creates operational vulnerabilities. The 2017 NotPetya incident disrupted manufacturing and logistics operations globally as malware propagated across flat OT networks. Ransomware infections encrypt historian and HMI systems, halting production until backups can be restored. Data exfiltration through unsecured historian connections compromises intellectual property and operational intelligence.
A common misconception is that air-gapped networks are inherently secure. True air gaps are rare in practice. Most facilities described as air-gapped have maintenance laptops connecting to both OT and IT environments, USB drives carrying updates and patches, and remote access solutions for vendor support. These vectors have been initial access paths in multiple significant ICS compromises, including Stuxnet. Network security controls must account for these realities rather than assume isolation that does not exist.
The business impact extends to regulatory compliance. The NERC CIP standards for electric utilities mandate network segmentation and monitoring. The TSA pipeline security directives require similar controls. Non-compliance carries financial penalties and potential operational restrictions. More importantly, regulatory frameworks codify lessons learned from actual incidents and represent minimum viable security postures rather than aspirational goals.
CDA approaches ICS network security through the Vulnerability Surface Domain (VSD) of the Planetary Defense Model, applying the Continuous Surface Reduction (CSR) methodology: every surface you expose is a surface we eliminate. In ICS environments, this means CDA does not begin with detection and response. It begins with rigorous inventory and communication path analysis to identify every connection that should not exist.
The first deliverable in a CDA ICS engagement is a network communication matrix: every source, destination, protocol, and port currently traversing IT/OT boundaries and within OT zone boundaries. Most organizations discover connections they did not authorize, did not document, and cannot explain. Each unexplained connection represents a surface to eliminate before deploying monitoring tools.
CDA then applies CSR systematically to each zone boundary. At the enterprise/OT DMZ, CDA validates that all historian replication is one-directional and proxied, that no enterprise authentication systems have direct trust relationships with OT systems, and that remote access paths terminate in the DMZ rather than extending into OT zones. At OT zone boundaries between Level 2 and Level 3, CDA validates that only protocols required for legitimate operations are permitted, with all others denied by default.
CDA does not treat industrial firewall rule sets as one-time configuration tasks. Rules drift over time. Vendors request exceptions. Emergency maintenance creates temporary connections that become permanent. CDA implements formal rule review cycles against communication baselines, flagging every rule that cannot be tied to documented business requirements. Rules without justification are removed.
On the monitoring side, CDA installs passive protocol-aware sensors at all zone boundaries and critical intra-zone segments, tuning alert thresholds against validated baselines rather than default signatures. This reduces alert fatigue and ensures anomaly alerts reflect genuine deviations from known-good behavior rather than noise from undocumented but legitimate traffic. The CDA posture is that the network itself is the most effective defensive layer in environments where endpoint controls cannot be installed, patches cannot be applied, and system reboots are operationally prohibited.
CDA Theater missions that address topics covered in this article.
Cryptographic technique that encrypts data while preserving its original format and length, enabling protection without breaking legacy system compatibility.
Guide to HTTP/2 security covering binary framing, HPACK compression attacks, rapid reset vulnerability, stream multiplexing risks, and mitigation strategies.
Explanation of Certificate Transparency framework, covering log servers, Signed Certificate Timestamps, monitoring capabilities, and detection of fraudulent certificates.
Written by CDA Editorial
Found an issue? Help improve this article.