OT Security

ICS / SCADA

What industrial control systems and SCADA systems are, how they are structured, and why they represent one of the most consequential attack surfaces in modern cybersecurity.

Where you will see it: Relevant in industrial environments, critical infrastructure, and wherever IT networks connect to operational technology systems.

What it is

Industrial Control Systems is an umbrella term for the hardware and software used to monitor and control industrial processes. Within that category, SCADA stands for Supervisory Control and Data Acquisition. A SCADA system collects data from sensors and field devices distributed across a wide area, presents that data to operators, and allows supervisory commands to be sent back to those devices. Other ICS architectures include Distributed Control Systems, which are more common in continuous process industries like oil refining and chemical manufacturing, and simpler standalone PLC-based systems used in manufacturing and discrete automation.

Key points

ICS is a broad term covering any system that monitors and controls industrial equipment and physical processes.
SCADA systems are a type of ICS designed to supervise distributed operations across large geographic areas, such as pipelines, power grids, and water networks.
These systems typically combine PLCs or RTUs at the field level with human-machine interfaces and centralized data collection at higher levels.
Most ICS and SCADA systems were designed for reliability and real-time performance, not for security in a networked environment.

How it works in broad strokes

Understand the layered architecture of an ICS environment: field devices at the bottom, control systems in the middle, and supervisory and enterprise systems at the top.
Identify what protocols are in use at each layer, since the protocol determines what visibility and control is possible and what security constraints apply.
Map the data flows between levels, paying particular attention to where field-level data crosses into IT systems, because those crossing points are where security boundaries must be enforced.
Recognize which components are safety-critical and which are operational, since this determines what level of intervention is acceptable and how incident response must be planned.
Build monitoring at the network level using passive tools that can observe ICS protocols without actively querying devices.

Concrete example

A regional water utility runs a SCADA system that collects flow, pressure, and chemical readings from pumping stations spread across hundreds of kilometers. Operators at a central control room monitor this data and can send commands to adjust pump speeds or chemical dosing. The SCADA server sits on a network that is also connected to the corporate IT environment for reporting purposes. An attacker who compromises a corporate workstation and pivots to the SCADA server has potential reach into the control commands being sent to physical infrastructure.

Why it matters

ICS and SCADA systems control processes that societies depend on: electricity, water, oil and gas, manufacturing, and building management. A failure in these systems, whether from a technical fault or a deliberate attack, can have consequences far beyond a service outage. Understanding how they are structured and where their weaknesses lie is foundational for anyone working in OT security.

Security angle

The attack surface of an ICS environment spans from internet-facing corporate systems all the way down to field devices, and the risk is that a compromise at the top can cascade toward the bottom.
Many ICS components cannot be patched or replaced on a security timeline, which means network-level controls and access restrictions are the primary security mechanism for the underlying devices.
Anomaly detection in ICS environments works differently from IT. Process behavior follows predictable patterns, and deviations from those patterns are often more meaningful signals than signature-based detections.

Common pitfalls

Assuming that because a SCADA system is not directly internet-facing it is not reachable. Most modern SCADA environments have indirect connectivity through IT networks, vendor access paths, or remote operator connections.
Treating all ICS components as equivalent. A Windows-based HMI can often be hardened using IT methods. A legacy PLC running proprietary firmware cannot, and applying the same approach to both will either leave gaps or cause operational harm.
Underestimating the complexity of ICS environments. These systems often have undocumented configurations, aging hardware, custom software written by engineers who have since left, and integrations nobody fully understands.

DEEP DIVE

▾

The architecture of an ICS environment

ICS environments are typically described using a layered model. At the lowest level are field devices: sensors that measure physical conditions like temperature, pressure, and flow, and actuators that change physical conditions by opening valves, starting motors, and adjusting equipment. These devices are the direct interface between the digital control system and the physical world.

Above the field level sits the control layer, where PLCs and RTUs process inputs from sensors and execute control logic to drive outputs to actuators. This is where the actual control decisions happen. A PLC monitoring a pump station might read a pressure sensor, compare the reading to a setpoint, and send a signal to increase pump speed if pressure has dropped. This logic runs continuously in a tight loop, often with cycle times measured in milliseconds.

