What Is an Industrial Control System

Computers You Never See

Right now, computers are deciding how much chlorine goes into your drinking water. Controllers embedded in a municipal treatment plant are reading sensors, comparing measurements against setpoints (the target values the system is configured to maintain), and adjusting chemical dosing automatically. They aren't running Windows. They have no keyboard. No one is watching them at this moment. They just run, continuously, every second of every day, without interruption. This is what an industrial control system (ICS) is: any computer system designed to monitor and control a physical process. Not to store data, not to run applications, not to serve web pages. To make things happen in the physical world. Valves open. Motors start. Pumps run. When a temperature sensor reports that a reactor vessel is getting too hot, the control system responds automatically. It adjusts flow rates, triggers a cooling cycle, or escalates an alarm to the operator. It does this faster than any human could react, and it does this without stopping. The design priority of an ICS is continuity, not convenience. A desktop computer that crashes gets restarted. An industrial control system controlling a city's water treatment plant cannot crash. If it stops, the city has no clean water. Every engineering decision inside these systems follows from that single requirement: keep the process running. That priority shapes everything, from hardware choices to patching schedules to how operators are trained. Understanding it is the foundation of everything else in this book.

The Industries That Depend on It

Every power plant uses ICS to control turbines, generators, boilers, cooling systems, and grid switching. The fuel source changes -- coal, gas, nuclear, wind, solar -- but the control requirement stays the same. Substations that step voltage up and down for transmission are monitored remotely by SCADA systems. SCADA (Supervisory Control and Data Acquisition) is software that collects data from remote equipment and sends commands back to it. The electricity reaching your home right now traveled through an ICS before it got there. Municipal water treatment plants use ICS to control chemical dosing, filtration, pumping, and pressure. Oil refineries use it to control distillation columns, heaters, and compressors running at high temperature and pressure around the clock. Pipeline operators monitor valves, flow rates, and compressor stations across hundreds of miles from a single control room. Manufacturing runs on the same technology: automotive assembly lines coordinating robots, conveyors, and welding stations; pharmaceutical plants controlling batch reactors where temperature and timing directly affect product safety; food and beverage production, chemical manufacturing, and paper mills. One hour of unplanned downtime on an automotive assembly line can cost more than two million dollars. That number explains why availability in an ICS environment is treated as a safety value rather than a business preference. When a process loses control, the consequences extend well beyond financial loss.

The same control logic extends beyond heavy industry. Rail signaling systems use ICS to control track switches and signal lights, preventing train collisions. Airport baggage systems route luggage through automated sorters at a pace no manual process could match. Traffic management centers coordinate signal timing across entire cities. Building management systems apply the same ICS principles to HVAC, elevators, fire suppression, and access control in large commercial and government facilities. Mining operations use ICS for underground ventilation, conveyors, and hoisting equipment, where the failure of a ventilation controller is not an inconvenience but a life-safety event. If a system moves something, heats something, or controls something physical at scale, an industrial control system is almost certainly involved. The practical implication for this book is significant: ICS cybersecurity incidents are not limited to refineries or power plants. They can reach any facility, in any sector, that relies on automated physical control.

Five Levels, One Map

Industrial control systems are not a single piece of technology. They are a collection of systems organized into a hierarchy, and understanding that hierarchy is what lets you orient yourself in any industrial facility in the world. The Purdue Model, developed at Purdue University and now the reference framework used across the industrial automation industry, organizes an ICS into five levels. The model separates systems by function and by criticality, from the physical process at the bottom to enterprise IT at the top. Once you understand it, you have a map you can apply in any sector.

At the bottom is Level 0: the physical process itself. Motors, pumps, valves, sensors, and actuators that interact directly with whatever is being produced or controlled. This is where chlorine enters the water, where fuel burns in the boiler, where the conveyor moves the product. Level 0 doesn't compute anything. It acts. Level 1 is the first digital layer. PLCs (Programmable Logic Controllers) sit here, reading sensor data from Level 0 and sending control signals back. A PLC executes logic continuously: if tank pressure exceeds 90 PSI, close valve V-12. That logic runs in milliseconds, without a human in the loop. Level 1 is what makes automated control possible -- a physical world responding to digital instructions in real time.

