What is firewall rule management?
Firewall rule management is the process by which an organisation designs, documents, changes, periodically recertifies and cleans up the rules on its firewalls, so that only traffic with a demonstrable need is allowed through. In an OT environment it is mainly about the rules at the boundaries between zones: between the office network and the IDMZ, between the IDMZ and the process network, and between production cells. A firewall is only as strong as its rule set; a poorly managed rule base turns an expensive industrial firewall into an open door.
🧠 Why do firewall rule sets decay over time?
A rule set usually starts out tidy, but grows with every project, every outage and every supplier who needs access “just for a moment”. After five to ten years, an OT firewall often holds hundreds of rules whose purpose nobody can remember. Typical causes:
- Rule bloat — new rules are added, old ones are never removed
- Any-any rules — during commissioning or troubleshooting, everything is opened up to get things moving
- Temporary rules that stay — a rule for a vendor or a factory acceptance test has no expiry date and is forgotten
- Undocumented rules — no owner, no ticket, no reason; nobody dares to remove them
- Shadowed and redundant rules — a broader rule higher up the list makes a more specific rule pointless
The result is a larger attack surface, slow audits and a rule base that can no longer be understood when an incident occurs.
🎯 Which principles make a good rule set?
| Principle | What it means in practice |
|---|---|
| Default deny | Everything is blocked unless a rule explicitly allows it; the final rule is always deny all with logging |
| Least privilege | As specific as possible: fixed source and destination IP, one port, one direction, ideally one function |
| Per conduit | Rules are grouped per conduit from the zones and conduits model, not per firewall interface |
| Business justification | Every rule has a description, an owner, a change reference and, where relevant, an expiry date |
| No direct IT-to-OT connections | Traffic between office and process always passes through a DMZ or IDMZ |
These principles are not a passing fad; they are written into the standards. IEC 62443-3-3 requires zone boundary protection in SR 5.2, with the requirement enhancement (RE 1) deny by default, allow by exception from security level 2 upwards. NIST SP 800-41 Rev. 1 (2009) has long recommended default deny for every firewall, and NIST SP 800-82 Rev. 3 (2023) advises a DMZ architecture so that traffic never flows directly between the corporate and OT networks.
🏭 What is different about firewall rules in OT?
In IT, a rule at port level is often enough. In OT it is not: a single open port can affect the whole process. Opening TCP 502 for Modbus TCP permits both reading registers and writing setpoints. That is why OT increasingly relies on protocol filtering with deep packet inspection:
- Modbus — allow only read functions (function codes 01–04) from the historian, and write functions (05, 06, 15, 16) only from the engineering workstation
- OPC UA — TCP 4840 by default, preferably only with encrypted sessions and fixed client certificates
- S7comm — TCP 102; a DPI firewall can block functions such as CPU stop or program block downloads for everything except the engineering workstation
Availability matters too. A rule that is too strict and blocks a SCADA poll stops production. Changes are therefore often trialled in monitor mode (log only) before they start blocking. This requires a next-generation firewall or an industrial firewall with OT protocol awareness; a classic stateful firewall sees only addresses and ports.
🔧 What does a rule table per conduit look like?
Below is an example for the conduit between the IDMZ and the zone Production Line 2:
| # | Source | Destination | Service | Action | Justification | Owner | Expires |
|---|---|---|---|---|---|---|---|
| 1 | Historian replica (IDMZ) | SCADA server L2 | TCP 4840, OPC UA, read only | Allow | Process data for business reporting | OT architect | — |
| 2 | Jump server (IDMZ) | Engineering workstation L2 | TCP 3389 | Allow | Remote maintenance, with MFA | OT operations | — |
| 3 | Engineering workstation L2 | PLCs line 2 | TCP 102, S7comm incl. download | Allow | Program changes under MOC | Process engineer | — |
| 4 | Vendor VPN (IDMZ) | PLC 2.4 | TCP 502, Modbus FC 03 | Allow | Commissioning of new dosing unit | Project manager | 31 Dec 2026 |
| 5 | Any | Any | Any | Deny + log | Default deny | — | — |
Rule 4 shows what a temporary rule should look like: narrow, with an owner and an expiry date.
🛠️ How do you set up a periodic review?
- Inventory — export every rule per firewall and map it to the conduits from your risk assessment under IEC 62443-3-2
- Collect hit counters — look back at least 90 days; in OT preferably longer, because some connections only occur during an annual shutdown
- Analyse — flag unused, shadowed, redundant and overly permissive rules (any source, any port)
- Recertify — put each rule to its owner: still needed, change or remove? Rules without an owner become candidates for removal
- Remove in stages — first disable the rule or switch it to log only, and delete it only after a safe observation period
- Report — record the outcome as audit evidence under NIS2 and national implementing legislation such as the Dutch Cyberbeveiligingswet, in force since 15 August 2026
For comparison, the payment card standard PCI DSS 4.0.1 requires in requirement 1.2.7 that network security control configurations are reviewed at least once every six months. No fixed interval is prescribed for OT, but an annual review at minimum is common practice, plus an extra review after every major plant modification.
🔄 How does firewall rule management relate to change management?
Every new or modified rule goes through change management, which in the process industry often means Management of Change (MOC). A good change request states the source, destination, service, conduit, justification, owner, end date and a rollback plan. The OT owner assesses the impact on the process; security assesses the risk. Once implemented, the rule set is stored as the new baseline in configuration management, so that later deviations stand out immediately. Changes made outside the process, for instance during a night-time outage, are registered afterwards as emergency changes.
🧰 Which tools and metrics help?
| Tool category | What it does |
|---|---|
| Firewall policy management | Analyses rule sets from multiple vendors centrally, automates changes and produces audit reports |
| Hit counter analysis | Shows which rules never see any traffic |
| Shadowed and redundant rule detection | Finds rules made obsolete by another rule |
| Logging to a SIEM | Makes denied traffic and rule changes visible to the OT SOC |
Useful metrics include the number of rules per conduit, the percentage of rules with an owner and justification (target: 100%), the number of any rules (target: zero), the number of expired temporary rules still active, and the percentage of rules recertified within the review period.
❓ Frequently asked questions
How often should firewall rules in OT be reviewed?
Common practice is to review firewall rules in OT at least once a year, and additionally after every major change to the installation. The payment card standard PCI DSS even requires a review every six months. IEC 62443 does not prescribe a fixed interval, but it does expect zone boundaries to be demonstrably managed.
What is an any-any rule and why is it dangerous?
An any-any rule allows traffic from any source to any destination on any port. Such a firewall rule completely removes the segmentation between zones. In OT, any-any rules are often created temporarily during commissioning and then stay in place unnoticed.
What is a shadowed firewall rule?
A shadowed firewall rule sits lower in the rule set than a broader rule that already handles the same traffic. As a result, the shadowed rule is never hit. Such rules clutter the rule base and can become active unexpectedly when rules are reordered.
Can a standard firewall block Modbus write commands?
No, a standard stateful firewall sees only IP addresses and ports and cannot tell a Modbus read from a Modbus write. That requires an industrial firewall with deep packet inspection. Such a firewall can allow or deny traffic per function code, for example 03 for reading or 16 for writing.
Who owns a firewall rule?
The owner of a firewall rule is the person or department with the business need for the connection, not the network administrator who enters the rule. The owner confirms at each review that the rule is still required. Firewall rules without an owner are candidates for removal.
Should the office network communicate directly with the OT network?
No, good practice under IEC 62443 and NIST SP 800-82 is that no direct connections exist between the office and OT networks. All traffic terminates in a DMZ or IDMZ, for example on a historian replica or jump server. The firewall rules enforce this separation.
📌 In summary
Firewall rule management ensures that every rule between OT zones is narrow, documented, owned and periodically recertified. With default deny, rules per conduit, protocol filtering and a fixed review process, the segmentation required by IEC 62443 stays effective for years.