OT Firewall Design and Rule Management for Industrial Networks

Introduction

Industrial firewalls are the enforcement mechanism that makes OT network segmentation real. A zone-and-conduit architecture exists on paper; firewalls make it exist on the network. Without properly designed and maintained firewall rules, the architectural boundaries defined in security documents are theoretical rather than operational.

Designing OT firewalls correctly is fundamentally different from designing enterprise firewalls. The traffic patterns are different: industrial protocols rather than HTTP, periodic polling rather than user-initiated requests, millisecond timing requirements rather than interactive latency tolerance. The change management constraints are different: a rule change that breaks a critical communication may not be noticed until a process upset occurs, potentially hours or days later. And the risk model is different: a misconfigured firewall rule that blocks a safety-critical communication may be more dangerous than no firewall at all.

This guide covers OT firewall architecture selection, rule design principles for industrial protocols, implementation methodology, change management processes, and ongoing rule lifecycle management. It is intended for OT security engineers, network architects, and IT/OT convergence teams responsible for implementing and maintaining segmentation controls in industrial environments.

Firewall Architecture Selection

Deployment Mode: Transparent vs. Routed

The first architectural decision for an OT firewall is its IP model: will the firewall operate in transparent mode (Layer 2 bridge) or routed mode (Layer 3 routing)?

Transparent mode (bridged) places the firewall in-line on an existing network segment without changing the IP addressing or routing of the protected devices. The firewall filters traffic at Layer 2 without acting as a router. This approach:

• Minimizes disruption to existing OT devices: no IP addresses change, no routing reconfiguration
• Does not require OT devices to have different default gateways
• Is suitable for retrofitting segmentation into existing environments with minimal operational impact
• Provides lower visibility into Layer 3 behavior and does not support stateful NAT

Routed mode makes the firewall a Layer 3 routing boundary, with separate IP subnets on each interface. This approach:

• Provides clearer network segmentation with distinct IP address spaces per zone
• Enables stateful connection tracking across subnets
• Supports NAT if required for IP address translation
• Requires IP addressing changes to OT devices when retrofitting, which may not be acceptable in running environments

For greenfield deployments or major network redesigns, routed mode is generally preferred for its cleaner segmentation model. For retrofitting into existing environments where changing device IP addresses is operationally impractical, transparent mode provides a viable path to enforcement without disruption.

Industrial-Grade vs. Enterprise Firewall Selection

Not every enterprise-grade firewall is appropriate for OT deployments. Selection criteria for OT-specific firewalls include:

Industrial protocol deep packet inspection (DPI). The firewall must understand OT protocols at an application level, not just TCP/IP. Look for native support for:

• Modbus TCP: ability to filter by function code, register range, and unit identifier
• DNP3: filtering by function codes, data object groups, and station addresses
• EtherNet/IP (CIP): filtering by CIP service code, class, instance, and attribute
• OPC DA/UA: session-level inspection and service filtering
• PROFINET, IEC 104, IEC 61850, BACnet/IP: protocol-specific filtering for relevant industry verticals

Enterprise firewalls with "OT add-on" modules often provide limited protocol support. Verify the specific protocol coverage for your environment before making a selection.

Certifications and environmental ratings. OT environments may require hardware that operates in extended temperature ranges, tolerates vibration, and meets industrial electromagnetic compatibility (EMC) standards. Vendors like Fortinet (FortiGate Rugged), Cisco (IR1100), Hirschmann, and Phoenix Contact offer industrially certified hardware.

High availability options. For critical process boundary points, the firewall must support high availability configurations — active/passive or active/active failover — with failover times compatible with process continuity requirements.

Failsafe behavior. Define required behavior in the event of firewall failure: fail-open (pass all traffic) or fail-closed (block all traffic). The choice depends on whether the greater risk is a security breach (fail-closed) or process disruption (fail-open). Clarify this with operations leadership before specifying hardware.

Management architecture. Firewalls should be manageable from a dedicated OT management network segment, not from the IT management network or the internet. Ensure the management interface can be placed on a separate network from the data plane interfaces.

Established vendors with strong OT market presence include:

• Fortinet: FortiGate Rugged series with dedicated FortiOS OT profile and ICS-specific protocol support
• Cisco: Industrial Security Appliances (ISA3000) with ICS-specific DPI via Cisco Firepower signatures
• Dragos / CRITIFENCE: Passive inspection focused, not enforcement firewalls but complementary detection
• Tofino Security (Honeywell): Purpose-built OT firewall with deep OT protocol support
• Claroty (via OT network modules): Inspection capabilities complementary to perimeter firewalls

Rule Design Principles for OT Networks