Level 2 is where operators interact with the system. HMI (Human-Machine Interface) screens display the live process. SCADA software running at this level supervises multiple sites from a single location. An operator sets a pump to run or raises a temperature setpoint. The PLC at Level 1 executes the command. Level 2 handles supervision; Level 1 handles execution. Level 3 covers site operations: engineering workstations, data historians (software that logs process values over time for trending and analysis), and manufacturing execution systems. Level 4 is enterprise IT: corporate networks, business applications, and analytics platforms. The higher you go in the model, the less real-time the systems become. The boundary between Levels 3 and 4 is the most significant dividing line in any ICS. Below it is the operational technology (OT) world. Above it is the IT world. The differences between those two worlds are what this book is about.

A Different Priority Order

IT security teaches the CIA triad: Confidentiality, Integrity, Availability. Protect data from unauthorized access first. Ensure its accuracy second. Keep systems running third. The order makes sense when the asset you're protecting is information. Data can survive a reboot. Servers can be taken offline for patching. A few hours of downtime is expensive and disruptive, but it is rarely dangerous. In industrial control systems, the priority order is almost exactly reversed: Safety first, Availability second, Integrity third, Confidentiality last. This is not a security gap or an oversight by engineers who didn't understand risk. It is an engineering decision with direct consequences for human life, and it has shaped every design choice in ICS hardware and software for decades.

Safety sits at the top because industrial systems are engineered to reach a known safe state when they fail. A chemical plant losing control doesn't just lose data -- it can injure or kill people, release hazardous materials, and destroy equipment that took years to build. Availability ranks second because the physical process often cannot simply stop. A chemical distillation column running crude oil takes days to safely shut down and days to bring back up. A nuclear reactor cannot be switched off and restarted like a server. Integrity matters because wrong data is dangerous -- a false sensor reading can cause a control system to take the wrong action -- but an unnecessary shutdown of a running process carries its own physical risks. Confidentiality is last. Not because it is unimportant, but because a data leak has never directly caused a refinery explosion. This reversed priority order explains almost every operational decision that initially confuses IT professionals when they first encounter an OT environment: systems running years-old software with known vulnerabilities, patch cycles measured in months, network configurations that would be unacceptable in a corporate setting. These are the products of an environment where the consequences of getting the wrong thing wrong are physical, immediate, and sometimes irreversible.

When the System Cannot Stop

The requirement for continuous availability in ICS creates constraints that have no equivalent in enterprise IT. Critical industrial facilities run a separate layer called a Safety Instrumented System (SIS), independent of the main control system. The SIS monitors for dangerous conditions -- excessive pressure in a vessel, a temperature approaching a hazardous threshold, a flow rate outside safe operating bounds -- and triggers an emergency shutdown automatically if those conditions are met. It does not wait for an operator. It does not check with the main PLC. The SIS acts on its own, and it is designed to fail safe: on power loss or a sensor fault, it defaults to a known safe state rather than leaving the process uncontrolled. Because the SIS sits on a separate network with its own sensors and logic, it must also be considered separately in any ICS security assessment. The most consequential ICS attacks have targeted SIS systems specifically, because taking a safety layer offline is the pathway from a cyber intrusion to a physical catastrophe. Patching these systems is not a matter of scheduling a maintenance window: it begins months in advance, requires testing on an identical offline system, and happens only when operations confirms the process is in a state where intervention is acceptable. Patch cadences that are considered dangerously slow in IT are the practical reality in ICS.

The Operator's World

