Industrial Firewalls: Configuration and Deep Packet Inspection for OT Protocols

01Key takeaways

1. 01

   An industrial firewall combines normal packet filtering with deep packet inspection of OT protocols, so policy can reach the function-code and register level, not just the port.

2. 02

   Place firewalls at the boundaries that matter in the Purdue model: between IT and OT, around the DMZ, and between cells or zones that should not share a flat network.

3. 03

   Write rules deny-by-default and per conduit. Allow only the specific source, destination, protocol and operation each process actually needs.

4. 04

   Deep packet inspection lets you separate read-only monitoring from write or configuration commands in Modbus, DNP3 and EtherNet/IP, which is often the single highest-value OT control.

5. 05

   A firewall is a policy device on a path that remains technically bidirectional. For boundaries that only need to publish data outward, pair it with one-way transfer so the return path is removed, not just filtered.

02What an industrial firewall actually is

An industrial firewall is a firewall designed for operational technology networks. Like any firewall it enforces policy on traffic crossing a boundary. What sets it apart is protocol awareness: it can parse industrial protocols and apply rules to the contents of those protocols, not only to the IP addresses and ports that carry them.

Most OT protocols were designed for trusted, isolated networks. They typically lack authentication, encryption and integrity checks. Modbus, DNP3 and EtherNet/IP all assume the device on the other end is friendly. An industrial firewall compensates for that assumption by inspecting each message and deciding whether it is allowed, rather than trusting that anything speaking the protocol belongs there.

Short version: an IT firewall asks is this traffic allowed on this port? An industrial firewall can also ask is this specific command allowed against this specific device?

03Why OT needs more than a port-based rule

In OT, the consequence of a bad packet is not a leaked record. It can be a tripped breaker, an overfilled tank or a stopped line. The attack techniques catalogued in MITRE ATT&CK for ICS, such as unauthorized command messages, modifying control logic and spoofing reporting messages, frequently ride inside otherwise valid protocol traffic.

A port-based rule cannot tell the difference between a SCADA server polling a register and an attacker writing a new setpoint. Both are Modbus on port 502. Deep packet inspection can tell them apart because it reads the function code and the target address. This is why NIST SP 800-82 and the ISA/IEC 62443 series both push past simple perimeter filtering toward protocol-aware, zone-based enforcement.

• Most OT protocols carry no authentication, so any reachable host can issue commands.
• Read and write operations share the same port, so port rules cannot separate monitoring from control.
• A single unauthorized write can change a physical process, not just data.
• Legacy controllers crash on malformed or unexpected traffic, so input validation at the firewall protects fragile devices.
• Flat OT networks let one compromised host reach every controller, which deep inspection and segmentation can contain.

04Where the firewall sits: the Purdue model and zones

The classic reference architecture for placement is the Purdue model, refined by the zone-and-conduit thinking in ISA/IEC 62443. The firewall belongs wherever traffic crosses between areas of different trust. The most important boundary is between the enterprise (Levels 4 and 5) and the OT environment (Levels 0 to 3), usually mediated by an industrial DMZ.

A well-built OT DMZ uses a pair of firewalls, or a single firewall with separate interfaces, so that no flow passes directly from enterprise to control network. Servers in the DMZ, such as a historian replica or a patch source, terminate connections from each side. Inside the OT network, additional firewalls separate cells, lines or process areas into zones so a problem in one area cannot spread laterally to the rest.

Zone

A grouping of assets that share the same security requirements and trust level, such as a single production cell or the safety system.

Conduit

A controlled communication path between zones. Every conduit gets an explicit, documented set of allowed flows and nothing else.

Industrial DMZ

A buffer zone between enterprise and OT where shared services live, so neither side connects directly to the other.

05Start deny-by-default and build the allowlist

The foundation of any defensible OT firewall is a deny-by-default posture. The last rule denies everything; every flow you intend to permit is added explicitly above it. This is the opposite of an IT edge firewall that allows broad outbound access, and it is achievable in OT because the traffic patterns are stable and well known.

Building the allowlist starts with knowing what normal looks like. Capture traffic at each boundary, identify every legitimate flow by source, destination, protocol and direction, and write one narrow rule per flow. A historian needs to poll PLCs; an HMI needs to talk to its controllers; an engineering workstation needs occasional access during maintenance windows. Each of these becomes a specific rule rather than a permissive subnet-to-subnet allow.

• Default-deny on every interface, with logging on the deny rule to surface unexpected traffic.
• One rule per flow, scoped to specific source and destination hosts, not whole subnets where avoidable.
• Lock each rule to the exact protocol and port the application uses, and to a single direction.
• Time-box maintenance and vendor flows so they are not left permanently open.
• Document the business justification for every allow rule and review them on a schedule to fight rule creep.

06How deep packet inspection of OT protocols works

Deep packet inspection in an industrial firewall means the device parses the application layer of an OT protocol and applies policy to its fields. Instead of treating a Modbus message as opaque bytes on port 502, the firewall decodes the unit ID, the function code and the data addresses, then checks them against rules.

Two enforcement modes are common. The first is an allowlist of operations: permit only the function codes a given conversation legitimately uses. The second is sanity and range checking: validate that values, lengths and addresses fall within expected bounds, which also protects fragile devices from malformed packets that would otherwise crash them. Many industrial firewalls can learn a baseline of observed traffic and then alarm or block on anything outside it.

