The ICS Security Landscape

The Cursor That Moved on Its Own

In February 2021, an operator at a water treatment plant in Oldsmar, Florida watched his mouse cursor slide across the screen. His hand was not on the mouse. Someone had connected remotely and, within two minutes, raised sodium hydroxide concentrations to 111 times the normal level. The operator spotted the change and reversed it. Fifteen thousand residents never knew. It is a good story of a breach caught in time. It is a troubling story about how it was possible. The facility was running TeamViewer, a remote desktop tool designed for IT support, directly on an HMI connected to the plant's control systems. The full investigation -- what enabled the access, why attribution remains contested, and what an audit trail would have resolved -- is covered in Chapter 10. This chapter covers the broader landscape: how ICS environments became targets, what beliefs leave them exposed, and what the two most consequential ICS cyberattacks in history revealed about the nature of the threat.

How ICS Became a Target

For most of their history, industrial control systems weren't relevant to most attackers. A Modbus-connected PLC on an isolated serial network, running proprietary firmware, in a sector an attacker knew nothing about -- the exposure was minimal. Four changes dismantled that. First, commercial off-the-shelf hardware replaced proprietary equipment across most industrial sectors. Windows-based HMIs, standard Intel processors, and common networking hardware replaced purpose-built electronics. That brought real-time capability and lower cost. It also brought Windows vulnerabilities, standard network stacks, and an internet full of automated tools designed to probe them. Second, TCP/IP replaced serial industrial protocols as the default communication medium. Devices that were once reachable only by someone physically on the serial bus became reachable from any IP-connected network. Third, remote access became routine. Vendors connect to PLCs from offices hundreds of kilometers away. Engineers diagnose problems from home. Each access path is a potential entry point that may or may not appear on any network diagram. Fourth, the attack tooling matured. Metasploit, a freely available penetration testing framework, includes Modbus exploit modules. Shodan, a public search engine, indexes internet-connected devices by protocol -- search for Modbus or DNP3 and it returns thousands of live PLCs and RTUs accessible from the open internet with no credentials required. An attacker targeting ICS no longer needs ICS expertise. The tools provide it. These four changes did not happen all at once, but by the mid-2010s their combined effect was clear: the assumption of isolation that had justified the absence of ICS security controls no longer held, and the attack surface was broader than most facility operators had documented.

The Five Beliefs That Leave Plants Exposed

Certain beliefs about ICS security persist because they used to be accurate. Each one has since been invalidated by changes in technology and attacker capability, but they continue to shape decisions in facilities around the world. The first is that the network is not connected to anything external. Serial-to-Ethernet converters, vendor access tunnels, engineering laptops that bridge the OT and corporate networks simultaneously, and cellular modems installed as backup links have all created paths that do not appear on topology drawings. Censys, an internet scanning service, found over 145,000 industrial control systems directly reachable from the public internet in late 2024. Most of those facilities have no record of those exposures. The second is that the firewall is protection. A firewall misconfigured to allow unauthenticated traffic on industrial protocol ports is not a security control -- it is a labeling system. Industry audits of OT environments consistently find firewall rules that allow exactly the traffic they should block. In 70 percent of OT incidents Dragos responded to in 2024, attackers entered through IT and crossed into OT from inside an already-compromised perimeter. The third is that attackers don't understand ICS systems well enough to cause harm. They don't need to. Automated tools and searchable exploit databases have compressed the knowledge gap. Dragos tracked nine threat groups actively operating in OT environments in 2024, four of which demonstrated demonstrated capability to cause direct physical consequences to industrial processes. The fourth is that the facility isn't a valuable target. Ransomware operators don't choose industrial targets for their technical knowledge -- they choose them because downtime has a direct, measurable hourly cost and industrial companies pay quickly. Dragos documented 1,693 ransomware attacks on industrial organizations in 2024, an 87 percent increase over the prior year; in 75 percent of those incidents, at least part of the operation shut down. The fifth is that the control systems or safety systems will catch anything malicious. They won't. Modbus has no authentication. A device that can reach the network can send commands to a PLC without credentials. The Triton malware, examined later in this chapter, specifically targeted safety systems to disable the safety layer before a process attack could follow. Attackers who understand ICS don't avoid the safety layer -- they plan around it.

Understanding ICS Risk