Walk into a real industrial control room and set aside any expectations shaped by film or television. The real version is quieter and more purposeful. One or two operators sit at a desk facing a bank of monitors. Process data updates every few seconds. The central display shows the HMI process graphic: a simplified schematic of the plant with live values overlaid. Tanks show current fill levels. Pumps show running or stopped. Valves show open or closed. Temperatures, pressures, and flow rates update in real time. An operator reads this the way an air traffic controller reads a radar screen: everything in motion, everything connected, any deviation from normal immediately apparent. Operators monitor trend graphs (rolling historical charts of measured values), manage alarms (anything outside a defined normal range generates a timestamped alert that must be acknowledged), adjust setpoints, start and stop equipment according to the production schedule, and follow written procedures for non-routine work. What they don't do is write code, configure hardware, or troubleshoot network issues. That is engineering work, handled by separate teams on a different timeline. The operator's defining characteristic is depth over breadth. They train on one specific system -- this water plant, this refinery, this assembly line -- and they know it intimately. They know what the values mean, what constitutes normal, and what sounds wrong before an alarm fires. This is the opposite of how IT administrators are trained, and it matters enormously for cybersecurity. A security tool that generates alerts an operator cannot interpret will be dismissed during a production-critical shift. A cybersecurity approach that ignores operator context will fail in any industrial environment, regardless of how technically sound it is.

The Security Gap

These systems were not built with security in mind. That's not a criticism -- it's a historical fact with technical consequences that practitioners deal with every day. Modbus, the dominant serial communication protocol for PLCs, was released by Modicon in 1979 for isolated serial connections where the network was trusted by definition. It has no authentication: no mechanism to verify that a command came from an authorized source. Any device that can reach the network can issue commands to a PLC -- stopping a motor, opening a valve, changing a setpoint -- without any form of identification or challenge. DNP3, common in power grids, and PROFIBUS, widely used in manufacturing, share the same foundational assumption. These protocols were built for closed environments where the absence of authentication didn't matter because nothing external could reach them. For decades, that isolation was the accepted answer to ICS security. This was called the air gap: the physical separation between the control network and everything else. Today, almost no industrial facility is truly air-gapped. Remote access for vendor support, data integration between OT historian systems and enterprise analytics platforms, and the general convergence of IT and OT networks have eroded that separation. The air gap was not a security plan. It was an assumption, and the world has since invalidated it.

Legacy equipment compounds the problem. A PLC installed in 2002 may run an embedded operating system with known vulnerabilities: documented security weaknesses that attackers can exploit through published methods. For many of these devices, no patch exists. The vendor stopped supporting the product years ago. The system cannot be replaced because it controls a continuous process with no acceptable downtime window, and because replacement costs and recertification requirements are prohibitive. This is not a theoretical concern; it is the reality of the installed base in manufacturing plants, utilities, and energy infrastructure operating today. The fourth structural gap is visibility. In most ICS environments, there is no record of which devices communicated with which, no logging of connections to PLCs or HMIs, and no network monitoring capable of detecting anomalous traffic. If an attacker gains access, there is often no way to know until the physical process is already affected. In IT security, a lack of visibility is treated as a critical finding. In ICS, it has historically been the operating standard. None of these gaps is limited to older or underfunded facilities. They are structural features of most ICS environments currently in service, and addressing them is what the security chapters of this book are about.

What's Next

Chapter 1 established what an ICS is, how it's organized, and why its priorities and constraints differ fundamentally from the IT world. Chapter 2 moves inside those five Purdue levels and examines each major component in detail: PLCs, HMIs, SCADA systems, DCS platforms, RTUs, and historians. Understanding what each component does, how it fits into the architecture, and where it sits in the Purdue hierarchy is what makes the security discussions that follow concrete rather than abstract.

Reflect

• Think about the industrial or operational environment you work in or closest to. Where in the Purdue Model do the systems you interact with sit, and how does that level determine what security controls are even feasible?
• The SAIC priority order (Safety, Availability, Integrity, Confidentiality) governs ICS design. Where in your own environment have you seen a security recommendation fail because it didn't account for availability or safety constraints?
• The air gap assumption has been eroded in almost every industrial environment. What connections exist in your environment -- remote access, data historians feeding enterprise systems, wireless -- that an attacker could potentially use as an entry point?
• The operator's depth-over-breadth mindset means security tools that generate unfamiliar alerts get dismissed. If you were introducing a new security monitoring capability in your environment, how would you design it to work with the operator's existing process awareness rather than against it?