A client of ours had 847 firewall rules. About 30% of them had not been hit once in the last 90 days. 40 allowed any-to-any traffic on ports nobody could explain. One rule opened the whole network to a vendor that had been decommissioned three years ago.

The firewall was doing its job. The ruleset had just accumulated years of debt.

This is what most firewall environments look like by year five. Not because the security team is bad at their job. Because rulesets drift. The usual review process is to tick the box on the annual audit, check nothing new broke, and move on.

A proper firewall audit finds all of it. Dead rules, shadowed ones, legacy exceptions, emergency workarounds that became permanent, and the compliance gaps that quietly expose the business to real regulatory action. Here is what we actually look at when we are hired to do one.

Why rulesets drift

Every firewall starts clean. A few core segmentation rules, a DMZ policy, some outbound egress controls. Six months in, nothing has drifted. Two years in, it is a different story.

Business pressure is usually the cause. A project needs an exception for a vendor to reach a payment gateway. A developer needs temporary SSH access to troubleshoot something in production. An acquisition brings a sister company’s network into scope and the quickest path to “make it work” is to open it up. Every one of those decisions is sensible in the moment. Most of them never get removed.

Staff turnover compounds this. The engineer who added rule 247 to let the Johannesburg office reach a specific reporting server left in 2022. Nobody now remembers what rule 247 does. It is still there because nobody wants to be the person who broke something by deleting it.

Published industry data puts real numbers on this. FireMon’s Insights reporting shows that around 30% of firewall rules in mature environments are completely unused, another 30-50% are redundant or purposeless on first assessment, and about 60% of enterprise firewalls fail an initial compliance check. Roughly 6% of rules have no owner or documentation of any kind. If that feels high, pull your own hit-count report. It usually isn’t.

What a real firewall review covers

Different engagements call for different depth. But there are six things that should be on the checklist for any firewall audit worth doing.

Rule hygiene

The biggest source of risk in most firewall rulesets is not overly permissive rules. It is dead rules that nobody has the confidence to remove.

We look for:

• Shadowed rules. Rule A is broader than rule B and sits above it, so rule B never evaluates. It might as well not exist. Every shadowed rule is either a mistake or a hint that the ruleset is not being maintained.
• Unused rules. Rules that have not triggered once in 90 days. Palo Alto, Check Point and Fortinet track this natively. On Cisco ASA you pull the hit counters with show access-list and compare over time.
• Overly permissive rules. Any-to-any on specific ports, or specific sources to any destination on high-risk ports like 3389, 22, 445, 3306.
• Redundant rules. Two or more rules covering the same match. Usually the result of an engineer not knowing the ruleset well enough to find the existing one before adding a new one.

We had a client whose ruleset had three separate rules permitting the same vendor to reach the same destination on the same port. Different sources. Different comments. All added by different people over four years. None of them should have existed.

Rule ordering and performance

Firewalls evaluate rules top-down in most policies. The most-hit rules should be at the top. They rarely are.

On a large ruleset this matters. Cisco ASA has explicit rule counters. Fortinet sorts by policy ID by default which has nothing to do with hit rate. Checking this is a one-hour exercise that usually lets us suggest a reordering that saves measurable CPU and latency on high-throughput firewalls.

Logging coverage

This is where compliance gets serious. If a rule is in place and nobody is logging hits on it, you cannot prove anything.

We check:

• Is logging enabled on the rules that matter (inbound management access, egress to known risky destinations, any-to-any rules that should never fire)?
• Are logs being shipped off-box to a SIEM or at least a syslog collector?
• Is retention set to match the compliance requirement (12 months is the PCI DSS baseline)?

If the answers are yes, no, and unclear, that is a finding.

Change management

Who can modify the firewall? What is the approval process? Is there a record of changes that links each one to a ticket and an approver?

Most of the time there is no record at all. Someone logs in, makes a change, commits, moves on. Six months later nobody can tell you why rule 247 was added. Documenting this gap is often the highest-impact finding from an audit. Fixing it stops the drift from continuing.

Segmentation

The rules are one thing. The segmentation they actually enforce is another.

We look at whether the firewall is isolating what it is meant to isolate. Production from corporate. Dev from production. Guest wifi from anything sensitive. The rules might be technically correct but if the servers have been moved, the segmentation it was designed for might not exist any more.

A firewall that thinks it is protecting a payment environment, but is actually sitting between two corporate subnets, is not providing the control your compliance documentation claims.

Benchmark alignment

This is the step most internal reviews skip. Is the device configured to an industry-agreed hardening standard, or to whatever the person who installed it remembered to set?

CIS maintains free firewall benchmarks for most major platforms. Current versions at time of writing:

• CIS Palo Alto Firewall 10 Benchmark v1.1.0
• CIS Fortinet FortiGate 7.4.x Benchmark v1.0.1 (released October 2025)
• CIS Cisco Firepower Threat Defense Benchmark v1.0.0
• CIS Cisco ASA 9.x Firewall Benchmark v1.1.0 (ASA platform reached end-of-sale December 2023, worth flagging)
• CIS pfSense Firewall Benchmark (current on cisecurity.org)
• Check Point: CIS retired all Check Point benchmarks in October 2025 due to a lack of subject-matter support. Means nothing for the controls themselves but it does mean no fresh benchmarking guidance going forward. Worth knowing if you run Check Point.