Default Deny: The Non-Negotiable Foundation

Every OT firewall should be configured with a default-deny policy: unless traffic is explicitly permitted by a rule, it is blocked. This is often stated as best practice but less often implemented in practice, because default-permit was the original state of most OT networks and converting to default-deny requires documenting every legitimate traffic flow.

That documentation effort is itself valuable. The process of identifying every permitted communication in an OT network produces a map of process dependencies, vendor connectivity requirements, and data flows that is essential context for any security or architecture decision.

Default deny must be combined with complete logging: all permitted and denied traffic should be logged with sufficient detail for forensic analysis and rule review. Log without reviewing is insufficient, but log without log is unacceptable.

Rule Structure: Five-Tuple Plus Protocol Action

OT firewall rules should specify, at minimum:

• Source IP address or range
• Destination IP address or range
• Destination TCP/UDP port
• Protocol
• Action (permit/deny)

For firewalls with industrial protocol DPI capability, rules at conduit boundaries should include additional protocol-specific actions:

Modbus TCP rules should specify:

• Permitted function codes (read coils: 0x01, read registers: 0x03, write single coil: 0x05, write single register: 0x06, write multiple registers: 0x10) — deny all others unless justified
• Permitted unit identifiers (device addresses) where known
• Permitted register/coil address ranges relevant to the permitted function

DNP3 rules should specify:

• Permitted function codes
• Permitted source and destination station addresses
• Whether unsolicited responses are permitted

EtherNet/IP / CIP rules should specify:

• Permitted CIP service codes (Get_Attribute_Single, Set_Attribute_Single, etc.)
• Permitted CIP class and instance combinations for the specific devices communicating

OPC UA rules should enforce endpoint URL filtering to ensure only authorized OPC UA server endpoints are accessible, and should inspect session establishment to verify certificate-based authentication is occurring.

Rule Naming and Documentation Standards

Every firewall rule should have:

• A unique identifier that maps to a change control record
• A plain-language description of the business or operational purpose
• The date the rule was created and the change request that authorized it
• The system owner or team responsible for the communication the rule permits
• A review date — the date when this rule's continued necessity should be verified

Rules without documentation create technical debt that compounds over time. After three years and multiple engineers, nobody knows why rule 47 permits TCP 44818 from 10.10.5.0/24 to 192.168.10.15. Without documentation, nobody can safely remove it. The rule remains because removing it is risky and leaving it is convenient — a pattern that produces firewall rule sets that no longer reflect actual security requirements.

Zone-to-Zone Rule Design

When designing rules between security zones, use the IEC 62443 conduit concept as the organizing model: every conduit between zones should have an explicit policy defining which traffic flows are permitted, in which direction, with which protocol constraints.

Develop a zone communication matrix before writing rules:

Every cell in the matrix should have an explicit rule. Any cell not in the matrix should be blocked by default deny.

Implementation Methodology

Phase 1: Traffic Discovery and Baselining

Before writing rules, understand what traffic actually flows in the environment. Attempting to write rules from documentation alone will produce rules that are either too permissive (because documentation is incomplete) or that block legitimate traffic (because undocumented flows exist).

Traffic discovery methods:

• Deploy passive OT monitoring on network TAPs at key boundary points for a minimum of 30 days before implementing firewall enforcement
• Use the passive monitoring data to build a communication map: every source-destination-protocol combination observed
• Cross-reference the observed communication map against engineering documentation and vendor documentation for each OT system
• Identify undocumented flows and resolve them: determine whether each undocumented flow is a legitimate communication that needs to be documented, or an unauthorized flow that should be blocked

The passive monitoring phase is not optional. Organizations that skip it and write rules from documentation alone will experience blocked communications after enforcement that they did not anticipate, potentially causing process disruptions.

Phase 2: Rule Writing and Lab Testing

With the communication map established:

1. Write draft rules covering every permitted flow identified in the discovery phase
2. Translate each flow into the most specific rule possible: specific source IP, specific destination IP, specific port and protocol, specific protocol action where DPI is available
3. Review the draft rule set against the zone communication matrix for completeness
4. If a test or lab environment is available, test rule enforcement against the communication map to verify that permitted flows pass and denied flows are blocked
5. Review with the operations team: present the proposed rule set to the control system engineers responsible for each zone and have them verify that all legitimate communications are covered

Phase 3: Staged Enforcement

Never deploy a new OT firewall directly to enforcement mode without a staged transition. The consequences of a misconfigured rule blocking a process-critical communication can be severe.