The organizations that fail at security consistently share one characteristic: they try to fix everything at once. They exhaust resources before the most critical risks are addressed, and they cannot explain to management which investments mattered and why. A risk framework prevents that. Risk equals Threat multiplied by Vulnerability multiplied by Consequence. In ICS terms: Threat is who or what could cause harm -- external attackers, malicious insiders, and system misconfigurations all qualify. Vulnerability is how exposed the system is, measured by what an attacker could reach and what they could do once there. Consequence is the worst credible outcome if that exposure is exploited. In industrial environments, consequence ranges from brief process disruption at the low end to equipment destruction, environmental incidents, injury, or loss of life at the extreme. All three factors must be present for risk to exist. Remove any one, and risk drops. In practice, each factor is rated qualitatively as low, medium, or high, and the combination determines where on the risk matrix a given exposure falls. Once a risk is measured, four responses are available, each mapped to a position in the likelihood-impact space. High likelihood and high impact: avoid it by eliminating the exposure entirely. High likelihood and low impact: reduce it by mitigating frequency or limiting damage. Low likelihood and high impact: transfer it -- cyber insurance covers financial exposure; the physical risk may still need compensating controls. Low likelihood and low impact: accept it, document it, and monitor it. Every security investment maps to one of these four responses. Without a risk framework, the implicit response to every vulnerability is "reduce it regardless of cost," which means resources are consumed uniformly rather than allocated where consequences are greatest. Risk tolerance must be documented and set by management, not assumed by engineers. "We haven't been attacked yet" is not a risk tolerance statement. It is the absence of one.

Defense-in-Depth: Seven Layers

A perimeter firewall is a necessary security control. It is also the first thing attackers plan around. A misconfigured rule, a vendor access tunnel, a compromised credential -- any of these provides a crossing. And if nothing separates an attacker from the process control layer once they are inside the perimeter, one successful entry gives them everything. The defense-in-depth model addresses this by stacking independent controls, each designed to catch what the previous layer cannot. The analogy is a medieval castle: not defended by a single wall but by a moat that slows approach, outer walls that stop direct assault, a gate that controls entry, an inner keep as a last refuge, and watchtowers that detect threats before they arrive. No single element is sufficient. Each compensates for the weaknesses of the others. In ICS security, those castle elements map to seven distinct control layers. The perimeter layer reduces the external attack surface through firewalls, Industrial DMZ buffering as introduced in Chapter 2, and ingress filtering. Network segmentation divides systems into zones with controlled conduit paths between them, limiting lateral movement -- an attacker's ability to pivot between systems after compromising one. Access control ensures only authorized personnel reach critical systems: role-based permissions, least privilege, and multi-factor authentication. Endpoint hardening addresses the devices themselves: patching what can be patched, removing unnecessary services, and applying application whitelisting where ICS vendors support it. The monitoring and detection layer makes the invisible visible: network traffic analysis, anomaly detection, and log collection. People and process -- training, documented procedures, and governance -- ensure technical controls are actually used. Incident response and recovery closes the model: tested response plans and backup configurations that ensure the facility survives what the other layers could not prevent. Detection must be distributed across this architecture, not concentrated at one point. A firewall that logs what it blocks but has no visibility inside the control network leaves everything between the perimeter and the field devices invisible once the perimeter is crossed. Monitoring capability placed at each zone boundary, at engineering workstations, and on the control network itself makes the stack genuinely resilient rather than reassuring in appearance only.

Stuxnet: The Weapon That Proved ICS Was a Battlefield

In 2010, nuclear centrifuges at Iran's Natanz enrichment facility began destroying themselves. The aluminium rotors were spinning to speeds that tore them apart. The engineers watching the SCADA screens saw nothing wrong. The readings showed everything was normal. The software was lying to them. Natanz was considered impenetrable: physically isolated, behind multiple security layers, with control systems that had no path to the outside world. The air gap was considered the strongest isolation an ICS facility could have. The attack reached it anyway. A contractor carried it on a USB thumb drive across the physical boundary. Stuxnet first infected five Iranian industrial automation companies under contract to the facility, then spread inward as engineers moved between sites carrying removable media. Once inside Natanz's network, it spread using four separate Windows zero-day vulnerabilities -- a zero-day is a software flaw the vendor has not yet discovered, so no patch exists. No prior malware had weaponized more than one or two zero-days simultaneously. Stuxnet used four, plus stolen legitimate digital certificates that made its code appear trusted. When it identified Siemens S7-315 and S7-417 PLCs, paired with specific frequency converter models from Iranian and Finnish manufacturers, it stopped spreading and started its attack cycle: driving centrifuges above safe rotational speed, allowing recovery, then dropping them to near-zero. Each cycle fractured the rotors further. While running, it fed the SCADA system pre-recorded normal sensor readings. Operators saw nothing unusual. Engineers assumed quality problems with the machines. Approximately 1,000 centrifuges were decommissioned and replaced. A cyberattack had physically destroyed precision industrial equipment. The programming behind it was extraordinary in another dimension: it managed the evidence. The attack did not generate alerts. It did not trigger the safety systems. It ran for months while engineers watched screens that showed a process running correctly. Stuxnet was later confirmed as a joint US-Israeli intelligence program codenamed Olympic Games, through investigative reporting and a 2016 US federal prosecution. Its lessons are permanent: air gaps can be crossed by human carriers, sensor data can be falsified while equipment is being destroyed, and nation-state actors will build highly sophisticated, purpose-built tools to accomplish specific ICS objectives.

Triton: When Attackers Targeted Safety

