What a firewall audit actually covers

A firewall audit answers three questions: what does the rule base actually permit, is that what you intended, and can you account for every change since the last review. None of those questions are answered by traffic logs. They are answered by configuration: rules, objects, NAT, and the history of who touched them. The checklist below is vendor-neutral and works whether your estate is Palo Alto, FortiGate, Cisco, Juniper, or all of them at once.

Rulebase hygiene (checks 1–5)

  1. Inventory every enforcement point. Firewalls, management planes (Panorama, FMC), and the ACL-bearing routers and switches between them. An audit scoped to “the firewalls we remembered” is not an audit.
  2. Find shadowed rules. A shadowed rule can never match because an earlier rule already covers its traffic. Shadowed rules are dead configuration that hides intent; auditors flag them, and attackers love the confusion they cause during incident response.
  3. Find redundant rules. Rules whose effect is already delivered elsewhere. Removing them changes nothing about what the firewall permits, and every redundant rule you carry makes the next review slower.
  4. Flag overly broad rules. Any-any sources, /8 destinations, service “any”. Rank them by exposure so the widest-open rules are handled first, not discovered on page forty of the report.
  5. Resolve every object. A rule that reads “web-group to db-group” tells an auditor nothing. Expand nested address and service groups to the real IPs, protocols, and ports before you assess a single rule, because that is what the firewall enforces.

Effective access and exposure (checks 6–9)

  1. Compute effective access for critical segments. Not rule by rule, but end to end: what can actually reach the database VLAN, the management network, the OT segment, once every rule, object, and NAT translation is taken together. This is the number one question a policy analyzer exists to answer.
  2. Reconcile inbound NAT with intended exposure. Every destination NAT and VIP is an internet-facing promise. List them, resolve them to real internal targets, and check each against what you meant to publish.
  3. Review VPN and remote-access scope. IPSec tunnels, GlobalProtect and SSL-VPN populations, and the policies that govern what remote users reach once inside.
  4. Verify management-plane access. Who can reach the firewall’s own management interfaces, from where, and over what. The rule base protecting your network is only as safe as the path to its admin login.

Change control (checks 10–12)

  1. Attribute every change in the audit window. Each policy change since the last review should map to a named admin and, ideally, a ticket. Unattributed changes are findings by definition.
  2. Diff current configuration against the last audited baseline. A side-by-side diff of then vs now is the fastest honest answer to “what changed this year?” If you cannot produce one, the audit starts from zero every time.
  3. Catch the changes that bypassed logging. API pushes, bulk imports, and firmware upgrades mutate device state without writing audit-log entries. Snapshot-based change detection catches them; log-based tooling structurally cannot.

Operational hygiene (checks 13–15)

  1. Verify the default-deny. Confirm every rule base ends in an explicit deny and that nothing broad sits just above it “temporarily”. Temporary rules from two years ago are a genre of audit finding.
  2. Check naming and ownership conventions. Rules and objects should say what they are for and who owns them. Convention drift is how a rule base becomes unauditable in the first place.
  3. Export the evidence. Auditors want artifacts: the rule inventory, the hygiene findings, the change timeline. Producing them should be an export, not a week of screenshots.
An audit finding is just a question you could have answered a quarter earlier.

Automating the checklist

Every check above can be done by hand, once, painfully. The reason they usually are not done quarterly is that hand-resolving nested objects across four vendors takes days. This is the job SAMURAI’s Policy Analyzer automates: it computes effective access with objects and NAT resolved, flags shadowed, redundant, and overly broad rules, and scores every rule by exposure, across Palo Alto, Cisco FTD, FortiGate, Juniper SRX, and ACI in one canonical model. Change attribution and snapshot diffs cover checks 10–12, and any table exports for the evidence file. Deployment is one docker run, self-hosted.

Two honest boundaries: SAMURAI works from configuration state, so it does not do usage-based cleanup (“zero hits in 90 days” needs traffic hit counts), and it does not run rule-recertification or approval workflows; the policy-management suites own those. For everything else on this list, the checklist becomes a dashboard you review instead of a project you dread.