Deploying Firewalls Without Breaking ICS Traffic: Technical Strategies for Critical Environments

The deployment of firewalls in industrial control system (ICS) networks is not a trivial task. From the early days of perimeter defense philosophies (“moats and castles”) to present-day microsegmentation and Zero Trust ideologies, industrial infrastructure has historically lagged behind IT in secure connectivity—and with good reason. Unlike typical enterprise IT networks, ICS environments carry unforgiving real-time constraints, proprietary and legacy protocols, and safety or uptime mandates which render indiscriminate traffic filtering both impractical and dangerous.

This article aims to bridge the gap between robust network security and operational reliability. We'll cut through superficial best practices and lay out the technical specificities, historical context, and deployment approaches for integrating firewalls into critical OT networks without compromising ICS traffic. Whether you are a CISO seeking macro-architecture guidance, or an operator dissecting Modbus packets, these are operationally workable and historically grounded insights.

The Roots: Why Industrial Networking is Different

Early ICS Connectivity: Security by Isolation

For decades, industrial networks operated in relative physical and logical isolation. The Purdue Enterprise Reference Architecture (PERA, published in 1990), which is still cited in various forms, formalized concepts of “network levels”—with Level 1 (control) and Level 0 (process) typically being air-gapped or lightly connected via serial links. In this paradigm, security equaled separation.

However, as remote operations, IIoT integration, and cost pressures prompted the adoption of Ethernet, TCP/IP, and wireless connections, ICS environments became exposed to familiar IT threats, but with different stakes: downtime or misoperation could translate to lost millions, regulatory violations, or even physical harm.

Legacy Protocols vs. Modern Threat Landscape

Common industrial protocols—such as Modbus/TCP (first specified in 1979), DNP3, PROFINET, and vendor-specific variants—pre-date the modern security landscape by decades. These protocols usually:

• Lack native authentication and encryption

• Are “chatty,” broadcasting critical control messages at millisecond intervals

• Expect low or predictable latency, with high intolerance for dropped or delayed packets

• Are often minimally documented, inconsistently implemented, or locked-in by vendor blackboxes

Firewalls: A Very Short Technical History

Genesis and Evolution

First appearing commercially in the late 1980s (e.g., the DEC SEAL and AT&T Bell Labs circuit-level firewalls), firewalls initially served as basic packet filters—allowing or blocking traffic based solely on IP addresses and TCP/UDP ports. Over time, stateful inspection and application-layer (Layer 7) deep-packet inspection (DPI) emerged to manage increasingly complex and application-aware traffic.

Meanwhile, the industrial world adopted IT networking at a measured, uneven pace. Only in the 2010s did standards like IEC 62443 codify network segmentation and traffic inspection as fundamental security strategies for ICS. Today, most industrial switches, routers, and security appliances advertise firewall capabilities, but their deployment remains fraught. Why?

Challenges of Deploying Firewalls in ICS

1. Protocol Complexity and Vendor Lock-in

Most COTS firewalls are designed for HTTP, SMTP, and similar protocols, not Modbus, CIP, or legacy HART-over-IP. DPI modules for ICS protocols are rare and often limited, while protocol deviation—even benign—can break communications with critical controllers. Vendors frequently rely on proprietary protocol extensions or non-standard port allocations, making configuration and troubleshooting a non-trivial effort.

2. Real-Time and Determinism Requirements

Traditional IT traffic can tolerate transient latency or jitter introduced by security appliances. ICS communications, especially between low-level PLCs and field devices, cannot. Even millisecond delays can trigger process failures or deranged safety systems. Stateful inspection and DPI increase latency and processing time—sometimes fatally.

3. Maintenance and Change Management Constraints

Unlike IT assets, which may be patched or rebooted on scheduled cycles, ICS assets often must run uninterrupted for years. The introduction of inline firewalls demands planned outages, rollback plans, exhaustive validation, and sometimes vendor re-certification.

4. Operator Visibility and the Human Factor

Operators and controls engineers are generally not firewall experts. Firewall logs, rulebases, and troubleshooting processes must be designed for maintainability and ease of diagnosis, lest a misconfiguration create confusion during incidents—or, worse, cause an extended outage.

Deployment Strategies: Getting It Right

Establishing the “Zones and Conduits” Model

Inspired by consultants but enshrined in the IEC 62443 series, the “zones and conduits” approach segregates the network into logical containers (“zones”) based on trust and function (e.g., Safety Instrumented Systems, historian networks, corporate WAN). “Conduits” define the permissible communications between zones, typically enforced by firewalls.

• Map Out Traffic Flows: Use passive asset discovery tools and actively monitor traffic to enumerate all ICS protocol flows, timing, and endpoints. Manual, vendor-assisted topology mapping remains essential, especially for legacy installations.