Seven years after Stuxnet, a threat group that Dragos named XENOTIME and FireEye named TEMP.Veles did something that changed how the industry thinks about the deepest layer of ICS protection. They attempted to disable the Safety Instrumented System at a Saudi petrochemical facility. The SIS, introduced in Chapter 1, is the automated safety layer that operates independently of the main control system. If critical process variables -- pressure, temperature, chemical concentrations -- move outside safe operating ranges, the SIS triggers an emergency shutdown without waiting for an operator decision. It is the last automated barrier between a process upset and a physical catastrophe. The assumption had been that attackers would not target the SIS in isolation, because disabling the safety layer alone causes nothing. To cause harm, an attacker needs simultaneous control of both the SIS and the process control layer. XENOTIME planned around that assumption precisely. They entered through the corporate network, crossed into OT through a misconfigured firewall, gained access to an engineering workstation via Remote Desktop Protocol, and then spent months reverse-engineering TriStation -- the proprietary protocol used to program Schneider Electric Triconex SIS controllers. Workers had left the physical key switch on the Triconex controllers in the permissive position, enabling remote software access. The result was TRITON: custom malware capable of sending reprogramming commands directly to the SIS. The attack was stopped by its own coding error. TRITON had a bug: instead of silently reprogramming the Triconex controllers to disable safety functions, the malware triggered a diagnostic fault. The controllers entered safe-state shutdown. The plant stopped unexpectedly, twice. Engineers investigated, found the malware, and the intrusion was discovered. Not by a monitoring tool. By a coding mistake. The facility was saved by luck. The attack was later attributed to CNIIHM, a Russian state research institute, through FireEye analysis in October 2018, a US Treasury sanction in 2020, and a US Department of Justice indictment of a named researcher in March 2022. XENOTIME remained active after Triton's discovery, probing electric utility networks in North America and the Asia-Pacific region. Triton established that safety systems are not off-limits, that attackers will specifically plan to disable the final safety layer, and that the goal in the most serious ICS attacks is not disruption or data theft -- it is a physical catastrophe with no automated system able to stop it.

The Frameworks That Structure Everything

Two frameworks appear throughout the rest of this book. Understanding their relationship prevents confusion when they appear together in audits, procurement conversations, and security assessments. IEC 62443 is the international standard series developed jointly by the International Society of Automation and the International Electrotechnical Commission, specifically for Industrial Automation and Control Systems. It is structured as four numbered series: Series 1 covers general concepts, terminology, and the security lifecycle model. Series 2 addresses policies and procedures -- the Cyber Security Management System (CSMS), patch management, and supplier security assessments. Series 3 is the system design standard, covering risk assessment methodology and the zones-and-conduits segmentation model that structures ICS network architecture. Series 4 covers individual components: product security requirements and the secure development lifecycle standards for equipment manufacturers. Three roles interact with the standard: asset owners (facilities that run ICS), system integrators (who design and install it), and product suppliers (who manufacture the components). IEC 62443 introduces Security Levels numbered 1 through 4, each reflecting an assumed attacker capability. Level 1 covers accidental or incidental exposure. Level 2 targets intentional attacks using publicly available tools. Level 3 assumes ICS-specific knowledge and targeted intent. Level 4 assumes a state-sponsored actor with substantial resources. These levels determine what security requirements apply to zones, conduits, and individual components. The NIST Cybersecurity Framework 2.0, released February 2024, provides a strategic organizing language for the entire security program. It organizes security activity into six functions: Govern (new in CSF 2.0), Identify, Protect, Detect, Respond, and Recover. Govern addresses who owns accountability for cybersecurity risk decisions -- a gap that commonly causes ICS security to fail not from missing technology but from missing ownership at the boundary between engineering and IT. NIST SP 800-82, now in its third revision, adapts the IT security control catalog for OT-specific realities: no active scanners on live OT systems, compensating controls accepted when patching is not feasible, and safe process operation taking priority over forensic preservation during an incident. The two frameworks divide the work: NIST CSF provides the strategic language for management and audit conversations, while IEC 62443 provides the engineering methodology for design decisions.

What's Next

Chapter 4 has established the threat landscape, the risk framework, and the organizing standards. Chapter 5 shifts from the external threat to the internal environment: who in the organization is responsible for security, how to map the assets that need protecting, and the governance structure that determines whether controls get applied and maintained. Before you can protect what you have, you need to know what you have and who owns it.

Reflect

• The five myths examined in this chapter (not connected, firewall protects us, attackers lack knowledge, not a target, systems will catch anything) were not invented -- they started as accurate descriptions of the environment. Which of these beliefs, in some form, is still shaping decisions in your environment today?
• Stuxnet demonstrated that a determined, well-resourced adversary can design malware to falsify sensor readings while destroying the physical equipment those readings describe. What would an attacker who could manipulate sensor data in your environment be able to conceal, and for how long?
• Triton was stopped by a coding bug in the malware, not by a detection or response capability. If the bug had not been there, what monitoring, logging, or access control would have surfaced the intrusion before the safety system was disabled?
• The defense-in-depth model has seven layers, and the chapter argues that security calibrated to the operational environment will be used while security that disrupts operations will be bypassed. Which of the seven layers is most likely to be circumvented in your environment, and what operational constraint is driving that circumvention?