The short answer
Deep Packet Inspection
Deep packet inspection reads the contents of a packet beyond the addresses and ports, and on an industrial firewall that means decoding Modbus, DNP3, EtherNet/IP, OPC UA, and other control protocols well enough to see what the message asks for: a read of holding registers, a write to a coil, a program download, a firmware update, a restart. Rules can then permit the SCADA to read from a controller while denying it writes, permit writes only to specific registers, permit programming functions only from the engineering workstation during a change window, drop messages that violate the protocol specification, and alert on anything unusual. It belongs at the boundary between the supervisory zone and the controllers, at the site conduit of a remote site, and in front of a controller that cannot be patched. It costs throughput, configuration effort, and vigilance, and it cannot see inside encrypted protocols or decode every vendor protocol, which is why it complements rather than replaces segmentation and controller hardening.
Key points
- Address and port rules say who may talk; deep inspection says what they may say.
- Reads allowed, writes denied or limited, programming only from one workstation in a window: the rules that matter for controllers.
- Malformed and out-of-specification messages are dropped before they reach a fragile device.
- Best placed between the SCADA and the controllers, at remote site conduits, and in front of unpatchable devices.
- It cannot see into encrypted traffic or undocumented vendor protocols; those need other controls.
- Start in monitor mode; enforce once the normal traffic is understood.
Beyond the port
A conventional rule permits the SCADA server to reach the controller on the Modbus port. Everything on that port then passes: the read the SCADA needs, the write it occasionally needs, and the write that an attacker on the SCADA server would send to change a setpoint or stop a pump. Deep packet inspection decodes the message and applies rules to its meaning. The read passes; the write passes only if it is to a register on the allowed list; a write to the controller mode or a request to restart is dropped and alarmed. The firewall has become a protocol-aware filter that enforces what the functional description says the SCADA should do, rather than what the protocol allows it to do.
What the rules look like
| Rule | Effect | Use |
|---|---|---|
| Permit read functions from the SCADA to the controller | Polling works | Every controller |
| Permit write functions from the SCADA only to listed registers or tags | Setpoints and commands work; everything else is denied | Controllers that accept commands from the SCADA |
| Deny write functions from anywhere else | No other host can command the controller | Every controller |
| Permit programming and configuration functions only from the engineering workstation, only during a scheduled window | Programming works when approved; a download at any other time or from any other host is dropped and alarmed | Every controller with an unauthenticated programming protocol |
| Deny restart, mode change, firmware, and diagnostic functions except from the engineering workstation | Denial of service functions blocked | Controllers that respond to those functions |
| Drop malformed or out-of-specification messages | Fuzzing and exploit traffic does not reach the device | In front of older controllers and instruments |
| Alert on any function not seen in the baseline | The unusual is noticed | Everywhere; in monitor mode first |
Where it belongs
- Between the supervisory zone and the control zone, where the SCADA polls the controllers: the highest-value place, because a compromised SCADA server is the most likely source of a malicious write.
- At the conduit of a remote site, in the site firewall, so that the site controller accepts only the polling functions from the plant and programming only from the jump host in a window.
- In front of a controller or a device with a known vulnerability that cannot be patched, blocking the function the exploit uses.
- In front of a safety system, permitting status reads outward and nothing inward.
- Not between every pair of devices on the control network; the throughput cost and the configuration burden would exceed the benefit.
Protocols
Industrial firewalls decode the open protocols well: Modbus TCP with its function codes and register addresses, DNP3 with its function codes and object groups, EtherNet/IP with its services and objects, OPC UA where it is unencrypted, and often the common vendor programming protocols, at least to the point of recognizing a download. What they cannot decode is traffic that is encrypted, which is increasingly the case with OPC UA and the newer vendor protocols, and vendor protocols the firewall maker has not reverse-engineered. For those the firewall falls back to addresses and ports, and the controls that carry the weight are the controller own authentication, the keyswitch, change detection, and the segmentation that limits who can reach the controller at all.
Deploying it
- 1
Monitor first
Enable inspection in a mode that logs what it sees without blocking, for weeks, across every operating condition. The log is the list of functions and registers the system actually uses.
- 2
Write the rules from the log and the functional description
The reads, the writes to listed registers, the programming path, and the denials, per controller.
- 3
Enforce in stages
One controller or one site at a time, watching the SCADA communication status and the alarm list for anything the rules broke.
- 4
Alert on the rest
Anything denied is logged and alarmed; a denial that recurs is either an attack or a rule that is wrong, and both need a person.
- 5
Maintain
A new tag that the SCADA writes is a rule change under change management; the rules are baselined and reviewed with the firewall rules.
Frequently asked questions
- Does inspection slow the polling?
- It adds latency of a fraction of a millisecond to a few milliseconds per message on an industrial firewall sized for the traffic, which is invisible to a SCADA polling at seconds. An undersized firewall inspecting a busy network drops packets, which shows as bad quality; size it for the message rate, not the bandwidth.
- Can it stop a compromised engineering workstation?
- It limits what that workstation can do to the window and the functions the rules permit, and it alerts on anything else, which is more than a port rule can do. It cannot tell a legitimate download from a malicious one made by the same workstation in the same window; change management, session logging, and program change detection cover that.
- Is deep inspection the same as an intrusion detection system?
- They overlap. An intrusion detection sensor watches a copy of the traffic and alerts; a firewall with deep inspection sits inline and blocks. Many utilities run both: the sensor for visibility across the whole network, the firewall for enforcement at the boundaries that matter.
- Our controllers use a vendor protocol the firewall does not understand. What then?
- Address and port rules still restrict who can reach the controller, and programming is restricted to the engineering workstation by those rules. The controller own authentication and keyswitch, change detection, and monitoring carry the rest. Ask the firewall vendor whether the protocol is on their roadmap, and the controller vendor whether the protocol can be secured.
Related topics
- Industrial FirewallsFirewalls built for control networks: how they differ from office firewalls, where they belong in a utility network, transparent versus routed modes, Modbus and DNP3 awareness, logging, and the ruggedized units that protect one controller or a remote site.
- Firewall Rule DesignWriting the rule set for a control network boundary: default deny, one rule per conduit with its reason, hosts not subnets, protocol and port and function, direction and initiator, logging on every rule, and the review that removes forgotten rules.
- Compensating ControlsWhat to do about a vulnerability that cannot be patched now or ever: restricting who can reach it, disabling the service, blocking dangerous protocol functions, allowlisting, monitoring, physical and procedural controls, matched to the attack path.
- Controller HardeningWhat can be locked down on a PLC or RTU: keyswitch and mode, credentials, unused services, access lists, firmware, and the engineering workstation that is the real target.
- Modbus TCPModbus over Ethernet: what the MBAP header changes, why the CRC disappears, how the unit identifier works, and what does not get easier just because it is on Ethernet.
- Firewall Logging and ReviewMaking the firewall log useful: logging on every rule including sensitive permits, sending logs to a collector off the firewall, what denials and unexpected permits mean, a weekly review a small utility can sustain, and the alerts worth waking someone for.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.