Category: ICS/OT Security
Difficulty: Beginner
Reading Time: 12 minutes
Introduction: Where Cyber Meets the Real World
There is a particular flavour of cybersecurity incident that most IT professionals never have to worry about. It is the kind where a successful exploit does not merely result in leaked customer data or a ransomware-encrypted file server, but in a steel mill's blast furnace refusing to shut down, a water treatment plant dumping excessive chlorine into the supply, or an entire country's power grid going dark on the coldest night of the year.
Welcome to ICS security -- the branch of cybersecurity where the consequences have weight, temperature, and occasionally explosive force. Unlike traditional IT security, where the worst-case scenario usually involves an awkward phone call to the Information Commissioner's Office, ICS security failures can result in environmental disasters, equipment destruction, and genuine danger to human life.
This article is the first in a series covering Industrial Control Systems security from the ground up. Whether you are an IT security professional looking to pivot into OT, a student building a home lab, or simply someone who enjoys the vague existential dread of learning how fragile critical infrastructure really is, this is where it starts.
What Is an Industrial Control System?
An Industrial Control System (ICS) is a general term covering several types of control systems and associated instrumentation used to operate and automate industrial processes. These systems run power plants, water treatment facilities, manufacturing lines, oil refineries, chemical plants, building management systems, and a distressing number of other things that society depends on daily without thinking about it.
The term "ICS" serves as an umbrella covering several component types:
PLCs -- Programmable Logic Controllers
PLCs are the workhorses of industrial automation. These ruggedised computers take inputs from sensors (temperature, pressure, flow rate, valve position), execute programmed logic, and drive outputs to actuators, motors, and valves. They are the reason your central heating knows when to turn on and a bottling plant can fill exactly 330ml into each can.
PLCs are programmed using specialised languages defined in the IEC 61131-3 standard -- Ladder Logic (which looks like circuit diagrams and makes software engineers weep), Structured Text, Function Block Diagram, and others. Most PLCs run proprietary real-time operating systems, and many in active service today were programmed with tools that require Windows XP.
Yes, really. Windows XP. In production. In 2026. This is not a bug; this is a feature of OT culture, and understanding why is critical to understanding ICS security.
HMIs -- Human-Machine Interfaces
HMIs are the screens and panels that operators use to monitor and interact with the industrial process. Think of them as the dashboards of the industrial world -- they display process variables, alarm states, and allow operators to make manual adjustments. They range from simple touchscreens bolted to the side of a machine to sophisticated SCADA workstations with multiple monitors showing real-time process graphics.
HMIs are frequently the most vulnerable component in an ICS environment, because they tend to run on standard Windows operating systems, they need network connectivity to communicate with PLCs, and they often run legacy software that has not seen a patch since the developer went out of business in 2011.
RTUs -- Remote Terminal Units
RTUs perform a similar function to PLCs but are designed for remote, distributed installations -- substations, pump stations, wellheads, and other locations where it would be impractical or impossible to run a cable back to the control room. They communicate over wide-area networks using protocols such as DNP3 or Modbus, often over radio links, leased lines, or (increasingly) cellular or satellite connections.
The security implications of devices that sit in unmanned locations, communicating over shared infrastructure, should be immediately apparent to any security professional.
SCADA -- Supervisory Control and Data Acquisition
SCADA is not a single device but an architecture -- a system of systems that provides centralised monitoring and control over geographically dispersed assets. SCADA systems aggregate data from PLCs and RTUs, present it to operators via HMIs, log historical data, generate alarms, and enable remote control.
A SCADA system for a water utility might aggregate data from dozens of pump stations, treatment plants, and reservoir level sensors spread across an entire region, presenting it all on screens in a central control room where a single operator can monitor the lot.
DCS -- Distributed Control Systems
DCS architectures are similar in concept to SCADA but are typically used in process industries (chemical plants, refineries, power generation) where control is distributed across multiple controllers that manage different parts of a continuous process. The distinction between SCADA and DCS has blurred considerably over the years, and modern systems often combine elements of both.
The Purdue Model: Layers of an Industrial Network
If you want to understand ICS network architecture, you need to understand the Purdue Enterprise Reference Architecture, more commonly known as the Purdue Model. It is the conceptual framework that (in theory) defines how industrial networks should be segmented.
The Purdue Model defines six levels:
Level 0 -- The Physical Process
This is the actual physical equipment: sensors, actuators, motors, valves, conveyor belts, chemical reactors. Level 0 is where the cyber meets the physical. There is no firewall that can protect against a motor that has been told to spin at twice its rated speed.
Level 1 -- Basic Control
PLCs, RTUs, and safety instrumented systems (SIS) live here. These devices directly read sensors and drive actuators. They execute control logic on cycle times measured in milliseconds. A PLC at this level might be controlling the temperature of a reactor vessel or the speed of a turbine.
Level 2 -- Area Supervisory Control
HMIs, engineering workstations, and local SCADA servers. This is where operators interact with the process, where alarms are displayed, and where engineers connect to download logic changes to PLCs. It is also where some of the most concerning attack vectors exist, because engineering workstations often need access to both the control network and the business network.
Level 3 -- Site Operations
Historians (databases that log process data), site-level SCADA servers, MES (Manufacturing Execution Systems), and other operational technology that manages production. Level 3 is often considered part of the OT domain but sits closer to the IT/OT boundary.
Level 3.5 -- The Demilitarised Zone (DMZ)
Not part of the original Purdue Model but added by common practice and referenced in standards like IEC 62443. This is the critical boundary between the OT and IT networks. Data should flow through the DMZ via jump servers, data diodes, or firewalls with strict rules. In a well-architected environment, no direct communication should be possible between Levels 4-5 and Levels 0-3.
In practice, this DMZ is about as consistently implemented as New Year's resolutions.
Level 4-5 -- Enterprise IT
The corporate network, business applications, email, internet access, and all the standard IT infrastructure. This is the domain most security professionals already know, and it is where many ICS attacks actually begin -- with a phishing email to a corporate user, followed by lateral movement down through the Purdue levels until the attacker reaches the control systems.
IT vs OT: A Culture Clash of Magnificent Proportions
Understanding ICS security requires understanding that IT and OT have fundamentally different priorities, cultures, and constraints. The friction between these two worlds is not merely technical -- it is philosophical.
The CIA Triad, Rearranged
IT security prioritises Confidentiality, Integrity, and Availability -- in roughly that order. Protect the data, ensure it has not been tampered with, and keep systems running.
OT security flips this on its head. The priority order is Availability, Integrity, Safety -- and confidentiality barely registers. Nobody cares if an attacker can read the temperature of a reactor vessel. They care very much if the reactor vessel stops being controlled, or worse, if the safety systems that prevent a runaway reaction are disabled.
When an OT system goes down, the consequences are not "users cannot access their email." The consequences range from "production stops and revenue is lost at thousands of pounds per minute" to "the safety system fails and people may be injured or killed."
The Patching Problem
In IT, the patching conversation goes roughly: "There is a critical vulnerability. Schedule a maintenance window. Apply the patch. Reboot. Verify. Done."
In OT, the conversation goes more like this:
"There is a critical vulnerability."
"In what?"
"The HMI software."
"When was it last patched?"
"2014."
"When can we schedule downtime?"
"The next planned shutdown is in eighteen months."
"Can we test the patch first?"
"The vendor went out of business in 2019."
"…"
OT environments routinely run systems with 15-25 year lifecycles. A PLC installed in 2005 may still be controlling a critical process in 2026, running firmware that has not been updated because the system works, because the vendor never released an update, because patching requires a full process shutdown, or because nobody has tested whether the patch would break the control logic. Often all four.
The mantra of OT operations is: "If it works, do not touch it." This is not laziness or negligence -- it is a rational response to an environment where an untested change can cause a process upset that shuts down a plant for days or damages equipment worth millions.
Safety Systems: The Last Line of Defence
Safety Instrumented Systems (SIS) deserve special mention. These are independent systems designed to bring a process to a safe state if conditions become dangerous. They are the emergency brakes of the industrial world, and they are designed to operate independently of the main control system precisely so that a failure in the control system does not compromise safety.
The importance of SIS will become clear when we discuss the Triton/TRISIS attack below.
When It All Goes Wrong: Real-World ICS Attacks
ICS security is not theoretical. Several high-profile incidents have demonstrated exactly what happens when attackers reach industrial control systems.
Stuxnet (2010) -- The Attack That Changed Everything
Stuxnet was not merely a piece of malware -- it was a precision-guided cyber weapon. Discovered in 2010, it targeted Siemens S7-300 PLCs controlling variable-frequency drives at Iran's Natanz uranium enrichment facility. The malware modified the speed of centrifuges -- subtly enough that operators did not immediately notice, but enough to cause them to tear themselves apart over time.
Stuxnet used four zero-day exploits, had two stolen digital certificates, and spread via USB drives (because the target network was air-gapped). It was almost certainly a state-sponsored operation, and it demonstrated several things that the ICS security community had been warning about for years:
- Air gaps are not absolute barriers
- PLCs can be reprogrammed by malware
- Attacks on industrial processes can cause physical destruction
- Sophisticated attackers can remain undetected in OT environments for extended periods
Stuxnet reportedly destroyed roughly 1,000 centrifuges. More importantly, it proved the concept that cyber attacks could cause physical damage to industrial equipment.
The Ukraine Power Grid Attacks (2015-2016)
On 23 December 2015, attackers (attributed to the Sandworm group) compromised three Ukrainian electricity distribution companies, remotely opened circuit breakers, and caused power outages affecting approximately 230,000 customers. The attack used spear-phishing to gain initial access to the corporate IT network, then moved laterally into the SCADA environment.
What made this attack particularly concerning was its sophistication: the attackers overwrote firmware on serial-to-Ethernet converters (preventing remote recovery), deployed KillDisk to wipe SCADA servers, and launched a telephone denial-of-service attack against the utility's call centre so customers could not report outages.
A second attack in December 2016 targeted the Pivnichna substation near Kyiv using Industroyer/CrashOverride -- the first known malware specifically designed to attack electrical grid equipment. It spoke native ICS protocols (IEC 104, IEC 61850, OPC DA) and could directly manipulate power grid equipment.
Triton/TRISIS (2017) -- Attacking Safety Systems
If Stuxnet changed the game, Triton raised the stakes. Discovered in 2017, Triton targeted Schneider Electric's Triconex Safety Instrumented System controllers at a petrochemical facility in Saudi Arabia. The attackers had already compromised the main control system but went further -- they attempted to reprogram the SIS controllers.
Safety systems exist for one reason: to prevent catastrophic failures that could endanger human life. An attacker who disables a SIS and then causes a process upset has removed the safety net entirely. The only reason Triton did not cause a disaster was that the malware triggered a fault that caused the SIS to shut the process down safely -- the attackers' code had a bug.
The implications were stark: a threat actor had developed the capability and demonstrated the intent to disable safety systems in a way that could have resulted in an explosion or toxic release.
Oldsmar Water Treatment Plant (2021)
In February 2021, an attacker accessed the HMI of the Oldsmar, Florida water treatment plant via TeamViewer and attempted to increase the sodium hydroxide (lye) concentration from approximately 100 parts per million to 11,100 parts per million. An operator noticed the cursor moving on screen and reversed the change.
This incident was notable not for its sophistication (it was remarkably unsophisticated) but for what it revealed about the state of ICS security at smaller utilities: shared passwords, remote access software exposed to the internet, no network segmentation, and no multi-factor authentication.
Why ICS Security Is Hard
Several factors make ICS security uniquely challenging:
Legacy systems everywhere. Critical infrastructure runs on equipment designed before cybersecurity was a consideration. Replacing it is extraordinarily expensive and operationally disruptive.
Proprietary protocols and systems. ICS environments use specialised protocols (Modbus, DNP3, OPC) and proprietary systems that standard IT security tools do not understand. You cannot run a vulnerability scanner against a PLC without risking a process upset.
Availability requirements. Many ICS processes cannot tolerate downtime for patching. Some run continuously for months or years between planned shutdowns.
Convergence of IT and OT networks. The air gap is largely a myth. Business demands for data from OT systems (for efficiency monitoring, regulatory reporting, predictive maintenance) have driven connectivity between IT and OT networks, often without adequate segmentation.
Skills gap. ICS security requires knowledge of both IT security and industrial engineering -- a combination that is relatively rare. An IT security analyst who does not understand process control can be as dangerous as an attacker, and a control engineer who does not understand cybersecurity cannot recognise a threat.
Where to Go from Here
This article has covered the fundamentals of ICS architecture and why securing these systems is both critically important and deeply challenging. The key takeaways:
- ICS environments control physical processes with real-world consequences
- The Purdue Model provides a framework for network segmentation, but implementation varies wildly
- OT culture prioritises availability and safety over the confidentiality focus of IT security
- Real-world attacks have demonstrated that ICS systems can be compromised with devastating effect
- The convergence of IT and OT networks has expanded the attack surface dramatically
The next article in this series will cover ICS protocols in detail -- what they do, why they were designed without security, and why Modbus remains the protocol that trusts absolutely everyone.
The physical world does not have a rollback button. Once a turbine has been overspun, a valve has been opened, or a safety system has been disabled, there is no git revert that will undo the damage. That fundamental reality is what makes ICS security one of the most important -- and most sobering -- domains in cybersecurity.
Tech Corsair -- navigating the digital seas so you don't have to.