Every benchmark has two profile levels. Level 1 is baseline hardening that can be applied broadly without impacting usability. Level 2 is stricter, defense-in-depth, and can affect operations if applied without planning. We usually assess against Level 1 first, then flag Level 2 items that make sense for the specific environment.

What the benchmarks cover (consistent categories across vendors):

• Device management plane (admin authentication, SSH/HTTPS only, no telnet/HTTP, role-based access, session timeouts)
• Authentication and AAA (TACACS+ or RADIUS, password policy, strong crypto)
• Logging, NTP, SNMP (central syslog, authenticated NTP, SNMPv3 only, no default community strings)
• Ruleset and traffic policy (default-deny, no any-any, explicit deny at end, logging on critical rules)
• Software integrity, image verification, routing protocol authentication

Compliance mapping

Different regulations care about different things. For a South African client the typical mapping looks like this.

POPIA (South Africa)

Firewall controls map to Condition 7 – Security Safeguards, sections 19 to 22 of the Act.

Section 19(1) requires “appropriate, reasonable technical and organisational measures” against loss, unauthorised access, or unlawful processing. Section 19(2) requires you to identify risks, maintain safeguards against them, and verify that safeguards are effectively implemented on a regular basis. That language directly supports periodic firewall review as a POPIA safeguard obligation.

Two enforcement trends worth knowing about. The Information Regulator launched a mandatory online eServices Portal on 7 April 2025 for reporting “security compromises” under section 22. That is the same portal you would have to use to report a breach caused by a firewall misconfiguration. The maximum administrative fine under POPIA is ZAR 10 million.

PCI DSS 4.0.1

The current version of PCI DSS is 4.0.1, released June 2024, with full enforcement of 4.x future-dated requirements from 31 March 2025. PCI DSS 4.0 renamed “firewalls” to “Network Security Controls” (NSCs), which covers perimeter appliances, virtual firewalls, cloud security groups, and host-based firewalls under the same control set.

Requirement numbers worth quoting in findings:

• 1.1.2 Roles and responsibilities for NSC activities must be documented
• 1.2.1 NSC configuration standards must be defined
• 1.2.5 All services, protocols and ports allowed must be identified, approved, and have a business need
• 1.2.6 Security features defined for insecure services or protocols
• 1.2.7 NSC configurations reviewed at least once every six months
• 1.3.x Network access between CDE and untrusted networks restricted
• 1.4.x Controls between trusted and untrusted networks

Logging retention for PCI DSS 10.5.1 is 12 months, with at least three months immediately available.

ISO 27001:2022

ISO 27001:2022 replaced the 2013 edition. Annex A was reduced from 114 to 93 controls organised into four themes (Organisational, People, Physical, Technological). Eleven controls are new. The firewall-relevant controls:

• A.8.15 Logging
• A.8.16 Monitoring activities (new in 2022)
• A.8.20 Networks security
• A.8.21 Security of network services
• A.8.22 Segregation of networks
• A.8.23 Web filtering (new in 2022)

If your last ISO 27001 audit used the 2013 mapping, your Statement of Applicability is out of date and the firewall control evidence you prepared for it probably does not line up cleanly to the new controls.

NIST references

• NIST SP 800-41 Revision 1 “Guidelines on Firewalls and Firewall Policy” is the canonical NIST publication. It has not been withdrawn, but it was written in September 2009 and shows its age on anything cloud-adjacent. Still useful for its policy and ruleset guidance.
• NIST SP 800-53 Revision 5 controls SC-7 (Boundary Protection) and AC-4 (Information Flow Enforcement) are the ones to cite for federal-adjacent environments.
• The NSA and CISA Network Infrastructure Security Guide (current version 1.2, February 2023) is the best free, current, authoritative reference for practical firewall and router hardening. It calls for default-deny ACLs with all denied traffic logged.

Tools we use

Nothing magical. Mostly show running-config exports with diffs over time, and a spreadsheet. For larger estates, Nipper handles Cisco and Palo Alto auto-assessment reasonably well. FireMon is better but costs real money and is overkill for anyone with under 300 rules. For SMB networks on pfSense or OPNsense, the built-in reports do most of the work.

The expensive tools shine on estates with thousands of rules across multiple devices. For most South African mid-market clients a trained pair of eyes on a ruleset export finds more than the tool would.

What bad looks like

One finding we keep seeing, sanitised:

access-list OUTSIDE_IN line 12 extended permit tcp any 10.0.0.0 255.0.0.0 eq 22
access-list OUTSIDE_IN line 13 extended permit tcp any 10.0.0.0 255.0.0.0 eq 3389
! temp - Johan - 2020-04-15

Johan has left the company. The rules are still in place.

Functionally this means the entire internal network is reachable from anywhere on the internet on SSH and RDP. The only thing standing between an attacker and the network is hope that nobody portscans the public IP. Which they do. Constantly.

This specific rule has been in three separate audits over the last five years. It exists today. It was a temporary exception for a remote troubleshooting session that never got torn down.

A proper review catches this. The review also creates the paperwork that makes removing it less scary. Because now the rule is a documented critical finding, not just an ageing line in a config. Removing it becomes the answer, not the risk.

If you want this done properly

$ ironsky audit --firewall ruleset.cfg