# PLC Security
Programmable Logic Controllers are the embedded industrial computers that translate digital commands into physical action, opening valves, spinning motors, tripping breakers, and regulating temperatures across the systems that keep modern civilization running. PLC security is the discipline of protecting those devices from unauthorized access, logic manipulation, and firmware compromise. It exists because the engineers who designed PLCs in the 1960s and 1970s optimized for determinism and reliability, not confidentiality or integrity. Decades later, those same devices are networked into enterprise environments and exposed to adversaries who understand exactly how much damage a manipulated PLC can cause. The problem PLC security solves is straightforward: preventing a software-layer intrusion from becoming a physical-world disaster.
---
A Programmable Logic Controller is a ruggedized, real-time computing device purpose-built for industrial process control. PLCs execute cyclic scan programs written in IEC 61131-3 languages, including Ladder Diagram, Structured Text, Function Block Diagram, and Instruction List. Each scan cycle reads input registers from sensors, executes control logic, and writes output values to actuators, typically completing this loop in one to one hundred milliseconds.
PLC security encompasses the protection of the device itself, its control logic, its communication interfaces, and its role within a broader Industrial Control System (ICS). It is distinct from general OT (Operational Technology) security, which covers the full range of field devices, historians, HMIs, and supervisory systems. PLC security is also distinct from SCADA security: SCADA systems supervise and collect data, while PLCs execute control. Compromising a SCADA system may disrupt visibility; compromising a PLC can directly alter physical outcomes.
The scope includes authentication mechanisms for programming interfaces, encryption of control logic and communication protocols, integrity monitoring of control programs, and secure firmware update procedures. It covers both legacy PLCs with minimal security capabilities and modern devices with advanced authentication and encryption features. Physical security of programming ports, network segmentation of PLC subnets, and access control for engineering workstations fall within the scope when they directly protect PLC functionality.
PLC security does not include the protection of the engineering workstations used to program PLCs, except where that workstation serves as an attack vector to the PLC itself. It does not address process safety systems (Safety Instrumented Systems, or SIS) as a primary scope, though the two disciplines heavily overlap, particularly after incidents like the TRITON/TRISIS attack on a Schneider Electric Triconex SIS in 2017.
---
PLCs expose attack surface across four dimensions: network protocols, physical ports, firmware interfaces, and control logic itself.
Network Protocols: Most PLCs communicate over industrial protocols designed before cybersecurity was a consideration. Modbus TCP, EtherNet/IP, PROFINET, and DNP3 share a common characteristic: they were built for interoperability between trusted devices on isolated networks. Modbus TCP carries no authentication header whatsoever. Any host that can route a packet to TCP port 502 can read coil registers, write holding registers, and issue function codes. EtherNet/IP uses the Common Industrial Protocol (CIP) and does support authentication in newer implementations, but most deployed configurations leave authentication disabled for compatibility with legacy HMIs. The practical result is that an attacker with network access to the PLC subnet can read process variables and issue control commands without any credential requirement.
Physical Ports: PLCs commonly expose RS-232 serial ports, USB programming interfaces, and unmanaged Ethernet ports. These ports frequently default to full administrative access. An attacker with thirty seconds of physical access can connect a laptop running vendor programming software, download the existing control program, modify it, and upload the altered version with no authentication challenge.
Firmware Interfaces: PLC firmware handles the operating system functions of the device. Firmware updates are delivered via vendor-specific programming software and, in the vast majority of legacy deployments, carry no cryptographic signature verification. An attacker who can supply a malicious firmware image can install a persistent implant that survives logic program changes, survives factory resets of the application layer, and may survive power cycling. The PIPEDREAM (also called INCONTROLLER) framework, disclosed by CISA and DOE in April 2022, included dedicated modules for interacting with Schneider Electric and OMRON PLCs at the firmware and protocol level, demonstrating that nation-state actors have invested in purpose-built tooling for exactly this attack path.
Control Logic: The control program itself is a structured asset with defined behavior. Adversaries who understand the process can make surgical modifications that remain within normal operating ranges for days or weeks before causing failure. A simple example: in a water treatment facility, a PLC controls the dosing pump that adds chlorine to drinking water. An attacker could modify the setpoint register to reduce dosing while simultaneously spoofing the sensor feedback value read by the SCADA historian, making operators believe the process is running normally while under-dosed water reaches distribution.
A typical PLC compromise proceeds through five stages.
Stage 1: Discovery. Adversaries scan ICS networks using tools like Shodan for internet-exposed PLCs or Redpoint/GRASSMARLIN for internal network enumeration. Modbus function code 17 (Report Server ID) and EtherNet/IP identity requests return device model, firmware version, and vendor without authentication. This reconnaissance maps the target environment and identifies exploitable devices.
Stage 2: Access. Using a compromised engineering workstation, a lateral-moved IT endpoint, or a direct network path resulting from flat network architecture, the adversary reaches the PLC's programming port or protocol interface. No credentials are required in most legacy environments.
Stage 3: Logic Extraction. The adversary downloads the existing control program using legitimate vendor software such as Siemens TIA Portal, Rockwell Studio 5000, or Schneider EcoStruxure. This provides full understanding of the process being controlled, setpoints, interlocks, and safety logic.
Stage 4: Logic Modification or Firmware Replacement. The adversary modifies the program, uploads an altered version, or replaces firmware with a malicious image. Modifications may be designed to trigger on a specific date, a specific process condition, or an external command.
Stage 5: Execution. The modified PLC executes attacker-defined behavior during normal operation. Operators may observe nothing abnormal until equipment fails, product quality degrades, or a safety threshold is crossed.
Modern PLC security implementations fall into four categories: preventive, detective, responsive, and recovery controls.
Preventive Controls include access authentication, encrypted communications, role-based authorization, and network segmentation. Siemens S7-1500 PLCs support TLS 1.3 encryption and certificate-based authentication. Allen-Bradley ControlLogix 5580 controllers include role-based access with granular permissions for read, write, and configuration operations. These controls prevent unauthorized access but require proper configuration and may impact real-time performance if improperly implemented.
Detective Controls monitor for unauthorized changes to control logic, unexpected network communications, and anomalous process behavior. Nozomi Networks and Claroty platforms provide passive monitoring that compares current PLC program state to baseline configurations. Dragos and CyberX platforms analyze industrial protocol traffic for unauthorized function codes or suspicious read/write patterns.
Responsive Controls include automated incident response workflows, emergency shutdown procedures triggered by security events, and isolation capabilities that can quarantine compromised PLCs from the broader network. Modern industrial firewalls like those from Hirschmann and Tofino include protocol-aware rules that can block specific Modbus function codes or DNP3 control operations in real time.
Recovery Controls encompass backup and restore procedures for control logic, firmware rollback capabilities, and disaster recovery planning that accounts for physical equipment damage caused by cyberattacks. These controls require offline storage of known-good configurations and tested procedures for rapid restoration.
---
The consequence of a compromised PLC is not a data breach. It is a physical event: a pipeline rupture, a chemical spill, a power outage, or contaminated water reaching consumers. This distinction places PLC security in a category where the acceptable risk threshold is categorically lower than in enterprise IT.
Business Impact: Unplanned process shutdowns caused by PLC compromise cost industrial operators between $50,000 and $500,000 per hour in lost production, depending on sector. Recovery from a destructive PLC attack that damages physical equipment extends downtime from hours to weeks, because replacement PLCs must be procured, programmed with verified logic, and commissioned before production resumes. The 2015 attack on Ukraine's power grid, which used compromised PLCs to open breakers and disable protective relays, caused outages affecting 230,000 customers and required manual restoration at dozens of substations.
Safety Impact: The TRITON/TRISIS attack in 2017 targeted the Safety Instrumented System at a petrochemical facility in Saudi Arabia. The attackers sought to disable the SIS so that a simultaneous attack on process PLCs could cause a fire or explosion without triggering emergency shutdown. The attack was discovered only because a logic error caused a plant trip, which prompted investigation. That logic error prevented mass casualties. The attack revealed that sophisticated adversaries specifically plan to defeat safety layers before executing destructive physical attacks.
Regulatory and Compliance Consequences: Critical infrastructure sectors face mandatory reporting requirements for cybersecurity incidents affecting operational technology. TSA Pipeline Security Guidelines require pipeline operators to implement specific cybersecurity measures for control systems. NERC CIP standards mandate access control, monitoring, and incident response capabilities for electric utility PLCs. Failure to implement adequate PLC security can result in regulatory penalties, increased oversight, and potential legal liability if inadequate security contributes to public harm.
Common Misconception: Air Gaps Are Sufficient: Many industrial operators believe their PLCs are protected because they are "air-gapped" from the internet. Stuxnet disproved this assumption definitively. Stuxnet spread via USB drives, infected engineering workstations, and crossed the air gap through normal engineering workflow. Modern OT environments are rarely air-gapped in practice: remote access connections, vendor maintenance laptops, historian links to corporate networks, and wireless enabled devices all create paths into supposedly isolated networks.
Common Misconception: Obscurity Is Security: Operators sometimes assume that proprietary protocols and custom logic make their PLCs difficult targets. PIPEDREAM/INCONTROLLER contained vendor-specific modules targeting Schneider Electric, OMRON, and OPC UA servers, demonstrating that adversaries invest in reverse engineering proprietary protocols when the target is valuable enough.
---
CDA approaches PLC security through the Planetary Defense Model, with PLCs classified under the Vital Systems Defense (VSD) domain. VSD governs the protection of systems where compromise produces consequences that extend beyond organizational boundaries into public safety, national infrastructure, or irreversible physical harm.
CDA's methodology for VSD is Continuous Surface Reduction (CSR): "Every surface you expose is a surface we eliminate." Applied to PLCs, CSR operates across four layers.
Protocol Surface Reduction: CDA begins every PLC engagement by enumerating all active protocol listeners on each PLC using passive network capture and active protocol interrogation. Every open port and every active function code that is not operationally required is documented and, where device configuration permits, disabled. On devices where disabling is not possible due to firmware limitations, compensating controls including protocol-aware firewall rules at the network layer are implemented to drop unauthorized function codes before they reach the device.
Authentication Surface Reduction: CDA audits PLC authentication configuration against vendor capability. For devices supporting role-based access control, CDA deploys and enforces configuration: read-only accounts for HMIs, write accounts restricted to engineering workstations by IP and MAC binding, and administrative access requiring two-person authorization workflow. For devices with no authentication capability, CDA documents the gap formally and implements compensating network controls.
Logic Integrity Monitoring: CDA deploys continuous control logic comparison as a detective control. Baseline logic images are cryptographically hashed and stored in a defended repository. Automated monitoring compares live PLC program state to baseline on a defined interval. Any deviation triggers an alert classified as a Severity 1 event, requiring immediate investigation before the PLC is returned to service. This capability directly addresses the attack stage where adversaries upload modified logic.
Firmware Chain of Trust: For modern PLCs with firmware signing capability, CDA enforces signature verification and maintains a registry of approved firmware versions per device model. For legacy devices without signing, CDA implements change control procedures that require documented authorization before any firmware operation is performed and physical access logging for all programming port connections.
CDA does not treat PLC security as a point-in-time assessment. The threat model for industrial environments includes persistent access by patient adversaries, and periodic assessments create windows of unknown compromise. CSR is continuous by design.
---
---
---