Firewall Rule Audit: How to Audit a Rulebase and Report Findings

A firewall rule audit is a point-in-time review of every rule in a firewall rulebase. It tests each rule against three questions: is it used, is it still needed, and is it as narrow as it should be? The output is a findings register with one row per problem rule. Each row carries the evidence (config line, hit count, last hit date), a risk score, a named owner and a recommended action. That register, a short summary and a remediation plan together make up the audit report.

Two neighbouring exercises get confused with it. In rule recertification, every rule owner re-approves their rules on a schedule. A compliance audit against ISO 27001 controls asks whether the whole control set meets a standard. The rule audit sits underneath both: it finds the broken, risky and dead rules and proves it with data. The table shows where each one starts and stops.

What does a firewall rule audit look for?

A firewall rule audit looks for eight kinds of finding. Four concern rule logic (shadowed, redundant, overly permissive, risky services), two concern usage (unused and expired temporary rules) and two concern governance (no owner, no logging). Each one needs different evidence, which is why the audit collects the configuration, the usage counters and the rule metadata as separate inputs.

Shadowing and redundancy need network math. Every rule has to be compared with every rule above it on source, destination, service and action. For 1,000 rules that is 499,500 pairs, so nobody does it reliably by hand past a few hundred rules. A minimal shadowing case looks like this:

Rule 15: ALLOW 10.0.0.0/8  -> ANY            TCP/443
Rule 42: DENY  10.0.1.50   -> 192.168.1.100  TCP/443
# Rule 42 never fires: Rule 15 already allowed the traffic.

The rulebase optimization guide covers shadow, redundancy and conflict cases in more depth. For the audit, one point matters more than the taxonomy. In our experience the finding that carries real risk is the overly permissive allow rule that is in use. Zero-hit rules are clutter. A busy any-service rule into a server segment is exposure. An audit that only chases unused rules produces a tidy report and leaves the risk where it was.

How do you pull hit counts and rule usage per vendor?

Every major firewall platform counts how often a rule matches. The platforms differ in three ways that decide whether a zero means anything: where the counter is stored, whether it survives a reboot, and whether high-availability peers share it. Check those three points for each platform before the analysis starts.

Palo Alto Networks (PAN-OS)

The Policies view shows Hit Count, First Hit, Last Hit, Created and Modified for each rule, and the Policy Optimizer can filter a rulebase for unused rules within a time frame you choose (PAN-OS 11.1 admin guide, View Policy Rule Usage). According to that page, the hit count persists through reboots, dataplane restarts and upgrades unless someone resets it or renames the rule. It is not synchronized across HA peers, so you check each firewall or read it through Panorama. On the CLI, show rule-hit-count vsys vsys-name vsys1 rule-base security rules all returns hit count plus first hit, last hit and last reset timestamps, and the same data is available through the XML API (pan.dev tutorial).

Fortinet (FortiGate)

diagnose firewall iprope show 00100004 <policy-id> prints a policy's hit count with first and last hit timestamps. The index is the policy ID, not the Seq# shown in the GUI (Fortinet technical tip). Two traps. The FortiOS 7.0.4 guide describes the policy-list hit count as a seven-day rolling counter, so a GUI zero says nothing about the last 90 days; use the last-hit timestamp instead. And the same technical tip notes that devices without a disk clear the counter statistics after a reboot, so check uptime on smaller models.

Check Point

SmartConsole shows a Hits column per rule. Hit Count is enabled globally by default for supported gateways, works independently of logging (it counts even when Track is None), and the management server keeps the data for the period set under Global properties > Hit Count, "Keep Hit Count data up to", with a default of 3 months (R81.20 Security Management guide). Turning Hit Count on or off takes effect only after a policy install. If your audit has to catch rules used once a year, raise the retention well before the audit, because a longer setting cannot recover data that was already dropped.

Cisco (Secure Firewall Threat Defense)

In the Management Center access control policy editor, Analyze > Manage Rule Hit Counts shows counts per device and filters for Never Hit Rules (Cisco documentation, View rule hit counts). The count increments on the first packet of a matching connection, persists through reboots and upgrades, and is kept separately by each unit of an HA pair or cluster. Rules with the Monitor action have no hit counts. On the device, show rule hits returns the same data.

Before you trust a zero

• Window length. 90 days is the common minimum. Rules tied to quarter-end, year-end or disaster-recovery tests need a window that covers those events, or an owner who can confirm them.
• Resets. Read the last-reset timestamp where the platform has one, and the uptime where a reboot clears counters.
• HA and clusters. Add up the counters of all members. A standby unit shows zero for traffic it never carried.
• Renamed or recreated rules. On PAN-OS a rename resets the count, and a rule rebuilt during a migration starts again from zero.

How do you score firewall rule risk?

