ICS Protocol Architecture and Security

When the Protocol Is the Weapon

In April 2022, CISA, the FBI, the NSA, and the Department of Energy issued a joint advisory about a toolkit unlike anything the ICS security community had publicly documented before. It did not exploit a software vulnerability. It did not target Windows, it did not require a firmware flaw, and it did not need a zero-day. It used Modbus, Codesys, and OPC UA -- the protocols that PLCs were built to understand -- to issue commands directly to industrial devices. A module sent FC3 read commands and FC16 write commands to Schneider Electric Modicon relays. The commands were syntactically identical to what a legitimate engineer sends every day. No CVE scanner would flag them. No signature-based IDS would raise an alert. The toolkit, called PIPEDREAM, was discovered before it was deployed in a live attack. Chapter 3 introduced the protocols that run on industrial networks: what Modbus is, where DNP3 is deployed, how OPC Classic and OPC UA differ structurally. This chapter examines those same protocols from the defender's perspective -- what makes them structurally unauthenticated, what that means for the traffic a defender can read, why OPC Classic's architecture creates a specific firewall problem, what OPC UA's security specification actually requires to function, and what PIPEDREAM demonstrated about the only detection surface available when an attacker uses legitimate protocol commands.

The Protocol as an Attack Surface

Industrial protocols exist in two tiers. At the field level, Modbus, DNP3, PROFIBUS, and IEC 61850 carry small, high-frequency packets between sensors, actuators, PLCs, and RTUs -- the raw process data that the control system depends on. At the plant level, EtherNet/IP and OPC/OPC UA carry that data upward to SCADA servers, historians, and operator interfaces. The tier structure matters for defenders because it defines what traffic belongs on each segment of the network. A field-level protocol appearing in traffic where it has no operational reason to exist is an anomaly before any content analysis is required. Every industrial protocol was designed by engineers with one priority: keep the process running. Security was not part of the specification brief for Modbus in 1979 or DNP3 in the 1990s. The networks they ran on were physically isolated, and isolation was considered sufficient. Three consequences follow from that design history. First, none of the original field-level protocols has authentication -- any device that can form a valid protocol message can command a PLC without presenting any credential. Second, the commands are not encrypted or obfuscated; every transaction declares its intent in plain text. Third, these properties are structural, not configurable. You cannot add authentication to a deployed Modbus network by enabling a setting. The compensating controls are at the network layer -- DPI firewalls that enforce function code restrictions at conduit boundaries, as covered in Chapter 9, and passive monitoring that uses protocol transparency to its advantage. Protocol literacy is the skill that makes both of those controls work: knowing what traffic is expected makes the unexpected visible.

Reading Modbus: What Every Packet Declares

A Modbus TCP packet has a fixed structure that a defender can read at a glance. The MBAP header carries four fields: a Transaction ID that pairs requests to responses, a Protocol ID that is always zero for Modbus, a Length field, and a Unit ID that identifies the target device on a serial segment. Below the header sits the Protocol Data Unit, which contains a single-byte function code naming the operation and a data field carrying the register addresses and values. The function code is the most important field in the packet. FC1 reads discrete coil states -- valve positions, motor status, relay outputs. FC3 reads holding registers -- the numeric values representing temperatures, pressures, flow rates, and setpoints. FC5 writes a single coil, changing one output state. FC16 writes multiple holding registers, pushing new setpoints or control parameter values into the PLC. FC16 is the write command. Every FC16 transaction in Modbus traffic represents a change being made to the physical process. In a normally operating plant, FC16 commands are rare, come from a small number of known engineering workstations, and appear only during documented maintenance windows. That predictability is the baseline. Normal Modbus sessions look like this: the same source IP polling the same PLC address at regular intervals, requesting the same register ranges, using FC3 reads almost exclusively. Anomalous traffic breaks the pattern in identifiable ways -- an FC16 command from a source that has never sent a write before, register addresses outside the documented range for the device, polling that starts at an unusual hour, or request rates that spike without a maintenance window open. None of those anomaly flags require deep packet analysis. They require knowing what normal looks like, which means someone must document it.

The Open Book That Works Both Ways

The same design decision that makes Modbus impossible to authenticate also makes it impossible to hide. Every transaction declares its intent in plain text. A defender who documents the expected sources, the expected function codes, and the expected register ranges for each PLC in the network can implement monitoring rules that flag deviations with straightforward logic -- no deep analysis engine required. The attacker who uses Modbus to send commands to a PLC cannot make the traffic opaque. They can only hope the defender has not done the documentation work. PIPEDREAM's Modbus module sent FC16 commands to Schneider Electric Modicon relays. From a protocol parsing perspective, those commands were indistinguishable from legitimate engineering activity. From a behavioral perspective -- wrong source IP, wrong time of day, wrong frequency -- they were immediately visible to any monitoring system that knew the baseline. The protocol does not hide the attacker. The attacker hides only inside the gap between what is expected and what has been documented as expected. Closing that gap is the defensive work that protocol literacy enables.

OPC Classic and the Firewall Problem

