Your firewall rulebase is a risk register nobody reads
Every firewall rule is a decision someone made about risk. Most organizations can no longer say who made those decisions, why, or whether they still apply.
In Issue 001 we talked about risk ownership in general terms. This issue gets specific about one place where unowned risk piles up quietly: the firewall rulebase.
Rulebases rarely get worse through one bad decision. They drift. A vendor needs remote access for a project. An application breaks during a migration and someone opens a broad rule "temporarily" to restore service. A server is decommissioned but its rules are not. Staff and providers change, and the context behind each rule leaves with them. After a few years, the firewall is still enforcing hundreds of decisions that nobody currently in the building can explain.
That is not a criticism of whoever manages the firewall. Day-to-day operations reward keeping things working, and removing a rule nobody understands feels riskier than leaving it. The result is predictable: the rulebase only grows.
An overly permissive or forgotten rule does not show up as an outage. It shows up during an incident, when an attacker uses access that was never supposed to exist, or during an audit, insurance renewal, or customer questionnaire that asks you to prove your network access is reviewed. If you handle card data, PCI DSS v4.0 requirement 1.2.7 expects network security control configurations to be reviewed at least once every six months.
Five signs your rulebase has drifted
1. Broad "any" rules
Rules that allow any source, any destination, or any service, especially between internal zones or from the internet, are the first thing an attacker benefits from and the first thing an assessor flags. Some exist for a documented reason. Many were created to make a problem go away quickly and never revisited.
2. Rules with no recent hits
If a rule has not matched traffic in months, it may be supporting a system that no longer exists. Most enterprise firewalls track rule usage. On Palo Alto Networks firewalls, Policy Optimizer and rule hit counts make this visible; on Cisco platforms, hit counts and rule usage reporting serve the same purpose. Zero hits is not proof a rule is safe to remove, but it is a strong reason to ask.
3. Shadowed and duplicate rules
Firewalls evaluate rules top-down. A rule placed below a broader rule that already matches the same traffic will never be used. Shadowed rules make the policy harder to read and give a false impression of how tightly traffic is controlled.
4. "Temporary" rules that became permanent
Vendor access, migration rules, and troubleshooting exceptions are normal. Leaving them in place indefinitely is not. If a rule was meant to be temporary, it should have an expiration date and someone responsible for removing it.
5. Rules nobody can explain
If a rule has no description, no ticket or change reference, and no named business owner, then nobody is accountable for the access it grants. This is the same ownership gap from Issue 001, expressed as configuration.
A safe cleanup sequence
The fear of breaking production is legitimate. Cleanup should be phased, monitored, and reversible. A practical sequence:
- Export and baseline. Take a configuration backup and export the full rulebase with hit counts. This is your rollback point and your starting evidence.
- Assign owners. For every rule that allows meaningful access, identify a business or technical owner. Rules with no owner go on a review list, not straight to deletion.
- Watch long enough. Collect usage data across a full business cycle before acting. Ninety days catches most month-end and quarter-end jobs; annual processes may need a longer look or a direct conversation with the application owner.
- Replace before you remove. For broad rules, build narrower replacement rules above them based on the traffic actually observed, keep logging enabled, and confirm the broad rule stops matching before you touch it.
- Disable first, delete later. Disable unused and replaced rules during an approved change window and leave them in place for a defined period. Re-enabling a rule takes seconds; reconstructing a deleted one under pressure does not.
- Document and repeat. Record what changed, why, and who approved it. Then schedule the next review so the rulebase does not drift back.
Who does what
This works best as a joint effort. The client's leadership confirms which business services must keep working and approves the residual risk of anything left broad. The MSP brings knowledge of the environment, runs the change process, and owns day-to-day operation of the result. Where the rulebase is large, spans multiple firewalls, or involves a platform migration, a specialist engineer can do the analysis and replacement-rule design alongside the MSP rather than in place of it.
A useful first step needs no project at all: ask for a count of rules with zero hits in the last 90 days, and a count of rules with no description or owner. Those two numbers tell you quickly whether a deeper review is worth scheduling.
What a phased remediation looks like in practice.
VALO's founder led a remediation of more than 150 Palo Alto firewall rules in a prior engineering role, using controlled replacement rules, application-default service settings, and traffic monitoring. The write-up covers the approach and validation steps.
VALO Security Brief is published every other Wednesday by VALO Technologies. It shares practical network security engineering, risk, and compliance guidance for MSPs and the organizations they support.
Not sure what's in your rulebase?
VALO's firewall assessments review Cisco and Palo Alto rulebases for broad, unused, shadowed, and undocumented rules, and deliver a phased cleanup plan your MSP or internal team can act on.
Discuss a firewall assessment