What are ICS and SCADA?
Industrial Control Systems (ICS) is the broad term for the cyber-physical systems that monitor and control industrial processes. Every automated process that moves product through a factory, maintains pressure in a pipeline, treats water before it reaches a tap, or distributes power across a grid runs on some form of ICS. These systems are embedded in the physical world in a way that standard IT systems are not: their outputs are not bytes on a screen but physical actions—open valves, started motors, applied heat, released chemicals.
SCADA (Supervisory Control and Data Acquisition) is a category within ICS. While ICS is the umbrella term for all control systems, SCADA specifically refers to systems designed for monitoring and controlling geographically distributed processes from a central location. A pipeline SCADA system may monitor hundreds of remote pump stations and compressor sites from a single operations center. A power utility SCADA may supervise dozens of substations across a state. The defining characteristic of SCADA is the combination of remote data acquisition from field sensors and centralized supervisory control over remote equipment.
ICS and SCADA are not the only component types in the category. Understanding the full component set is essential for understanding what the security discipline must protect.
ICS/SCADA system components
💻
Purdue Level 1
PLC (Programmable Logic Controller)
A ruggedized industrial computer that executes control logic in real-time scan cycles, typically 1-100 ms. PLCs directly command actuators, motors, valves, and drives based on sensor inputs and programmed logic. They are the most direct interface between cyber and physical: a compromised PLC can issue unauthorized physical commands. Most were designed without authentication, encryption, or the ability to run security agents.
📡
Purdue Level 1
RTU (Remote Terminal Unit)
Similar to a PLC but designed for remote or harsh environments where power and communication bandwidth are constrained. RTUs collect sensor data from geographically dispersed field equipment and communicate it back to a central SCADA host. Common in pipelines, power distribution, and water systems. Often communicate over low-bandwidth serial or cellular links using protocols like DNP3 or Modbus.
🖥️
Purdue Level 2
HMI (Human-Machine Interface)
The operator console that displays process state and accepts operator commands. HMIs are typically Windows-based workstations running specialized SCADA software. They sit at Level 2 and connect upward to historians and MES and downward to PLCs and DCS. HMIs are high-value targets because they have both network connectivity and the ability to issue control commands: a compromised HMI can manipulate processes without requiring access to the PLC firmware directly.
🏭
Purdue Level 2
DCS (Distributed Control System)
A control system that distributes control logic across multiple controllers embedded throughout a process plant, coordinated by a central supervisory layer. DCS is typical in continuous process industries like chemical, refining, pulp and paper, and power generation. Unlike PLCs (which often control discrete functions), DCS coordinates multiple interdependent process loops across a large facility. A single DCS may manage thousands of control loops simultaneously.
⚡
Purdue Levels 0-1
SIS (Safety Instrumented System)
A dedicated safety system designed to bring a process to a safe state if process variables exceed predefined limits. SIS is independent of the basic process control system (DCS/PLC) and must maintain that independence for safety integrity. Triton/TRISIS, the most dangerous ICS-specific malware ever deployed, specifically targeted SIS controllers to disable safety shutdowns, potentially enabling a catastrophic process upset that the safety system would normally prevent.
📊
Purdue Level 3
SCADA / Historian
The supervisory layer that collects real-time data from PLCs and RTUs, provides centralized process visibility, and enables remote control. Historians at Level 3 archive time-series process data for trend analysis, regulatory reporting, and predictive maintenance. Historians are a common attack vector because they sit at Level 3 but may have connections to both the OT zone below and the enterprise network above, creating a potential IT-to-OT pathway if not properly controlled through an iDMZ.
ICS vs SCADA: how they relate
ICS and SCADA are frequently used interchangeably, but they have distinct scopes. Understanding the distinction matters for security because the threat landscape and applicable controls differ between them.
Broad category
ICS (Industrial Control Systems)
| Scope | All systems that control industrial processes: PLCs, DCS, SCADA, RTUs, SIS, HMIs, and the networks connecting them. |
| Geography | May be co-located within a single plant or distributed across many sites. |
| Communication | Uses both fieldbus protocols (Profibus, DeviceNet) at lower levels and Ethernet-based protocols (EtherNet/IP, Modbus TCP, OPC UA) at higher levels. |
| Security focus | Device hardening, network segmentation, access control, firmware integrity for PLCs and DCS controllers. |
Specific subcategory
SCADA
| Scope | Supervisory control and monitoring of distributed processes from a central operations center. |
| Geography | Always distributed. SCADA is used when remote sites require centralized supervision: pipelines, power grids, water/wastewater. |
| Communication | Uses protocols designed for wide-area communication: DNP3, Modbus RTU/TCP, IEC 60870-5-104, IEC 61850. Often over serial, radio, cellular, or leased lines. |
| Security focus | Communication path security, remote access controls, DNP3 Secure Authentication, monitoring for unauthorized commands from the SCADA master. |
The landmark attacks that defined ICS security
ICS security became a recognized discipline through a series of high-profile attacks that demonstrated that industrial systems were vulnerable, that the consequences could be catastrophic, and that adversaries had both the capability and the intent to target them. These attacks shaped threat modeling, regulatory responses, and product security design for the decade that followed.
2010
Stuxnet
The first publicly confirmed cyber weapon designed to cause physical destruction. Stuxnet targeted Siemens PLCs controlling centrifuges at Iran's Natanz nuclear enrichment facility. It used four zero-day exploits to propagate via USB, spread across Windows networks, and ultimately modify PLC code to sabotage centrifuge operation while reporting normal operation to operators. Stuxnet proved that well-resourced adversaries could penetrate air-gapped networks and weaponize control logic to destroy equipment.
Air gaps are not sufficient isolation
2015
Ukraine power grid (BlackEnergy)
Attackers compromised multiple Ukrainian electric utilities, gained access to HMI workstations, and used legitimate remote access tools to manually open circuit breakers at substations, cutting power to 225,000 customers. The attack demonstrated that adversaries could gain persistent access to utility SCADA networks and use legitimate control interfaces to directly manipulate the process. Recovery took six hours and required manual operations.
Remote access is the primary initial entry vector
2016
Ukraine power grid (Industroyer/CrashOverride)
A second, more sophisticated attack against Ukraine's grid used ICS-specific malware that directly communicated using IEC 60870-5-104 and IEC 61850 SCADA protocols. Unlike the 2015 attack (which used HMI interfaces), this malware operated at the protocol level, issuing trip commands to protection relays. This demonstrated that adversaries understood substation communication protocols well enough to write native ICS malware that bypassed the HMI layer entirely.
Protocol-level attacks do not require HMI access
2017
Triton/TRISIS
The first known attack against a Safety Instrumented System (SIS). Attackers gained access to the engineering workstation used to program Triconex SIS controllers at a petrochemical plant in Saudi Arabia and deployed custom malware designed to reprogram the safety logic. If successful, the attack could have disabled emergency shutdown systems, potentially enabling a catastrophic process event. The attack was discovered only because it inadvertently caused the SIS to fail into a safe state, shutting down the plant.
Safety systems are not immune from targeted attacks
2021
Colonial Pipeline
A ransomware attack against Colonial Pipeline's IT network led to a precautionary shutdown of the 5,500-mile fuel pipeline supplying the U.S. East Coast. While the ransomware did not directly compromise OT systems, the company shut down operations because IT systems required for safe operation (billing, scheduling, inventory management) were unavailable. The attack caused fuel shortages, panic buying, and federal emergency declarations.
IT/OT interdependence means IT attacks can halt operations
2023
Utilities Water Authority breach
Iranian-linked threat actors compromised an HMI at a Pennsylvania water utility using default credentials, allegedly altering pumping settings. The incident was one of dozens targeting U.S. water and wastewater systems throughout 2023, demonstrating that critical infrastructure operators often fail to implement basic access control hygiene (changing default passwords, multi-factor authentication, network segmentation).
Default credentials remain a persistent weakness
MITRE ATT&CK for ICS: the adversary behavior framework
MITRE ATT&CK for ICS is a knowledge base of tactics and techniques observed in real-world attacks against industrial control systems. It provides a common vocabulary for describing adversary behavior in OT environments and serves as the foundation for threat hunting, red teaming, and defensive architecture planning. Understanding the tactics gives defenders a structured way to think about what adversaries can do once they gain access to an ICS network.
Exploit public-facing apps, spearphishing, removable media, supply chain compromise
Modify control logic, change operating mode, modify program, system firmware
Masquerading, rootkit, modify alarm settings, spoof reporting messages
Network sniffing, remote system discovery, control system device ID, point & tag ID
Exploitation of remote services, default credentials, VNC/RDP to HMI workstations
Automated collection of process data, historian queries, point enumeration
Manipulation of control, loss of view, denial of service, damage to property
TA0101
Impair Process Control
Brute force I/O, modify setpoints, unauthorized command, activate firmware update mode
Why this matters: ATT&CK for ICS gives defenders a way to map observed indicators to adversary intent. If you see an attacker enumerating all OPC tags from a Level 3 server (Discovery), you can anticipate that Impact or Impair Process Control tactics may follow. This enables defenders to prioritize containment actions based on likely next moves rather than waiting for damage.
Defense-in-depth controls for ICS/SCADA environments
ICS security cannot rely on a single control. Defense-in-depth layering means that if one control fails, others remain in place to detect, delay, or prevent adversary success. The following eight control categories represent the minimum expected baseline for protecting operational technology environments.
Asset inventory
Maintain a complete inventory of all OT assets
You cannot defend what you do not know exists. Asset discovery tools (Claroty, Dragos, Nozomi) passively enumerate devices on OT networks. Inventory must include device type, firmware version, network address, communication protocols, vendor, installed location, and responsible personnel. This is Foundational Requirement (FR) 1 in IEC 62443-3-3.
Segmentation
Implement network segmentation and zone isolation
Separate OT networks from IT networks with firewalls and enforce Purdue Model segmentation between levels. Use conduits (iDMZ architecture) to control IT/OT data flows. Deny-all default firewall rules with explicit allow rules for necessary connections only. This prevents lateral movement and limits blast radius if one zone is compromised.
Hardening
Harden OT devices and disable unnecessary services
Disable unused ports and protocols on switches, PLCs, and HMIs. Remove or disable default accounts. Use application whitelisting to prevent unauthorized code execution on Windows-based HMI and engineering workstations. Deploy endpoint detection and response (EDR) on Level 2 and Level 3 systems where agent deployment is feasible.
Access control
Enforce least-privilege access and multi-factor authentication
Require MFA for all remote access, all VPN connections, and all jump server sessions. Role-based access control (RBAC) should limit which personnel can modify control logic, adjust setpoints, or issue commands. Session recording and logging are mandatory for accountability. Zero-trust principles apply in OT as much as in IT.
Monitoring
Deploy OT-aware monitoring and anomaly detection
Passive network monitoring using OT-specific tools (not general-purpose IDS) to detect unauthorized commands, protocol anomalies, firmware changes, and unexpected traffic patterns. Integrate OT monitoring with SIEM to correlate IT-side and OT-side indicators. Alerting on unauthorized access to safety systems (SIS) should be treated as highest-priority incidents.
Patch mgmt
Establish a risk-based patching strategy
OT systems cannot follow IT patch cadences because production availability is the primary constraint. Patch management must be risk-based: critical vulnerabilities with active exploitation get priority, lower-risk issues can be deferred to planned outages. Test patches in a lab environment that mirrors production before deployment. Use virtual patching (firewall rules or IPS signatures) when direct patching is not feasible.
Remote access
Control and monitor vendor remote access
Vendor remote access is one of the most exploited pathways into OT networks. Require all vendor access to go through jump servers or privileged access management (PAM) solutions. Sessions must be time-limited, logged, and monitored in real time. VPN credentials should not grant direct OT access; they should terminate in a DMZ or jump host where session activity is recorded.
Incident response
Maintain an OT-specific incident response plan
IT incident response playbooks do not translate directly to OT. Responders must understand the physical consequences of response actions: isolating a PLC may shut down a process; rebooting an HMI may interrupt operator visibility during a critical process state. The incident response plan must include engineering, operations, and safety personnel, not just IT security.
How SWTB products reduce ICS/SCADA attack surface
Software Toolbox connectivity products are designed to reduce attack surface at the OT data layer by eliminating the need for direct IT-to-OT connections, closing inbound firewall ports, and providing secure alternatives to insecure legacy protocols like DCOM. Each product implements a specific security principle.
Connectivity
TOP Server: Secure OPC aggregation in the OT zoneTOP Server consolidates device connectivity within the OT network (Level 3), exposing data as OPC DA and OPC UA rather than requiring each IT application to connect directly to dozens of individual PLCs. This reduces the number of systems that require firewall exceptions and limits which protocols must cross security boundaries. TOP Server also supports OPC UA security policies (Basic256Sha256, encryption, application certificates) for secure OT-to-IT data transfer.
Segmentation
Cogent DataHub: Outbound-only iDMZ tunnelingDataHub implements the CISA-recommended pattern of outbound-only connections from OT to IT. The OT-side DataHub instance initiates an encrypted tunnel to the iDMZ-hosted instance; no inbound port on the OT-facing firewall is required. This prevents IT systems from initiating connections into the OT zone and eliminates the need for inbound firewall rules. DataHub also supports data diode mode for hardware-enforced unidirectional data transfer.
Tunneling
DataHub OPC tunneling: Eliminate DCOM exposureOPC DA over DCOM is a well-known attack vector because DCOM requires dynamic port ranges, makes firewall rule management complex, and has a history of exploitable vulnerabilities. DataHub tunneling replaces DCOM with TCP-based encrypted tunnels, allowing OPC DA clients to access OT-side OPC servers without opening DCOM ports or exposing RPC services on OT networks. This is one of the most common ICS security hardening actions.
Edge isolation
N3uron: Edge processing with local autonomyN3uron edge nodes at Level 2 can pre-process, filter, and contextualize data locally before publishing to an iDMZ-hosted MQTT broker. This reduces the volume of data crossing the OT/IT boundary, minimizes the bandwidth and exposure of OT devices, and allows edge nodes to continue operating locally even if connectivity to the central broker is lost. Edge autonomy is a key defense-in-depth principle for geographically distributed SCADA systems.
Data routing
OPC Router: Auditable IT/OT data flowsOPC Router creates explicit, visually documented data routing workflows between OT sources (OPC servers, MQTT brokers, PLCs) and IT consumers (databases, cloud platforms, ERP). Its workflow model makes IT/OT data flows auditable, which is required for IEC 62443 zone and conduit documentation. Each connection is explicitly defined and logged, providing the transparency needed for security audits and regulatory compliance.
Frequently asked questions
Why can't we just apply IT security practices to OT systems?+−
IT and OT have fundamentally different priorities. In IT, confidentiality is typically the highest priority: preventing unauthorized access to data. In OT, availability is the highest priority: keeping processes running safely. You cannot reboot a PLC controlling a chemical reactor mid-batch to apply a security patch. You cannot isolate a safety instrumented system from the network during an incident response because doing so may disable emergency shutdown capability.
Additionally, many OT devices were designed 10–20 years ago before cybersecurity was a primary design consideration. They lack the processing power to run security agents, do not support modern authentication mechanisms, and use proprietary or legacy protocols that cannot be updated. Security in OT must work around these constraints rather than assuming devices can be patched or replaced.
What is IEC 62443 and why does it matter for ICS security?+−
IEC 62443 is the international standard for securing industrial automation and control systems. It defines security levels (SL1 through SL4) based on the consequence of a successful attack, assigns foundational requirements (FRs) for each level, and provides a framework for implementing defense-in-depth across the Purdue Model zones. Compliance with IEC 62443 is becoming a contractual requirement for system integrators and equipment vendors in many industries.
For asset owners, IEC 62443-3-3 defines the system requirements: network segmentation, access control, data integrity, and event logging. For product vendors, IEC 62443-4-1 and 4-2 define secure development lifecycle requirements and product certification criteria. Understanding 62443 is essential for aligning security investments with a globally recognized baseline.
How do I secure legacy PLCs and RTUs that cannot be patched or upgraded?+−
When the device itself cannot be secured, the strategy shifts to securing the network around it. Place legacy devices on isolated network segments with deny-all firewall rules that permit only the specific communications required for operations. Deploy passive network monitoring to detect anomalous commands or configuration changes. Use protocol inspection firewalls or industrial application firewalls (e.g., Tofino, Claroty) that understand industrial protocols and can enforce deep packet inspection rules.
For devices that require remote access, implement jump servers or privileged access management (PAM) solutions that terminate sessions and log all activity. If a device uses default credentials that cannot be changed, document this in the risk register, monitor it continuously, and ensure that physical access to the device is tightly controlled.
What is the difference between IT threat intelligence and OT threat intelligence?+−
IT threat intelligence focuses on malware signatures, IP reputation lists, phishing campaigns, and vulnerabilities in enterprise software (Windows, Office, web browsers). OT threat intelligence focuses on adversaries with the capability and intent to target industrial processes: nation-state actors, insider threats, and hacktivists. It tracks vulnerabilities in PLCs, DCS controllers, HMIs, and industrial protocols (Modbus, EtherNet/IP, OPC, DNP3).
OT threat intelligence also tracks adversary techniques documented in MITRE ATT&CK for ICS, emerging ICS-specific malware families (Industroyer, Triton, FrostyGoop), and indicators of compromise (IOCs) observed in industrial environments. Vendors like Dragos, Claroty, and Mandiant provide OT-focused threat intelligence feeds that integrate with OT monitoring platforms and SIEMs.
Do I need an air gap or is network segmentation sufficient?+−
Air gaps (complete physical separation with no network connection) are required for only the most critical safety systems (SIS at safety integrity level SIL 3 or SIL 4) and certain classified or defense applications. For most industrial facilities, properly implemented network segmentation with dual firewalls (iDMZ architecture), strict access controls, and monitoring is sufficient and more operationally practical than an air gap.
Air gaps also have limitations: USB drives and removable media can still bridge them (as Stuxnet demonstrated), and many "air-gapped" networks are not truly isolated—they have temporary connections for data export, vendor remote access, or software updates. If you claim an air gap, audit it regularly to ensure it remains intact and that no undocumented bridges have been introduced.
How do I justify ICS security investment to management when we haven't been attacked?+−
Frame ICS security as operational risk management, not just cyber risk. An unplanned production outage caused by a ransomware incident costs the same whether it originated from malice or negligence. Calculate the cost of unplanned downtime (lost production, overtime labor, expedited shipping, contract penalties) and present security investments as downtime avoidance measures. Many executives respond more strongly to "this could halt production for 3 days" than to "this could result in a data breach."
Additionally, regulatory and insurance drivers are increasing. NERC CIP for electric utilities, TSA Security Directives for pipelines, EPA requirements for water systems, and the SEC cyber disclosure rules all mandate certain ICS security controls. Cyber insurance underwriters are requiring ICS-specific security controls before issuing or renewing policies. Compliance and insurability are business requirements, not optional IT projects.
Getting started with ICS/SCADA security
The most effective starting point for any organization new to ICS/SCADA security is a passive asset inventory of the OT network. Deploy a SPAN port or network tap and use an OT-aware tool (Claroty, Dragos, Nozomi, or similar) to enumerate every device, every protocol, and every communication path. You will almost certainly discover devices and connections you did not know existed. That inventory is the prerequisite for every control that follows.
Second, eliminate direct IT-to-OT network paths. Implement an industrial DMZ (iDMZ) with dual firewalls and explicit rules. Use outbound-only data transfer mechanisms like Cogent DataHub tunneling so OT systems initiate all connections and no inbound ports need to be opened on the OT-facing firewall. This single architectural change addresses the root cause of the majority of IT-to-OT propagation incidents.
Software Toolbox has been implementing secure OT connectivity architectures for decades. Whether you are replacing DCOM with OPC tunneling, building a UNS with iDMZ-compliant MQTT, or need to audit and document every data flow crossing your IT/OT boundary, our engineering team can help you design and deploy an architecture that meets both operational and security requirements.