At the supervisory level, SCADA systems collect data from many control-layer devices, present it to operators through human-machine interfaces, and provide the ability to send supervisory commands. Above that, historian servers store time-series process data, and enterprise systems use that data for production planning, maintenance scheduling, and business reporting. Each level up the stack is further from the physical process and closer to the IT world, which is why the upper levels tend to have more IT-like characteristics and the lower levels are the most constrained.

SCADA specifically: supervision at geographic scale

SCADA systems were developed to solve a specific problem: how do you monitor and control processes that are spread across hundreds or thousands of kilometers? A pipeline stretching across a continent, a power transmission network covering an entire region, or a water distribution system serving a large city all share the same challenge. You need data from many remote locations, and you need the ability to send commands back to those locations, all in near real time.

Early SCADA systems used serial communication over dedicated telephone lines or radio links to reach remote terminal units at field sites. The RTU would collect local sensor readings and report them back to the central SCADA server on a polling cycle. Operators would see the aggregated data on a control room display and could issue commands when intervention was needed.

Modern SCADA systems use IP-based networks and often run on standard operating systems, which brings capability but also exposure. The same network infrastructure that enables fast, reliable data collection also creates pathways that can be exploited if not properly controlled. The geographic distribution of SCADA systems also creates physical security challenges, since remote sites like substations and pumping stations often have limited physical access controls.

Real incidents and what they reveal

The 2015 and 2016 attacks on Ukrainian power distribution companies are the most thoroughly documented cases of ICS-targeted cyberattacks causing real-world physical effects. In the 2015 incident, attackers used spear-phishing to gain access to corporate IT networks, spent months conducting reconnaissance, and then simultaneously executed coordinated actions against multiple distribution companies. They used legitimate remote access tools to operate SCADA interfaces, opened circuit breakers at substations, and disabled serial-to-Ethernet converters to complicate recovery. Approximately 230,000 customers lost power.

The 2021 Oldsmar water treatment incident, where an attacker briefly gained access to a SCADA system and attempted to increase sodium hydroxide levels to dangerous concentrations, illustrated a different risk: the consequences of unauthorized access to a system controlling chemistry directly affecting public health. An operator noticed the change in real time and reversed it, but the incident revealed that the system was accessible via remote desktop software with minimal authentication controls.

These incidents share a common pattern. Attackers gained initial access through IT-side vectors, moved laterally to systems with reach into the OT environment, and then used legitimate functionality within the ICS to cause harm. The ICS protocols and interfaces themselves were not exploited with novel techniques. What was exploited was the access and the absence of controls that should have limited what an authenticated session could do.

Why ICS security is different from IT security

When a security team patches a vulnerability on an IT server, the process is usually straightforward: test the patch in a staging environment, schedule a maintenance window, apply the patch, verify functionality, and close the ticket. The system might be unavailable for thirty minutes, which is an acceptable operational cost for most IT services.

When the same vulnerability exists on a PLC controlling a continuous industrial process, none of those steps are simple. There may be no staging environment that accurately replicates the production system. The maintenance window may only be available during an annual planned shutdown. The vendor may not have released a patch, or may never release one for that version of firmware. The system may need to be tested and recertified after any change. The operational cost of downtime may be measured in hundreds of thousands of currency units per hour.

This is why the dominant security approach in ICS environments is not patch management but rather compensating controls and defense in depth. You accept that the underlying devices cannot be hardened in the traditional sense, and you instead focus on controlling who can reach them, monitoring what they communicate, and detecting when behavior deviates from what is expected. It is a security model built around the constraints of the environment rather than the ideal state.

Building security into ICS environments

Effective ICS security starts with visibility. Before you can protect a system, you need to know what is in it. Passive network monitoring tools designed for OT protocols can build an asset inventory and baseline the communication patterns of an ICS environment without sending any traffic that could disturb devices. This baseline becomes the reference point for anomaly detection.

Network segmentation is the next foundational control. The Purdue Model and IEC 62443 both provide frameworks for thinking about how to zone an ICS environment and control what can communicate across zone boundaries. At a minimum, the control network should be isolated from the corporate IT network, with only specific, monitored data flows permitted across the boundary through a demilitarized zone or a data diode.

Access control deserves particular attention. Remote access to ICS environments should use dedicated, monitored channels with strong authentication, not general-purpose VPNs or remote desktop tools with shared credentials. Every access session to a control system should be logged and reviewable. Vendor access, which is a common attack path in ICS incidents, should be session-based and require active approval rather than persistent connectivity.