• Define Minimal Conduits: Explicitly specify ports and protocols required for every zone-to-zone flow. Err on the side of “least privilege,” avoiding “any-to-any” or “full allow” rules, even as “temporary” measures.

Choose the Right Firewall Type and Placement

• Industrial-grade, inline firewalls should protect inter-zone boundaries—primarily separating IT and OT domains, and between critical process levels (e.g., Level 3 to Level 2 in PERA).

• Where legacy devices or high determinism is required, use tap/span (mirroring) for monitoring rather than inline inspection. Selective inline enforcement can be introduced after exhaustive validation.

• Application-aware firewalls deserve consideration only if the product’s DPI engine robustly supports native ICS protocols and has been tested in your environment. Otherwise, stick to tightly controlled port-level rules, with continuous monitoring.

Handling Known ICS Protocol Pitfalls

• Modbus/TCP: Uses TCP/502. Many implementations rely on persistent, high-frequency polling. Apply connection timeouts and session limits carefully; even “stateful” tracking can disrupt cyclic traffic if not configured to accommodate keep-alive intervals and bursty connections.

• UDP-based protocols: (such as some EtherNet/IP or proprietary poll-response traffic) do not benefit from TCP’s built-in session validation. Firewalls must implement suitably relaxed state entries to avoid unexpected drops.

• Broadcast/multicast discovery: Some controllers depend on broadcast traffic for device discovery or redundancy. Ensure such traffic is not inadvertently blocked when segmenting by subnet or VLAN.

• Non-standard ports and vendor extensions: Document and test for alternative port usage or protocol “tunneling.” Some vendors wrap control protocols within HTTP or proprietary encryption, complicating deep inspection or port-based filtering.

Testing and Validation: No Shortcuts

Real-world ICS networks often uncover protocol idiosyncrasies, undocumented flows, and edge cases (e.g., firmware updates, time synchronization, engineering station communication). Adopt a structured testing methodology:

1. Lab First: Replicate traffic flows using representative devices and network configurations. Test for both expected functionality and edge failure cases.

2. Monitor and Baseline: Use protocol-aware analyzers (e.g., Wireshark with ICS decoders, vendor diagnostics) to baseline traffic before and after firewall installation.

3. Staged Rollout: Deploy firewalls in “monitor-only” or bypass modes initially. Gradually enable rule enforcement, with rollback plans and “out-of-band” remote access in case of lockout.

4. Involve Operations: Controls engineers should be involved in test-plan creation, acceptance, and troubleshooting. No deployment is successful if it alienates the operators who rely on the traffic.

Case Notes: ICS Firewall Outages

Several real-world incidents illustrate common pitfalls:

• Botched ARP Filtering: A site segmented Level 1 traffic with VLANs; a firewall mistakenly filtered ARP broadcasts, causing controller isolation and a process shutdown lasting hours.

• Keepalive Timeouts: Energy sector deployment set TCP session idle timeouts to “default” (5 minutes); polling intervals exceeded this during a non-critical process, and reconnections failed post-maintenance—halting control.

• DPI “Silent Drops”: A building automation deployment enabled DPI for BACnet MS/TP, but unknown proprietary extensions triggered silent packet drops with no clear error logs. Days of troubleshooting ensued, only resolved after disabling application-layer inspection and reverting to explicit port allow-lists.

Bridging IT/OT Cultures for Secure Deployments

Collaboration, Not Collision

Firewalls can become flashpoints between IT-driven security mandates and OT-driven operational continuity. Successful deployments depend on cross-disciplinary teams:

• Joint Architecture Reviews: Formalize regular exchanges between IT (network/security) and OT (operations/engineering) teams. Review proposed segmentation, rules, and monitoring approaches.

• Unified Documentation: Produce up-to-date, accessible diagrams of network topology and access dependencies—including those informal or “one-off” connections common in ICS.

• Incident “Tabletops”: Simulate device lockouts or network denial events under controlled conditions. Assign roles, practice response, and document lessons learned for inclusion in playbooks.

Conclusion: Pragmatism and Operational Awareness

The addition of firewalls to ICS networks is neither a “checkbox” nor a simple translation of IT architectures. ICS environments demand rigorous mapping, thorough testing, hard-won operational understanding, and ongoing collaboration between IT and OT teams. The technical landscape continues to shift: protocol normalization, convergence of IT/OT standards, and better tooling are slowly demystifying firewall deployment for critical applications. Yet the essential truth remains—no security control is worth the cost of a process outage, and “deny all, allow by exception” requires an honest reckoning with your operational realities.

Take it from decades of field failures and hard-earned fixes: deploy firewalls only as fast as your network can tolerate. Test in the real world, communicate with your operations people, and never underestimate the stubborn chaos of legacy ICS traffic.