Score firewall rule risk on exposure and impact, not on the finding type. A shadowed rule is low-risk clutter. An any-service rule from the internet into a server segment is critical. Both count as one finding, so a register without scores ranks them as equals. The model below is the one we use; adjust the weights to your environment.

Multiply the three factors for a score between 1 and 27, then add 2 points for each governance gap: no owner, no logging, an end date that has passed. In our model, 18 and above is critical and goes into the next change window. 9 to 17 is high and gets a 30-day target. 4 to 8 is medium and waits for the next cleanup batch. Lower scores go into housekeeping.

Score unused rules too. An unused rule that scores 18 is the cheapest high-risk fix in the whole report: nothing measurable depends on it, and removing it closes an open door.

How to audit firewall rules, step by step

Audit firewall rules in seven steps. The order matters because each step produces the evidence the next one relies on.

1. Fix the scope and freeze a baseline. List the firewalls, virtual systems and rulebases in scope. Export each configuration and record the export time and a file hash. Every finding refers to this snapshot. In a multi-vendor estate, export each platform in its native format.
2. Start the usage window early. Check counter retention, HA behaviour and the last reset date weeks before the analysis, using the vendor notes above.
3. Normalize the rules. Map every rule to one model: source, destination, service or application, action, zone, enabled state, comment, owner, ticket reference. Expand nested object groups, because a group three levels deep is where any hides.
4. Run the checks. Test every rule for the eight finding types. Tools do the pairwise shadow and redundancy maths; people review the permissive and risky-service findings, which need context.
5. Score and rank. Apply the risk model so the register sorts by risk, not by rule number.
6. Confirm the flagged rules with their owners. Only rules with findings go to owners here. Periodic sign-off of every rule belongs to recertification.
7. Report, then remediate through change management. Every fix is a normal change in your firewall change management process. Disable before you delete, as the rule decommissioning guide describes, and measure again at the next audit.

What goes into a firewall rule audit report?

A firewall rule audit report answers three questions for three readers. Management wants to know how healthy the rulebase is. The firewall team needs to know which rules to change and why. The auditor wants the evidence behind both. A report that covers all three has six parts:

• Summary: rulebases in scope, snapshot date, usage window, totals per finding type and per risk band.
• Rulebase metrics: total rules, share unused, share with any, share without an owner, share without logging. Compare them with the previous audit; the trend says more than any single number.
• Findings register: one row per finding, with the columns below.
• Remediation plan: change tickets and target dates per critical and high finding.
• Risk acceptances: findings the business keeps on purpose, each with an approver and an expiry date.
• Evidence appendix: configuration hashes, export method, hit-count source and window, tool and version.

The register is also your compliance evidence. PCI DSS v4.0.1 requires network security control configurations to be reviewed at least once every six months to confirm they are relevant and effective (Requirement 1.2.7), and every allowed service, protocol and port to be identified, approved and tied to a defined business need (Requirement 1.2.5), per the PCI SSC document library. A dated register with owners and actions evidences both. Our PCI DSS firewall guide and NIS2 evidence guide map the same output to those frameworks.

Frequently Asked Questions

How often should you audit firewall rules?

Audit firewall rules at least every six months where PCI DSS applies, since Requirement 1.2.7 sets that interval for configuration reviews. Outside PCI scope, our recommendation is twice a year plus once before any firewall migration. Every dead rule you migrate has to be translated, tested and documented on the new platform, which is why cleaning first is part of migration best practice.

What is the difference between a firewall audit and a firewall rule audit?

A firewall audit covers the whole deployment: firmware versions, high availability, admin access, logging, backups and the rulebase. A firewall rule audit covers only the rulebase content, rule by rule: whether each rule is used, needed, narrow enough, owned and logged.

Can you audit firewall rules manually?

Up to a few hundred rules on one firewall, a spreadsheet review works for the permissive, unused and ownership findings. Shadow and redundancy analysis does not scale by hand: 1,000 rules produce 499,500 rule pairs to compare on four fields each.

What should you do with unused firewall rules?

Do not delete an unused rule on the strength of a zero alone. Confirm the counter window covers the rule's business cycle, ask the owner, disable the rule and watch for breakage before you remove it. The decommissioning guide covers the full sequence.

Is a firewall rule audit the same as rule recertification?

No. The audit is a technical analysis that produces findings. Recertification is a governance process in which each owner re-approves their rules. Many teams feed audit findings into the recertification campaign, so owners decide on rules that already carry evidence.

Check your firewall change governance

An audit cleans the rulebase once. Whether it stays clean depends on how new rules get requested, approved and documented. The FwChange NIS2 Readiness Check asks ten questions about that change process and scores how well you could evidence it to an auditor. To see how the platform flags shadowed, redundant and over-permissive rules before a change reaches production, explore the FwChange platform.