Stage 1 — Monitor mode (2-4 weeks): Deploy the firewall in passive inspection mode, generating alerts for traffic that would be denied by the rule set but taking no enforcement action. Review alerts daily. Identify any legitimate traffic that was missed during discovery.

Stage 2 — Partial enforcement: Enable enforcement on non-critical conduits first. Monitor for blocked traffic alerts. Investigate and resolve any legitimate traffic that was blocked before proceeding.

Stage 3 — Full enforcement with rollback plan: Enable enforcement on all conduits. Maintain the ability to quickly revert to monitor mode if critical communications are found to be blocked. Establish a 24-hour operations monitoring period with escalation procedures if process anomalies occur.

Phase 4: Verification and Acceptance

After full enforcement:

• Confirm with operations that no legitimate process communications have been affected
• Verify that monitoring and logging are functioning correctly
• Document the final rule set with complete documentation for every rule
• Conduct a simulated traffic test to verify that representative attack traffic is being blocked

Change Management for OT Firewall Rules

Every Rule Change is a Change Control Event

Firewall rule changes in OT environments should follow the same change management discipline as any other OT configuration change. Every rule addition, modification, or deletion should require:

1. A written change request specifying the communication to be permitted, the source and destination systems, the operational justification, and the requesting team
2. Technical review by the OT security team to verify the rule is as specific as possible and does not inadvertently open broader access than required
3. Approval by the system owner for the destination zone
4. A maintenance window appropriate for the criticality of the change, or an emergency process for urgent changes with post-change review
5. A test plan and rollback procedure documented before the change is made
6. Post-change verification that the intended communication now works and no unintended traffic has been permitted

Emergency rule changes — required urgently to resolve production issues — should be permitted through an expedited approval process but must receive retroactive full review within 24-48 hours. Emergency rules added without review frequently become permanent unauthorized access pathways.

Temporary Rules and Expiration

Many legitimate OT firewall rules are temporary: vendor maintenance access, a configuration change window, a temporary integration during commissioning. These rules should have explicit expiration dates configured in the firewall management system, with automated alerts when they are about to expire.

Temporary rules that are not actively expired become permanent through inaction. Most firewall management systems support automatic rule disabling at a configured expiration time. Use this feature for every rule with a defined temporary purpose.

Rule Review Cadence

Beyond change-driven review, conduct periodic rule review on a defined schedule:

• Quarterly: Review all rules modified or added in the previous quarter. Confirm that the operational justification remains valid.
• Annual: Full rule set review. For every rule, confirm that the source and destination systems still exist, the communication is still operationally required, and the rule is as specific as possible.
• Event-driven: After any network change (system decommissioning, IP address change, VLAN restructuring), review all rules that reference affected addresses.

Annual rule reviews consistently identify rules for systems that have been decommissioned, temporary rules that were never removed, and rules that were written overly permissively and can now be tightened.

Performance Considerations for Industrial Firewalls

Deep Packet Inspection Overhead

Industrial protocol DPI requires the firewall to inspect packet payloads rather than just headers. This increases processing load and can introduce latency. For OT networks with real-time timing requirements, latency measurement is essential:

• Measure baseline latency on critical communications before deploying firewall enforcement
• Measure latency after DPI-enabled enforcement and confirm the delta is within operational tolerances
• For real-time control loops with sub-100ms timing requirements, evaluate whether DPI on every packet is feasible or whether lighter-weight header-only inspection must be used

Most modern industrial firewalls are designed for low-latency operation on typical OT traffic volumes. Performance concerns are most acute in high-throughput data historian environments or in networks with many simultaneous active PLCs.

High Availability and Failover Timing

For firewalls protecting critical process boundaries, configure high availability with failover timing tested and validated:

• Active/passive HA with sub-second failover for the most critical conduits
• Test failover under realistic traffic load to confirm that process communications recover within acceptable time
• Configure monitoring for HA state changes with alerting to the OT security team and operations

Conclusion

OT firewall design and rule management is a discipline, not a one-time configuration task. The rule set that correctly reflects your OT network's security requirements today will diverge from reality as systems are added, decommissioned, and reconfigured over time. The change management processes, review cadences, and documentation standards described in this guide are what maintain the alignment between the rule set and the actual security requirements of the industrial environment.

A well-maintained OT firewall is a powerful detective as well as a preventive control. The logs of permitted and denied traffic, reviewed consistently, provide visibility into communication patterns that complement passive OT monitoring and provide an independent record of network behavior. Use that record.

Beacon Security provides OT firewall architecture design, rule development, and ongoing rule management services for industrial environments. We help organizations build and maintain firewall programs that genuinely enforce their IEC 62443-aligned segmentation architecture. Contact us to assess or design your OT network segmentation controls.