Most firewall estates aren't breached because of a missing feature. They're breached through a rule nobody remembers writing. Here's how to keep a rulebase clean, auditable, and defensible.
Every firewall estate we're brought in to audit has a working rulebase. It also, without exception, has rules nobody can explain. A "temporary" allow from a project that shipped three years ago. A rule with a source of any because a ticket needed closing on a Friday. A duplicate of a duplicate, both shadowed by a broader rule above them, both still evaluated on every packet. None of this shows up as an outage. It shows up later, as the path an incident took.
A rulebase doesn't degrade because engineers are careless. It degrades because it's easy to add a rule under pressure and hard to justify removing one later. Adding a rule fixes today's problem in minutes. Removing one means proving a negative — that nothing depends on it — which takes longer than most change windows allow. So estates accumulate rules the way a hard drive accumulates files: additions are cheap, deletions get deferred indefinitely, and eventually nobody has full context on what's actually needed.
Shadowed and duplicate rules. A specific rule sitting below a broader one that already matches the same traffic. It looks intentional. It's dead weight — and it hides the fact that the broader rule above it is doing more than anyone realises.
"Any/any" survivors. Broad source/destination/service rules added to unblock something quickly, then never narrowed once the real requirement was understood. These are usually the widest blast radius in the entire policy.
Rules with no owner. No ticket reference, no review date, no name tied to a person or project. If nobody's listed as the owner, nobody's going to volunteer to remove it — so it stays forever.
Logging switched off, or logged and never reviewed. Either the rule doesn't log, so an audit or an incident response has nothing to work with, or it logs into a pipeline nobody actually looks at, which is functionally the same problem with a bigger bill.
Object and group sprawl. Address and service objects created per-project instead of reused, until the object list is three times larger than the estate it describes. This is what makes rule reviews slow enough that they stop happening.
This is close to the checklist we run against Fortinet, Palo Alto, and Check Point estates during a health check. None of it requires new tooling — it requires a cadence.
any in source, destination, or service with the narrowest object that satisfies the actual requirement, and log the reason it couldn't be narrowed further if it genuinely can't.Quarterly, at minimum, for anything customer-facing or handling regulated data. Annually is not a cadence — it's long enough for a rulebase to fully regrow everything you cut. The estates we see with the fewest surprises treat rule review the same way they treat patching: scheduled, owned, and reported on, not triggered only by an audit finding or a near-miss.
A clean rulebase isn't a compliance artefact. It's the difference between an incident response that takes an hour because the policy is legible, and one that takes a week because nobody can say with confidence what a given rule actually does.
Our network health checks include a full firewall policy review — shadowed rules, stale objects, and a prioritised remediation plan.