ICS and SCADA Protocols: Why Industrial Networks Need Hard Boundaries

Protocols built for a world that no longer exists

Modbus was published in 1979. S7comm dates to the 1990s. EtherNet/IP and BACnet emerged in the late 1990s and early 2000s. Every one of these protocols was designed for a specific environment: serial communication links in physically isolated facilities, where the only people who could send a command were the ones standing next to the equipment.

That world is gone. These protocols now run over TCP/IP on networks that are, in many organisations, reachable from the corporate LAN or even from the internet. The protocols themselves have not changed. They still carry zero authentication, zero encryption, and zero integrity checking. A single well-formed packet can open a valve, change a temperature setpoint, stop a turbine, or disable a safety system. The protocol will not ask who sent it or whether they were authorised to do so.

This is not a vulnerability in the traditional sense. There is no CVE to patch, no firmware update to apply, no configuration knob to turn. The protocols work exactly as designed. The problem is that the environment they were designed for no longer exists, and the network boundaries that were supposed to replace physical isolation are often weak, misconfigured, or entirely absent.

What these protocols actually do

Understanding why network isolation matters requires understanding what these protocols allow anyone on the network to do.

Modbus (TCP port 502). Modbus is the lingua franca of industrial automation. It is simple by design: a client sends a function code and a register address, and the server responds. Function code 3 reads holding registers. Function code 6 writes a single register. Function code 16 writes multiple registers. There is no authentication header, no session token, no access control list. If you can reach a Modbus device on port 502, you can read and write any register on that device. A register might control the speed of a motor, the position of a valve, the setpoint of a temperature controller, or the state of a safety interlock.

S7comm (TCP port 102). Siemens S7 PLCs use S7comm for programming, diagnostics, and data exchange. The protocol provides full read and write access to PLC memory, including program blocks, data blocks, and system state. An attacker with network access to a Siemens PLC can download running programs, upload modified programs, start and stop the PLC, and read or write process data. Older versions of S7comm (used by S7-300 and S7-400 series) have no authentication whatsoever. Newer versions (S7-1200 and S7-1500) support optional password protection, but it is frequently left disabled and the passwords, when set, are transmitted in a format that is trivially reversible.

EtherNet/IP (TCP port 44818). EtherNet/IP carries the Common Industrial Protocol (CIP) over standard TCP/IP. CIP is used by Allen-Bradley/Rockwell PLCs and many other industrial devices. Through CIP, any host on the network can read and write tags (variables) on a PLC, change configuration parameters, upload and download programs, and reset devices. The protocol supports "unconnected messages" that require no prior session establishment, meaning a single packet from any source can issue commands to any device.

BACnet (UDP port 47808). BACnet is the standard protocol for building automation: HVAC systems, fire suppression, lighting, physical access control, elevator management. A BACnet client can read and write any "property" on any "object" across the building automation network. That means changing HVAC setpoints, disabling fire alarms, unlocking doors, and modifying elevator schedules. The protocol has no built-in authentication. BACnet/SC (Secure Connect), published in 2019, adds TLS-based security, but adoption remains minimal. The overwhelming majority of deployed BACnet systems use the original unauthenticated protocol.

Why "it's on a separate network" is not enough

Many organisations believe their OT networks are isolated because they are on a different VLAN, a different IP range, or behind a firewall. But isolation is not a binary state. It is a spectrum, and the distance between "separate VLAN" and "actually isolated" is enormous.

The most common failures look like this. A firewall exists between the corporate network and the OT network, but it permits broad access for "monitoring" or "historian" traffic. An engineer's laptop dual-homes between corporate Wi-Fi and the OT network. A vendor VPN terminates directly into the OT segment for remote support. A shared file server or print server bridges the two networks. An Active Directory trust relationship extends from IT into OT. A jump host provides RDP access from the corporate network into the control system network without protocol-level restrictions on what happens after the RDP session is established.

Each of these is a path. And because ICS protocols have no authentication, a path is all an attacker needs. Once any device on the corporate network can route a packet to TCP port 502, 102, 44818, or UDP port 47808 on the OT network, every industrial device on that network is fully accessible.

The Purdue Model and where firewalls belong