The highest-value DPI rule in most plants is simple: on conduits that exist for monitoring, permit read function codes and deny every write or configuration command. Reporting flows almost never need to write.

07Function-code and register filtering by protocol

The same principle applies across the major OT protocols, with protocol-specific detail. The goal is always to allow the minimum set of operations a conversation needs and to deny the rest, especially anything that changes state or configuration.

Modbus/TCP

Filter by function code and register range. Permit reads such as Read Holding Registers (code 3) and Read Input Registers (code 4) on a monitoring path; deny writes such as Write Single Register (6) and Write Multiple Registers (16), forced coils (5), and diagnostics that can reset or restart a device.

DNP3

Filter by function code and object. A monitoring conduit may allow Read (function 1) and confirm functions while denying Write (2), Direct Operate and Select-Before-Operate control sequences, and management functions such as Cold Restart that affect outstation availability.

EtherNet/IP and CIP

Inspect the CIP service and object. Permit implicit I/O and explicit reads needed by HMIs and historians; deny CIP services that write configuration, start or stop the controller, or change the program, and restrict access to sensitive object classes.

OPC UA

Where modern gateways speak OPC UA, restrict to the specific endpoints and services in use, require its built-in security where available, and avoid exposing discovery and management services across zones.

Map these rules to documented engineering intent. A register that drives a physical output should never be writable from a reporting zone, and the firewall is where that intent becomes enforceable policy rather than a hope.

08Mapping the configuration to standards

A firewall configuration is easier to defend in an audit when it traces back to recognised guidance. The zone-and-conduit model, deny-by-default rules and protocol-aware enforcement described here align directly with the major OT security frameworks.

NIST SP 800-82 Rev. 3

Recommends network segmentation, boundary protection between IT and OT, an OT DMZ and restriction of traffic to only what is required for operations.

ISA/IEC 62443

Defines the zones-and-conduits model and security levels. Firewall conduit rules are a primary mechanism for enforcing the required separation between zones.

MITRE ATT&CK for ICS

Provides the adversary techniques to test rules against, such as unauthorized command message and modify controller tasking, so DPI policy can be tied to concrete threats.

CISA ICS guidance

Recommends defense-in-depth, layered boundary controls and minimizing OT exposure, reinforcing that the firewall is one layer among several.

Keep an artifact that links each conduit and rule set to the relevant clause or control. Auditors and incident responders both benefit when the rationale for a rule is written down rather than living only in an engineer's memory.

09Common configuration pitfalls

Most industrial firewall failures are not exotic. They come from operational shortcuts that quietly erode the policy over time. Knowing the common ones makes them easier to avoid and easier to find during review.

• Any-any rules left in place to get the line running and never tightened afterward.
• Permitting a whole protocol on its port without DPI, so writes and reads are treated identically.
• Temporary vendor or maintenance rules that become permanent because nobody owns their removal.
• An exposed or shared firewall management interface that becomes the easiest way into the OT network.
• No logging on deny rules, so unexpected and malicious traffic is invisible until something breaks.
• Inspection too aggressive for fragile legacy devices, where the firewall must be tuned and tested against real equipment before enforcement is enabled.

Test rule changes in a maintenance window or on a representative bench first. An overly strict DPI rule can drop traffic a controller depends on, and in OT a dropped packet can mean a stopped process.

10Where one-way transfer fits alongside the firewall

An industrial firewall is a strong policy control, but it is still a control on a path that remains technically capable of carrying traffic in both directions. Rules can drift, management interfaces can be attacked, and an emergency exception can quietly reopen a route. For the highest-consequence boundaries, the most robust design removes the return path rather than filtering it.

This is where one-way transfer complements the firewall instead of competing with it. Many OT-to-IT flows, such as historian replication, log forwarding to a SOC and telemetry to enterprise reporting, only need to publish data outward. On those conduits, a data diode or unidirectional gateway enforces direction in hardware, so no inbound command path exists no matter how the policy changes. The firewall still does the heavy lifting for the boundaries that genuinely need governed two-way traffic.

A practical pattern: firewalls with DPI for conduits that need a controlled conversation, and one-way enforcement for conduits that only need to publish. Match the control to the direction the process actually requires.

11A practical deployment roadmap

Treat the firewall rollout as a project with a sequence, not a single change. The order below moves from understanding to enforcement while keeping production safe at each step.

• Inventory assets and capture baseline traffic at every boundary you intend to control.
• Define zones and conduits, then document the exact flows each conduit must carry.
• Deploy firewalls at the IT/OT boundary and DMZ first, in monitor or alert mode.
• Move to deny-by-default with explicit per-flow allow rules once the baseline is understood.
• Enable protocol DPI conduit by conduit, separating read from write, and test against real devices.
• Add one-way transfer for publication-only conduits, then review rules and logs on a recurring schedule.

The end state is a network where every crossing is intentional, every command is checked against engineering intent, and the boundaries that should never carry return traffic physically cannot. That is defense in depth: segmentation, protocol-aware filtering and one-way transfer each carrying a different part of the load.

FAQFrequently asked questions

SRCSources of record