Firewall Rule Reviews Alongside External Testing
A penetration test tells you what is reachable from outside. A firewall rule review tells you why, and which of the rules permitting it still has a reason to exist. The two together are considerably more useful than either alone, which is why standards ask for both: PCI DSS requires configurations to be reviewed at least every six months, and the rule sets we see rarely survive that scrutiny intact.
How rule sets grow
One request at a time. A supplier needs access for a migration and a rule is added with a wide source range because the addresses were not known yet. A developer needs a port opened for testing and the rule stays. An application is decommissioned and its rules remain because nobody told the network team. Over several years the policy becomes a historical record rather than a design, and its size makes it harder to review, which slows the reviews further. Most estates reach a point where nobody can say what a given rule is for, and the person who would have known left two reorganisations ago.
See also: Advancing Careers Through Lifelong Learning
What a review actually looks for
Start with rules permitting any source or any destination, because those are the ones with the largest consequences. Then look for shadowed rules that can never match because an earlier rule catches the traffic, unused rules with no hit count over months, and object groups that have grown to include addresses nobody recognises. Each rule should have a business justification, an owner and a review date recorded somewhere, and the absence of that record is itself a finding worth reporting to whoever signs off the change process.
“Hit counters are the most useful thing in a rule review and almost nobody looks at them. A rule with no matches in six months is either obsolete or protecting something that no longer exists. Disable rather than delete, wait a month, then remove. That single habit will shrink most rule sets by a third without any risk.”
William Fieldhouse, Director, Aardwolf Security Ltd
Where testing and review disagree
The interesting findings appear in the gap between the two. A rule review says a service is restricted to a supplier’s addresses, and testing shows it answering from anywhere because a load balancer sits in front of the firewall. Or the review shows a tidy policy while testing finds a service exposed through a cloud connection that bypasses the perimeter entirely. Run external firewall and perimeter testing against the same scope you reviewed, then compare the results, because each corrects the blind spot in the other.
Internal rules deserve the same attention
Segmentation is enforced by rules that are reviewed far less often than perimeter ones. A policy intended to separate the office network from the server network frequently contains an any-any rule added during a migration, which quietly removes the separation everything else depends on. Internal segmentation testing checks what actually passes between zones rather than what the policy claims, and it is the practical way to confirm that a design still exists in the configuration.
Frequently asked questions about firewall reviews
These questions come up when a network team is asked to evidence its controls.
How often should rules be reviewed?
Every six months is the common standard and it works well in practice. Estates with high change rates benefit from a lighter monthly check on new rules, with the full review kept to the longer cycle.
Can this be automated?
Analysis can be, and judgement cannot. Tools identify shadowed, unused and overly broad rules quickly. Deciding whether a rule still has a business reason requires somebody who can find the owner and ask.