The Purdue Enterprise Reference Architecture, developed in the 1990s, defines a hierarchical model for industrial networks that remains the foundation of OT security architecture today. It divides the network into levels based on function.

The critical boundary is between Level 3 (site operations) and Level 4 (business planning/enterprise). This is where the IT/OT divide should live, and it is where a firewall or DMZ must enforce strict protocol-level controls. In practice, many organisations either place no firewall here, place a firewall but configure it too permissively, or allow exceptions that effectively negate the boundary.

The Purdue Model also calls for a Level 3.5 DMZ: a buffer zone between IT and OT where shared services like historians, patch servers, and remote access gateways live. Traffic from the enterprise network reaches the DMZ. Traffic from the OT network reaches the DMZ. But no traffic flows directly from enterprise to OT. The DMZ breaks the direct path. Implementing this correctly means that even if an attacker fully compromises the corporate network, they cannot send a Modbus write command to a PLC, because there is no routable path from Level 4/5 to Level 2.

What happens when the boundaries fail

The consequences of IT traffic reaching OT networks are not theoretical. They are historical.

Stuxnet, discovered in 2010, crossed from IT networks into Iranian uranium enrichment facilities and manipulated Siemens S7-300 PLCs controlling centrifuge speeds. The attack modified PLC code to spin centrifuges at destructive speeds while reporting normal operation to the operators. The malware spread through the IT/OT boundary via infected USB drives and network shares, exploiting exactly the kind of weak isolation described above.

TRITON (also called TRISIS), discovered in 2017, targeted Schneider Electric Triconex safety instrumented systems (SIS) at a petrochemical facility in the Middle East. The attacker traversed from the IT network through the OT network to reach the SIS controllers, the last line of defence against catastrophic process failures. The malware attempted to disable safety systems that prevent explosions, toxic releases, and equipment destruction. The only reason it failed was a bug in the malware itself.

The Colonial Pipeline incident in 2021 demonstrated a different failure mode. Ransomware compromised IT systems, and the company shut down OT operations not because the OT network was directly affected, but because the loss of IT systems meant they could not monitor and bill for pipeline operations. The business dependency between IT and OT systems created an indirect path to operational shutdown even without direct OT compromise.

These are not edge cases. They are the predictable result of industrial protocols with zero authentication operating on networks with insufficient boundaries.

Building the boundaries that actually work

Securing ICS and SCADA environments is fundamentally different from securing IT networks. You cannot deploy endpoint agents on PLCs. You cannot patch a Modbus implementation that is burned into firmware from 2005. You cannot require multi-factor authentication on a protocol that has no authentication field. The control must come from the network.

Unidirectional gateways (data diodes). For the highest-security boundary, hardware-enforced unidirectional gateways allow data to flow from OT to IT (for monitoring and historians) but physically prevent any traffic from flowing from IT to OT. These are not software firewalls that could be misconfigured or bypassed. They are hardware devices with a transmit-only optical interface on one side and a receive-only interface on the other. No packet can travel in the reverse direction, because there is no physical medium to carry it. Data diodes are standard practice in nuclear facilities, military installations, and critical infrastructure that cannot tolerate any risk of inbound traffic.

IT/OT DMZ at Purdue Level 3.5. For environments where bidirectional communication is required (remote access, patch management, bidirectional historian queries), the DMZ model provides the next best option. Place shared services in a DMZ segment. Allow IT-to-DMZ traffic and OT-to-DMZ traffic, but never IT-to-OT traffic directly. The DMZ acts as a protocol break: the historian in the DMZ collects data from OT devices and presents it to IT systems through a completely different interface. No ICS protocol ever crosses the DMZ boundary.

Protocol-aware firewalls. Standard firewalls that filter on IP, port, and protocol are necessary but not sufficient. A rule that allows TCP port 502 tells you nothing about what Modbus function code is being used. A protocol-aware firewall (sometimes called a deep packet inspection firewall for OT or an industrial protocol firewall) can parse Modbus, S7comm, EtherNet/IP, and BACnet at the application layer. It can allow Modbus function code 3 (read) while blocking function code 6 (write). It can permit S7comm diagnostic reads while blocking program uploads. This level of granularity is essential because the threat model is not "block all ICS traffic" but "block ICS traffic that could modify the process while allowing monitoring."

