Firewall rule review: finding the any-any rule from 2019

Firewall rule bases only ever grow. Rules get added under deadline pressure, the reason is never written down, the person who requested it leaves, and nobody dares remove anything. Ten years later the rule base is the accumulated sediment of every urgent request the organisation ever made.

What a review looks for

• Overly permissive rules - any source, any destination, any service. Usually added during an incident or a migration as a temporary measure.
• Unused rules with no hit count over a meaningful period.
• Shadowed rules that can never match because an earlier rule catches the traffic first - harmless but evidence of drift.
• Redundant rules duplicating one another.
• Expired temporary rules that were never removed.
• Rules with no owner or justification - the most common finding, and the reason nobody will remove anything.
• Overly broad object groups, where the rule looks tight but the group behind it contains half the network.

That last one is easy to miss. A rule referencing a well-named group can be as permissive as any-any if nobody has reviewed what the group contains - and groups accumulate members the same way rule bases accumulate rules.

Why it is an audit issue

Segmentation claims rest on the rule base. If you tell an assessor that your cardholder environment or your OT network is segmented, the rule base is the evidence - and a temporary any-any rule from three years ago quietly connecting two zones the diagram shows as separate contradicts the claim entirely.

PCI DSS requires periodic rule review explicitly. Most other frameworks require it implicitly through change control and network security requirements.

Removing rules without an outage

The reason rule bases never shrink is fear, and the fear is reasonable. A staged approach removes it:

1. Identify candidates from hit counts over a long enough window to include periodic processes - a quarter at minimum, longer where annual jobs exist.
2. Attempt to find the owner. Some will be identifiable from change records; many will not.
3. Disable rather than delete, and wait. Disabled rules can be re-enabled in seconds; deleted ones require reconstruction.
4. Log and alert on what would have matched where the platform supports it.
5. Delete after a defined quiet period, documenting what was removed.

Stopping the regrowth

Cleaning up once and changing nothing means repeating the exercise in two years. What prevents regrowth:

• Mandatory justification and owner on every new rule, enforced by the change process rather than requested politely.
• Expiry dates on temporary rules, with automatic review rather than reliance on memory.
• A named owner per rule group, reviewed when that person leaves.
• Review as a scheduled recurring control with evidence, not an occasional project.

Evidence to keep

The review date, who performed it, the rule base version examined, findings, actions taken and approvals for removals. Auditors ask for the review record, not the rule base - and a review with no recorded decisions is treated as not having happened.

Key takeaways

• Check object group contents, not just rule definitions.
• Segmentation claims are only as good as the rule base evidencing them.
• Disable and wait rather than delete - it removes the fear that blocks cleanup.
• Require justification and owner at creation or the base regrows.