In the mid-1990s, every ICS vendor maintained proprietary drivers for data exchange. Connecting a Siemens PLC to a Wonderware SCADA system required custom code on both sides, maintained separately, broken by every firmware update. OPC Classic solved this by defining a standard software interface: any device with an OPC server and any application with an OPC client could exchange data without vendor-specific code. It ran on Windows using Microsoft's Component Object Model/Distributed COM framework -- DCOM -- which was the standard mechanism for inter-process communication at the time. The firewall problem is architectural. DCOM communication begins on TCP port 135, where an endpoint mapper service handles the initial handshake. The client requests the port where the OPC server is listening. The server names a port -- chosen dynamically from the unprivileged range, which begins at 1024 and extends to 65535. The actual data exchange moves to that negotiated port. A traditional firewall writing rules for specific ports cannot follow this negotiation. The workaround -- opening the entire 1024-65535 range to permit OPC Classic traffic -- transforms a firewall into a device that filters almost nothing meaningful. Two intermediate solutions reduce the exposure without requiring migration. An OPC Classic-aware firewall understands the DCOM state machine; it follows the port negotiation, opens only the specific port assigned to that session, and closes it when the session ends. An OPC tunneling application wraps the entire OPC Classic exchange inside a single fixed TCP connection, making it appear as a normal, rule-friendly protocol from the firewall's perspective. Neither solution eliminates the underlying architecture or the operational complexity of managing it. Migration to OPC UA eliminates the problem.

OPC UA: Security in the Specification

OPC UA eliminated DCOM entirely. It runs on TCP/IP with a single configurable port -- no dynamic negotiation, no endpoint mapper, no unpredictable port range. It is cross-platform, operating on Linux, embedded systems, and non-Windows environments. Siemens and Rockwell have implemented OPC UA directly in PLCs and field devices, meaning the interoperability layer can run where the data originates rather than on a separate Windows server. The security specification is part of the OPC UA standard itself, not an extension. Six capabilities are defined. Encryption protects message content from eavesdropping during transit. Message signing applies digital signatures to detect tampering between sender and receiver. Sequenced packet numbering prevents replay attacks by making each message uniquely ordered in the session. X.509 certificate authentication allows clients and servers to verify each other's identity cryptographically, removing the dependency on shared passwords. User access control assigns specific permissions to individual users on each server, not just at the session level. Auditing records user and system actions in a tamper-evident log. OPC UA also exposes a browsable information model -- a hierarchy of folders, objects, and methods that describes everything the server makes available. An authorized client can enumerate this hierarchy and see precisely what data the server publishes and what operations it accepts. A defender can use that same enumeration capability to document what a legitimate OPC UA connection should request and flag anything outside that scope. These security capabilities are in the protocol specification, which means they are available in any compliant implementation. That is different from being active by default. Security modes must be configured: OPC UA supports a no-security mode, a sign-only mode, and a sign-and-encrypt mode, and many deployments default to the lowest mode for compatibility reasons. Certificates must be issued by a PKI that someone manages and maintains. User permissions must be defined and reviewed. OPC UA is where security became possible in industrial communication. Using it requires the same governance discipline as any other security control.

Protocol Literacy as a Detection Capability

PIPEDREAM is the clearest answer to why OT defenders need protocol literacy. If you know that normal Modbus traffic on PLC 4 comes from two engineering workstations, runs FC3 reads every five seconds, and never includes an FC16 write outside a documented maintenance window -- then an FC16 write from an unknown source at two in the morning is immediately visible before any threat intelligence is consulted. That detection does not require a commercial OT monitoring platform, though those platforms make it automated and scalable. It requires knowing what the protocol does, knowing what normal looks like in your environment, and having a monitoring system that can flag deviations. A DPI firewall at the conduit boundary, as covered in Chapter 9, can enforce that FC16 writes are permitted only from the authorized engineering workstation IPs -- blocking unauthorized writes before they reach the PLC. Passive monitoring downstream can detect any traffic pattern that deviates from the documented baseline even when DPI enforcement is not in place. The two controls work together: enforcement at the boundary, detection everywhere else. An attacker using legitimate protocol commands is making a bet that you have not documented your baseline. Building that baseline -- what sources, what function codes, what register ranges, what timing -- is the protocol security work that no tool can do for you. It is also the work that makes every subsequent control more effective.

What's Next

Chapter 11 examined the security properties of the protocols running on industrial networks: the structural unauthentication that cannot be patched away, the transparency that benefits defenders as much as it exposes operators, the DCOM architecture that makes OPC Classic incompatible with modern network segmentation, the security specification in OPC UA that requires active configuration to engage, and the PIPEDREAM toolkit that demonstrated protocol literacy as the only reliable detection surface against a protocol-native attack. Chapter 12 moves to the formal methodology for turning all of this security knowledge into a documented, auditable risk assessment: the IEC 62443-3-2 Zone and Conduit Risk assessment process, the System Under Consideration, the security level types, and the foundational requirements that give each zone a specific, measurable protection target.

Reflect

• PIPEDREAM's Modbus module was behaviorally detectable -- unexpected source, unusual timing, wrong command sequence -- but not technically detectable by vulnerability or signature analysis. For the most critical PLC in your environment, is there a documented baseline of expected Modbus sources, function codes, register ranges, and timing windows? If that device received an FC16 write from a new source at 2 AM, would any monitoring system currently in place alert on it?
• The OPC Classic firewall problem reduces to a choice: OPC Classic-aware firewall, OPC tunneling, or migration to OPC UA. For any OPC Classic deployment in your environment, which option is in place, and is the current state an intentional architecture decision or an inherited configuration nobody has reviewed?
• OPC UA's six security features are in the specification but require active configuration. For any OPC UA server in your environment, what security mode is it running (no-security, sign, or sign-and-encrypt)? Who issued and maintains the X.509 certificates? Are user permissions defined at the individual level or at the session level?
• The chapter establishes that protocol literacy is a detection capability, not just an engineering skill. For the most common protocol on your control network, could you describe what a normal session looks like -- source, destination, function codes used, timing -- well enough to write a monitoring rule that flags deviations? If not, what would it take to build that baseline?