The first 5 firewall rules we audit

When we take over a firewall, we can usually predict the findings before the export finishes. Rule-bases accumulate like desk drawers: everything that was ever temporarily necessary is still in there, and nobody remembers which rules hold the business together. These are the first five things we look for.

1. The any-any that "made it work"

Somewhere near the top, there is often a rule created during a crisis — source any, destination any, service any — that made an application work at 11 p.m. and was never revisited. It quietly bypasses everything below it. We find it, work out what it was really for, and replace it with the narrow rule that should have existed.

2. Remote access for people who left

VPN accounts and firewall users are rarely offboarded with the payroll. An ex-employee with a working VPN profile is a breach with a start date you don't know yet. Access lists get reconciled against the current staff list — every audit, no exceptions.

3. Management interfaces on the internet

The firewall's own admin page, exposed on the WAN "so the vendor can support it". Management access belongs behind the VPN, restricted by source, with MFA. This finding alone justifies most audits.

4. Expired security subscriptions

A firewall whose IPS and web-filtering licences lapsed eight months ago is a router with self-esteem. The hardware keeps passing traffic, so nobody notices protection stopped. Renewal dates belong in a tracked system, not in the reseller's memory — it is precisely the kind of thing our managed services exist to never forget.

5. Rules with no names, owners or hits

Zero-hit rules that nothing has matched in a year, rules named "test", rules nobody can explain. Each is either dead weight or a story worth knowing. A healthy rule-base reads like documentation: every rule named, justified, and reviewed on a schedule.

If any of these five sound familiar, a security assessment takes days, not months, and produces a ranked fix list your team can execute.