Category: ICS/OT Security
Difficulty: Beginner-Intermediate
Reading Time: 14 minutes
Introduction: A Brief History of Misplaced Trust
In the beginning, there were industrial networks, and they were air-gapped, and it was good. Engineers designed protocols to move data between controllers and sensors efficiently and reliably, and they did not bother with authentication, encryption, or any of that paranoid nonsense, because the network was physically isolated. The only people who could send a Modbus command were the people standing in the control room, and they had badges and hard hats.
Then someone connected these networks to the corporate LAN. Then someone connected the corporate LAN to the internet. Then everyone involved in the original protocol design developed a collective stress disorder.
This article covers the major protocols used in Industrial Control Systems, why they were designed the way they were, what that means for security, and why a surprising amount of critical infrastructure is controlled by protocols that would struggle to pass a first-year computer science security audit.
Modbus: The Grandfather of Industrial Protocols
What It Is
Modbus was developed by Modicon (now Schneider Electric) in 1979. To put that in context, that is the year Margaret Thatcher became Prime Minister, Sony released the Walkman, and the most sophisticated cyber threat was someone guessing your mainframe password.
Modbus is beautifully simple. It operates on a master-slave architecture (now more commonly called client-server). The master device sends requests, and slave devices respond. The data model consists of four types of registers:
- Coils (read/write, single bit) -- typically used for digital outputs
- Discrete Inputs (read-only, single bit) -- typically digital inputs
- Holding Registers (read/write, 16-bit) -- the most commonly used, for analog values
- Input Registers (read-only, 16-bit) -- analog input values
Commands are equally straightforward. Function code 0x01 reads coils, 0x03 reads holding registers, 0x06 writes a single register, 0x10 writes multiple registers. There are a handful of others, but these cover most use cases.
Two variants exist in widespread use:
- Modbus RTU -- serial communication (RS-232 or RS-485), binary encoding
- Modbus TCP -- runs over TCP/IP on port 502, adds a simple header but is otherwise identical
Why It Is a Security Nightmare
Modbus has no authentication. None. Zero. A device on the network that can reach port 502 can read every register and write to every writable register on every Modbus device. There is no username, no password, no certificate, no token, no challenge-response -- nothing.
There is no encryption. All data is transmitted in cleartext, including the commands being sent to controllers. Anyone with access to the network traffic can see exactly what values are being read and written.
There is no integrity checking beyond a basic CRC for transmission errors. There is no way for a receiving device to verify that a command was sent by an authorised source.
To use an analogy: if your front door had the security model of Modbus, it would not merely be unlocked -- it would not have a lock, or a handle, or a door. It would be a doorframe with a sign saying "Please enter, take whatever you like, and rearrange the furniture on your way out."
Attack Vectors
The simplicity of Modbus makes attacks almost trivially easy for anyone on the network:
Reconnaissance: An attacker can scan for devices on port 502 and read all registers to map out the entire process. Every sensor value, every setpoint, every output state -- all available without credentials.
Process manipulation: Writing new values to holding registers can change setpoints, open or close valves, start or stop motors. The PLC will execute whatever values it receives because it has no way to distinguish a legitimate command from a malicious one.
Replay attacks: Captured Modbus traffic can be replayed to reproduce previous commands. Since there are no sequence numbers, timestamps, or session tokens, the target device will happily execute replayed commands.
Man-in-the-middle: An attacker can intercept and modify Modbus traffic in transit, changing register values while they are being transmitted between the master and slave.
Several tools exist for Modbus interaction: mbtget, pymodbus, and modules in Metasploit can all craft and send Modbus commands. The barrier to entry for attacking Modbus is astonishingly low.
DNP3: Slightly Better, Still Not Great
What It Is
Distributed Network Protocol 3 (DNP3) was developed in the 1990s for the electric utility industry. It is primarily used in SCADA systems for communication between control centres and field equipment (RTUs, substations, water treatment plants).
DNP3 is significantly more capable than Modbus. It supports:
- Unsolicited responses (devices can report events without being polled)
- Time-stamped data (critical for event sequencing in power systems)
- Multiple data types (binary inputs/outputs, analog inputs/outputs, counters)
- Data quality flags (indicating whether a value is valid, out of range, etc.)
- File transfer capabilities
- Event buffering (devices can store events and transmit them when connectivity is restored)
DNP3 typically runs on TCP port 20000, though it can also operate over serial links.
Security Considerations
The original DNP3 specification (IEEE 1815) included no security features. However, unlike Modbus, DNP3 has been updated with a Secure Authentication mechanism (SA, defined in IEEE 1815-2012). This adds challenge-response authentication using HMAC to verify that commands are from authorised sources.
The catch? Secure Authentication is optional, requires configuration on both ends, and many deployed DNP3 devices either do not support it or have it disabled. Upgrading thousands of deployed RTUs and substations to support SA is a multi-year, multi-million-pound project that many utilities are still working through.
Without SA enabled, DNP3 shares many of the same vulnerabilities as Modbus: no authentication, no encryption, susceptible to replay and man-in-the-middle attacks. With SA enabled, it is meaningfully more secure, but the transition is far from complete across the industry.
Protocol-Specific Attacks
DNP3's richer feature set also provides richer attack opportunities:
Cold restart command: DNP3 includes a function code (0x0D) that commands a device to perform a cold restart -- essentially rebooting the controller. Sending this to multiple field devices simultaneously can disrupt an entire SCADA system.
Configuration manipulation: DNP3 supports reading and writing device configurations. An attacker can modify polling rates, alarm thresholds, and event reporting parameters to blind operators to actual conditions.
Time synchronisation attacks: Since DNP3 supports time synchronisation from the master, an attacker can send false time sync messages, causing event timestamps to be incorrect -- undermining forensic investigation and event correlation.
OPC UA: The Modern Attempt
What It Is
OPC Unified Architecture (OPC UA) is the heir apparent to the older OPC Classic (OLE for Process Control, which was built on Microsoft's COM/DCOM -- a sentence that should make security professionals flinch). OPC UA was designed from the ground up as a platform-independent, service-oriented architecture for industrial data exchange.
OPC UA runs on TCP port 4840 by default and provides:
- A rich information model with support for complex data structures
- Platform independence (unlike OPC Classic's Windows-only DCOM dependency)
- Built-in security including authentication, encryption, and signing
- Discovery services for finding available servers on a network
- Historical data access
- Publish-subscribe capabilities
Security Features (Actually Present This Time)
OPC UA is the rare ICS protocol that was designed with security in mind. It supports:
- X.509 certificate-based authentication between clients and servers
- Transport-layer encryption using TLS
- Message signing for integrity verification
- User authentication via username/password, certificates, or tokens
- Granular access control (read, write, browse permissions per node)
This sounds excellent on paper. In practice, OPC UA's security is only as good as its configuration. Deployments with self-signed certificates, weak cipher suites, or the security mode set to "None" (which is an option, because of course it is) are common. Research has also identified vulnerabilities in specific OPC UA implementations, including buffer overflows and denial-of-service conditions.
The lesson, as always: a protocol with good security features that are poorly configured is only marginally better than a protocol with no security features at all.
BACnet: When Buildings Attack
What It Is
Building Automation and Control Networks (BACnet) is the standard protocol for building management systems -- HVAC, lighting, access control, fire detection, and lift management. It is standardised as ISO 16484-5 and ASHRAE 135.
BACnet operates over several network types (Ethernet, IP, MSTP) and typically uses UDP port 47808. It uses a client-server model with a rich object-oriented data model: everything in a BACnet system is an object (analog inputs, binary outputs, schedules, calendars, trend logs).
Security Status: Concerning
BACnet was designed for building automation, an environment that was traditionally considered low-risk from a cybersecurity perspective. After all, the worst an attacker could do with a building management system is adjust the thermostat, right?
Not quite. BACnet systems routinely control:
- HVAC in data centres (disable cooling, watch the servers cook)
- Access control systems (unlock doors remotely)
- Fire suppression systems (disable fire detection, trigger suppression in occupied areas)
- Lifts and escalators (disrupt vertical transport in a high-rise)
Original BACnet had no authentication or encryption. BACnet/SC (Secure Connect), ratified as an addendum in 2019, adds TLS-based security with certificate authentication. Adoption is underway but far from universal, and legacy BACnet/IP devices remain widespread.
EtherNet/IP and CIP: Industrial Ethernet
What It Is
EtherNet/IP (where "IP" stands for "Industrial Protocol," not "Internet Protocol" -- because naming conventions in ICS are designed to cause maximum confusion) is an application-layer protocol for industrial automation that runs over standard Ethernet and TCP/IP infrastructure. It uses the Common Industrial Protocol (CIP) as its application layer.
EtherNet/IP uses TCP port 44818 for explicit messaging (configuration, diagnostics) and UDP port 2222 for implicit messaging (real-time I/O data). It is widely used in manufacturing, particularly in North American facilities.
Security Considerations
EtherNet/IP with CIP shares the common ICS security deficiency: no built-in authentication or encryption in its base specification. CIP Security, an extension released by ODVA, adds TLS/DTLS-based security with certificate authentication, but it is an optional addition to the base protocol.
Because EtherNet/IP runs over standard Ethernet, it is susceptible to all the standard network attacks (ARP spoofing, MAC flooding, VLAN hopping) in addition to protocol-specific attacks against the CIP application layer.
The Air Gap Myth
A recurring theme in ICS security discussions is the "air gap" -- the idea that OT networks are physically isolated from IT networks and the internet. This was once largely true, and it is the fundamental reason these protocols were designed without security features.
The air gap is now largely mythical. Several forces have eroded it:
Business requirements: Management wants production data in real-time dashboards, predictive maintenance analytics, and integration with ERP systems. All of this requires data to flow from OT to IT networks.
Remote access: Vendors need remote access for support and maintenance. Operators want to check system status from home. COVID-19 accelerated the deployment of remote access solutions in OT environments, often without adequate security controls.
Convergence of protocols: The shift from proprietary serial networks to Ethernet-based protocols (EtherNet/IP, Modbus TCP, OPC UA) means that OT devices now share the same network infrastructure as IT systems.
Supply chain integration: Modern manufacturing relies on data exchange between suppliers, manufacturers, and customers, all of which creates pathways between networks.
Even where a genuine air gap exists, Stuxnet demonstrated that it can be crossed via removable media, compromised vendor laptops, or supply chain attacks.
Shodan and Censys: Finding ICS on the Internet
If the air gap is a myth, just how many ICS devices are exposed to the internet? Shodan and Censys provide the uncomfortable answer.
What They Are
Shodan is a search engine for internet-connected devices. Unlike Google, which crawls web content, Shodan scans IP addresses, identifies services, and catalogues the results. It can identify ICS devices by their protocol banners, response patterns, and service ports.
Censys performs similar internet-wide scanning with a focus on protocol analysis and certificate cataloguing.
What They Find
A Shodan search for Modbus (port 502) consistently returns thousands of results worldwide. Searches for BACnet (port 47808), DNP3 (port 20000), EtherNet/IP (port 44818), and other ICS protocols return similarly concerning numbers.
These are not honeypots or research systems (though some are). Many are genuine industrial control systems -- PLCs, RTUs, building management systems, and SCADA servers -- directly accessible from the internet with no authentication required.
Common findings include:
- HMIs with default credentials (or no credentials at all) accessible via HTTP
- Modbus devices responding to read requests from any source
- BACnet devices disclosing their full object list and current values
- OPC servers with the security mode set to "None"
Several ICS-focused Shodan dorks are well-documented:
port:502-- Modbus devicesport:47808-- BACnet devicesport:20000-- DNP3 devicesport:44818-- EtherNet/IP devices"Schneider Electric"-- devices identifying as Schneider Electric products"Siemens"-- Siemens S7 controllers and other products
The existence of these search engines is not the problem. They merely reveal what is already there. The problem is that these devices are exposed in the first place.
Securing ICS Protocols: What Can Be Done
Given the limitations of legacy protocols, securing ICS environments requires a defence-in-depth approach that does not rely on protocol-level security:
Network Segmentation
Proper segmentation following the Purdue Model (or a similar framework) is the single most important control. ICS protocols should never traverse the IT/OT boundary without passing through firewalls with protocol-aware inspection capabilities. ICS-specific firewalls from vendors such as Claroty, Nozomi Networks, and Dragos can inspect Modbus, DNP3, and other protocols at the application layer.
Network Monitoring
If you cannot add security to the protocol, you can monitor the traffic for anomalies. ICS network monitoring tools can establish baselines of normal communication patterns and alert on deviations: unexpected source addresses, unusual function codes, register writes outside normal ranges, or communication at unusual times.
Protocol-Specific Mitigations
- Modbus: Restrict access to port 502 via firewall rules. Use a Modbus-aware firewall to filter by function code (allow reads, block writes from unauthorised sources). Consider a protocol gateway that adds authentication.
- DNP3: Enable Secure Authentication where supported. Restrict access to authorised master stations.
- OPC UA: Configure security mode to "SignAndEncrypt." Use strong certificates. Disable anonymous access.
- BACnet: Migrate to BACnet/SC where possible. Segment BACnet traffic into dedicated VLANs.
Encryption Overlays
Where protocol-level encryption is not available, network-level encryption (IPsec tunnels, VPN connections) can protect traffic in transit. This adds complexity and potential latency, which must be carefully evaluated against process requirements.
Conclusion: Trust, but Verify (or Better Yet, Just Verify)
ICS protocols were designed in an era when "network security" meant locking the server room door and "remote access" meant driving to the site. They were built for reliability and efficiency in physically isolated environments, and they excel at those tasks. They were not built for a world where any network might be reachable from the internet and where sophisticated threat actors specifically target industrial systems.
The challenge is not that these protocols exist -- they are deeply embedded in critical infrastructure and cannot be replaced overnight. The challenge is securing environments that depend on fundamentally insecure protocols, and doing so without disrupting the processes they control.
The answer is not to panic, but to layer defences: segment networks, monitor traffic, restrict access, upgrade where possible, and maintain the awareness that the protocol carrying your SCADA commands offers roughly the same security as a postcard.
At least postcards are not usually responsible for keeping the lights on.
Tech Corsair -- navigating the digital seas so you don't have to.
