Firewall rule audit: how to review a rulebase

A firewall rule audit reads every rule in a firewall’s policy and asks two questions: does this rule still do anything, and should it be allowed to do what it does? The first is rule hygiene. The second is the one that matters for security, and in an OT network it is mostly about which rules let traffic cross the boundaries between zones.

This guide walks through a rule review from the inputs to the decision on each rule. It works for any firewall; the examples come from an OT network, where a wrong change can stop production, so every step leans toward evidence before action.

What you need before you start

A rule review is only as good as what it reads. Collect four things:

• The configuration export. The full policy in evaluation order, with the address, service and application objects it refers to. On managed firewalls, include the shared rules that the manager pushes above and below the local ones, because they change what every local rule matches.
• A traffic log. The sessions the firewall logged, with the rule that matched each one. The window should cover normal production and the work that happens rarely: batch changes, shift handovers, month-end jobs, maintenance. A day of traffic cannot prove that a quarterly engineering rule is unused.
• A zone map. Which zone each interface or address belongs to, what each zone does, and in OT, which Purdue model level it sits at. The map is what turns “rule 41 allows A to B” into “rule 41 allows the business network to reach the controllers.”
• Rule ownership. Who asked for each rule and why, from change tickets, rule comments or the people who run the firewall. Many rules will have no owner on record. That is a finding in itself.

Step 1: check rule hygiene

Hygiene problems are visible in the configuration alone. They rarely open a path on their own, but they hide the rules that do, and they make every later change riskier.

• Shadowed rules. A rule above takes everything a rule below would match, with the opposite action, so the lower rule never applies. A deny shadowed by a broad allow is the dangerous case: the block someone wrote does nothing.
• Redundant rules. A rule above already matches everything a rule below would match, with the same action. The lower rule is dead weight, but removing the upper one later would bring it back to life.
• Overlapping rules. Rules that partly match the same traffic, sometimes with different actions. Order decides the result, which makes the policy hard to reason about.
• Disabled rules. Rules left in the policy but turned off. They are history, not protection, and they can be turned back on by mistake.
• Rules without logging. An allow that does not log leaves no record of what crossed. A final deny that does not log hides what tried to.
• Any-any and broad rules. An allow with any source, any destination or any application allows more than any conduit needs. See any-any firewall rules.

Step 2: read the rules against the traffic

The traffic log shows which rules carry sessions and what those sessions are. Read them together:

• Rules with traffic. For each allow rule that matched sessions, list the sources, destinations and applications it actually carried. That list is usually much smaller than what the rule allows, and it is the starting point for narrowing it.
• Rules without traffic. A rule that matched nothing in the window is a candidate for removal, not a proven one. Check the window against the rule’s purpose first: backup, disaster recovery, vendor support and annual maintenance rules can sit quiet for months.
• Traffic the design forbids. Sessions that cross the zone design, whatever rule allowed them: business hosts reaching supervisory or control zones, internet or VPN sessions landing on control networks, OT devices opening sessions to the internet, and industrial protocols on paths that should never carry them. These are the findings that matter most, and the rule behind each one is the one to fix first.

NIST SP 800-82r3 makes the same case. Section 6.2.1.3 recommends configuring firewalls to permit only explicitly authorized communication between segments, and notes that reviewing recorded traffic may reveal communication nobody documented. The NIST SP 800-82r3 guide has the detail.

Step 3: decide what happens to each rule

A rule review ends with a decision on every rule in scope, not only a list of problems. Five decisions cover almost every case:

Decision	When it applies
Keep	The rule carries the traffic its conduit needs and nothing the design forbids. The owner still confirms its purpose.
Narrow	The rule carries needed traffic, but also allows more: any source, any application, or a path the design forbids. Rewrite it to name what the traffic shows.
Recertify	The rule depends on something a firewall review cannot judge, such as a user, group or schedule condition. Its owner confirms who needs it and why.
Remove	The rule is disabled, shadowed with no traffic, redundant, or unused over a window long enough to trust.
Retire	A planned change replaces the rule, so it goes when that change is applied.

Two rules keep the decisions honest. First, every decision names its evidence: the sessions, the rule above that shadows it, or the condition that needs an owner. Second, the asset owner decides. A review recommends; the people who run the process confirm, give the business reason for each rule they keep, and set the date of the next review.

Step 4: plan the change safely

Removing or narrowing a rule in OT is a production change. A rule that looks unused may carry the one session a line needs at shutdown.

• Make changes in a planned window, with the operations team aware.
• Write the rollback for each change before applying it, in the firewall’s own commands.
• Where the evidence is thin, disable before deleting, and keep logging on the disabled rule’s path, so anything that needed it shows up in the log instead of failing silently.
• Inside OT, between cells, prefer rules that log first and enforce later, once the log shows the conduit carries only the flows on record.

The change plan guide covers what each change should carry, the safe order and the retest.

What a firewall rule audit should produce

A finished review leaves four things behind:

1. Findings with evidence. Each problem with the rule, the sessions and the hosts behind it, and its severity.
2. A rule review sheet. One row per rule in scope, with the decision, the reason, the owner, the business reason and the next review date.
3. A change plan. The ordered rule changes that close the findings, each with a rollback, sized for a change window.
4. A re-check. After the window, a fresh traffic log read against the new rules, to show the paths are closed and nothing needed was cut.

Together they are the evidence an auditor or insurer asks for; see proving OT segmentation.

IEC 62443-3-3 SR 5.2 (zone boundary protection) asks for communication at zone boundaries to be monitored and controlled; a rule review with its traffic is how a site shows that for each conduit. The IEC 62443 guide covers the requirement.

How SegAudit runs a rule review

SegAudit reads the firewall configuration and traffic log you collected, offline, and reviews every allow rule that touches OT. Each rule gets one of the five decisions above, with the reason, and the review sheet exports as CSV or markdown for the owners to sign off. Rule hygiene sits alongside it: shadowed, redundant and overlapping rules, rules that never match, and rules without logging.

In the Northline sample (a made-up three-site company that ships with SegAudit), 66 allow rules touch OT: 12 go back to their owners to recertify, 2 are removed, 30 are retired by the change package and 22 are kept. The shadowed rules include a deny, deny-interzone-default, that never blocks anything because allow-any-temp above it allows all of it first.

To see what SegAudit catches in one of your own exports, run the free Quick check.

Common questions

How often should firewall rules be reviewed?

On a schedule your security program sets, and after every significant change. Many programs review at least once a year; PCI DSS v4.0 asks for network security control configurations to be reviewed at least every six months. In OT, review after commissioning work and vendor visits too, because that is when temporary rules appear.

What is a shadowed firewall rule?

A rule that never applies because a rule above it, with the opposite action, already matches everything it would match. A shadowed deny is the risky case: someone wrote a block, but the broad allow above it lets the traffic through. The fix is to decide what the deny was meant to stop and narrow the allow.

Can unused firewall rules be deleted straight away?

Not on the evidence of a short window. A rule can sit quiet for months and still be needed for backup, disaster recovery or annual maintenance. Check the log window against the rule’s purpose, ask its owner, and in OT disable it in a change window with a rollback before deleting it.

What is the difference between a rule audit and a penetration test?

A rule audit reads the firewall’s configuration and logs to find what the rules allow and what actually crossed. A penetration test tries to get through. A rule audit touches nothing on the network, which is why it suits OT, where active testing can disturb controllers.