No direct path from corporate to process control. This is the simplest rule and the most frequently violated. No host on the corporate network should be able to reach a PLC, RTU, DCS controller, or safety system directly. Not through a firewall rule, not through a VPN, not through a jump host that tunnels traffic. The path should not exist. If an engineer needs to program a PLC remotely, they connect to a hardened engineering workstation in the DMZ or Level 3 segment through a monitored, authenticated, recorded remote access solution. They do not get a direct TCP session to the PLC.

Strict vendor remote access controls. Vendor VPNs are a persistent source of boundary violations. Vendors need remote access to support equipment. That access should terminate in the DMZ, not in the OT network. It should require multi-factor authentication, session recording, and time-limited access windows. The vendor should access a jump host, not the PLC directly. And the VPN should be disabled when not actively in use, not left running because it is inconvenient to set up each time.

Finding ICS protocol leaks in your firewall policy

The challenge with ICS/SCADA security is that the firewall rules allowing these protocols to cross boundaries are often not obvious. They may be hidden inside broad "allow" rules that were created years ago for a different purpose. A rule that permits "any TCP traffic from the engineering VLAN to the plant VLAN" includes Modbus, S7comm, and EtherNet/IP even if nobody thought about those protocols when the rule was written.

When you analyse your firewall ruleset with netbobr, rules like PCI-NET-056, CIS-NET-036, and NIST-NET-046 specifically look for ICS and SCADA protocols crossing zone boundaries. PCI-NET-056 flags any rule that permits ICS protocol traffic (Modbus, S7comm, EtherNet/IP, BACnet, DNP3, and others) where it has been detected in your rule set. CIS-NET-036 and NIST-NET-046 identify rules that allow these protocols to cross from one network zone to another, which is the precise condition the Purdue Model is designed to prevent.

These checks matter because the protocol exposure is often unintentional. The firewall administrator who wrote a broad allow rule for "server-to-server communication" between two zones did not intend to allow Modbus writes to PLCs. But the rule permits it, and the PLC will accept the command without question.

The cost of getting this wrong

In IT security, a compromised server means data loss, downtime, and financial impact. In OT security, a compromised controller means physical consequences. Pumps run dry. Pressure vessels exceed safe limits. Chemical mixtures go wrong. Safety interlocks are disabled. Buildings lose climate control, fire suppression, or physical access management.

The protocols that control these systems were designed to be fast, simple, and reliable on isolated serial networks. They achieve that by stripping away everything that modern network security depends on: authentication, encryption, integrity verification, access control, and session management. What remains is a protocol that does exactly what anyone tells it to do, from any source, without question.

The network boundary is the only control that matters. If your firewall policy allows ICS protocols to cross from IT to OT, or from untrusted to trusted segments, then you are relying on the absence of attackers rather than the presence of controls. That is not a security posture. That is an assumption.

Start by mapping every firewall rule that touches ports 502, 102, 44818, and 47808. Identify which of those rules allow traffic to cross from enterprise segments into operational technology segments. Then close those paths. Use a DMZ. Deploy data diodes where the risk warrants it. Run protocol-aware inspection on the boundaries you cannot eliminate entirely. And verify the result with tools like netbobr that can systematically identify ICS protocol exposure across your entire ruleset, because manual review of hundreds or thousands of rules will miss things.

Industrial protocols deserve industrial-grade boundaries

The gap between how these protocols were designed and how they are deployed today is the core problem. Modbus was never meant to be routable. S7comm was never meant to be reachable from a corporate laptop. BACnet was never meant to traverse the internet. But the convenience of IP networking, the pressure to connect OT to IT for monitoring and analytics, and the difficulty of maintaining true air gaps in modern facilities have pushed these protocols onto networks they were never designed to survive on.

The answer is not to redesign the protocols. Backward compatibility requirements and the 20-to-30-year lifespan of industrial equipment make that impractical for most deployed systems. The answer is to build the boundaries that the protocols themselves cannot enforce. Hard boundaries, enforced at the network layer, verified regularly, and treated with the same severity as the physical safety systems that depend on them. Because in OT environments, the firewall is not just protecting data. It is protecting the physical process, the equipment, and the people who work alongside it.