Rule bases only ever grow. Adding a rule solves today. Removing one risks breaking something nobody remembers.
A firewall rule audit answers four questions about every rule: what does it permit, who asked for it, is it still used, and would anybody notice if it were removed. Most organisations can answer the first for all of them and the other three for almost none.
- Four questionsPer rule, and three are usually unanswered
- Shadowed rulesRules that can never match anything
- Any to anyThe finding that appears in almost every audit
- CIS Control 12Network infrastructure management
Seven findings that appear in almost every rule base we review.
Permissive rules that were meant to be temporary
An any to any rule, or a rule permitting a whole subnet to a whole subnet on all ports, added during a migration or an outage with every intention of tightening it afterwards. They are the single most common serious finding, they are usually near the top of the rule base where they shadow everything below, and nobody remembers adding them.
Shadowed rules that can never match
A rule that sits below a broader rule matching the same traffic will never be evaluated. It is not a security problem in itself, and it is strong evidence that the rule base has been edited by several people over several years without anybody looking at the whole. Shadowed rules also make every subsequent change harder to reason about.
Rules with no traffic against them
Usage data over a representative period tells you which rules are doing work and which are not. A rule with no hits over ninety days is a candidate for removal, subject to the obvious question of whether the period covered its use case. Seasonal, year-end and disaster recovery paths are the exceptions that make this a judgement rather than a script.
Rules with no owner and no justification
The question that closes most rules is not is it used, it is who asked for it and why. A rule with a change reference, a requester and a business reason can be reviewed. A rule with a comment field reading temp or a ticket number from a system that was replaced cannot, and it will survive every future review for exactly that reason.
Objects and groups that have drifted from their names
An address group called finance servers that now contains eleven objects, three of which are not finance servers and one of which is a whole subnet. Group drift is how a narrow rule silently becomes a broad one without the rule itself ever changing, and it is invisible unless somebody expands every object.
Configuration outside the rule base itself
Management access from anywhere, administrative accounts that are shared, logging disabled on rules that matter, firmware several versions behind, and high availability that has never been failed over. Secure configuration is control 4 in the CIS Controls, and a perfect rule base on a device anybody can log into is not a control.
Divergence between what the diagram says and what the device does
Almost every organisation has a network diagram that describes an intended architecture and a rule base that describes an accumulated one. The gap between them is where unexpected paths live, and reconciling the two is frequently the most useful output of the audit for anybody who has to design a change afterwards.
Adding a rule has a clear benefit today. Removing one has an unclear risk tomorrow.
The asymmetry is structural, and it explains why rule bases grow monotonically in every organisation regardless of the quality of the team.
- Adding a rule unblocks a project, resolves an incident or enables a supplier. The benefit is immediate, attributable and appreciated. It is the right thing to do at the time and it is almost never wrong.
- Removing a rule has no visible benefit and a non-zero chance of breaking something nobody has documented. Nobody thanks the engineer who removed a rule successfully, and everybody remembers the one who removed the wrong one. The incentive runs one way.
- The only thing that reverses the asymmetry is evidence. Usage data showing a rule has matched nothing over a representative period, plus a documented owner who confirms it is no longer needed, converts removal from a gamble into a decision. That evidence is what an audit produces.
- This is also why a rule audit needs to end with a maintained process rather than a one-off cleanup. Without a review cycle and a requirement that new rules carry an owner and an expiry where appropriate, the rule base returns to its previous size within a few years.
Four things that turn a rule audit into a cleaner rule base.
We use usage data, because opinion cannot remove a rule
Hit counts over a representative period turn removal from a gamble into a decision. Without them, every proposed removal is somebody asserting that a rule looks unnecessary, and that assertion never survives contact with the person responsible for whatever might break. The evidence is what makes the conversation short.
We trace ownership before recommending removal
A rule with a named owner can be confirmed or retired in one email. A rule with no owner requires either archaeology or a controlled disable and observe. Doing the tracing during the audit, rather than handing over a list of unattributed rules, is most of the difference between a report and a result.
We disable before we delete
The safe sequence for a rule with no recorded traffic and no identifiable owner is to disable it, observe for an agreed period, then remove it. That converts the worst case from an outage to a quick re-enable, and it makes the whole exercise something an operations team will agree to rather than resist.
We leave behind a process, not just a cleaner base
New rules requiring a named owner and a business justification, temporary rules carrying an expiry date, and an annual review with usage data. Without those three the rule base returns to its previous size within a few years, and the next audit produces the same report to a different audience.
Six UAE situations where a rule audit pays for itself quickly.
An organisation migrating to a new firewall platform
Migrating a rule base is the single best opportunity to shrink it, because everything has to be examined anyway. Migrating it unchanged carries a decade of accumulated permissions onto a new platform and wastes the only occasion when removal is expected rather than resisted.
A regulated firm with a periodic review obligation
Several frameworks and payment obligations expect firewall rules to be reviewed at a defined frequency. Where such an obligation applies, the audit produces both the review and the evidence that it happened, with a documented decision against each rule rather than a signature confirming somebody looked.
A business in scope for payment card requirements
PCI DSS version 4.0.1 is the current version in the standards council document library, and network controls have always been central to it. Where card data is in scope, the segmentation the rule base implements is the control that determines how much of the estate is in scope, which makes rule accuracy commercially significant.
An operator with converged operational and corporate networks
Where production systems sit behind rules written over many years, the gap between the intended segmentation and the actual one is both a safety and a security question. Reconciling the documented design with the live rule base is frequently the most valuable single output for this profile.
A group that has grown by acquisition
Each acquisition brings a rule base written by a different team to different conventions, and integration typically adds permissive rules to make things work quickly. Auditing across the group produces a consistent picture and identifies the temporary integration paths that are now several years old.
An organisation that has just found an unexpected path
The usual prompt. Somebody discovers that one system can reach another that it should not, and the immediate question is what else is like that. A full rule audit is the only way to answer it, and the answer is almost always that there are several more, of which one or two matter.
How UAE organisations manage their firewall rule bases.
| Feature | Audited and maintained | Changes controlled, nothing removed | Unmanaged rule base |
|---|---|---|---|
New rules require justification | Yes | Yes | No |
Rules have an identified owner | Yes | For recent ones | No |
Unused rules identified | Yes | No | No |
Shadowed rules removed | Yes | No | No |
Object groups match their names | Yes | Drifted | Unknown |
Any to any rules known and scoped | Yes | Present, unnoticed | Present |
Management access restricted | Yes | Usually | No |
Documented design matches reality | Yes | No | No design |
Temporary rules expire | Yes | No | No |
Rule count trend | Stable | Rising | Rising |
Nine categories, and what we do with each.
| Finding | Why it matters | Default recommendation | |
|---|---|---|---|
| Any to any, or any service permitted | Permits far more than intended, and usually shadows rules below it | Scope to the actual requirement, urgently | |
| Overly broad source or destination | A subnet where a host was needed | Narrow to the specific systems, with the owner confirming | |
| Shadowed rule | Can never match, and makes the base harder to reason about | Remove, after confirming the shadowing rule is correct | |
| No traffic over the review period | Likely obsolete, subject to seasonal exceptions | Disable, observe, then remove | |
| No owner or justification | Cannot be reviewed, so survives indefinitely | Trace the owner, or treat as a candidate for removal | |
| Object or group drift | A narrow rule that has silently become broad | Rebuild the group to match its name and purpose | |
| Logging disabled | No record of what the rule permitted | Enable, unless there is a documented volume reason | |
| Management access too broad | Secure configuration failure, independent of the rules | Restrict to a management network, with named accounts | |
| Divergence from the documented design | Unexpected paths that nobody designing a change would predict | Reconcile, and correct whichever is wrong |
Five steps, and disabling before deleting is not negotiable.
- 1
Collect configuration and usage data
Configuration exports from every in-scope device including branch and cloud firewalls, plus rule usage data over a representative period, ninety days as a reasonable minimum. Read-only access is normally sufficient, and a central management platform makes the collection considerably faster.
- 2
Analyse the rule base against the finding categories
Permissive rules, shadowed rules, rules with no traffic, rules with no owner or justification, object and group drift, logging gaps, and management access. Each finding is categorised so the output is a decision list rather than an undifferentiated report of everything that could be improved.
- 3
Trace ownership and reconcile with the design
Change records, ticket references and the people most likely to know, so that as many rules as possible arrive at the review with an owner attached. In parallel, the live rule base is compared with the documented network design, because the gap between them is where the surprising paths live.
- 4
Agree the actions, then disable before deleting
Urgent scoping for permissive rules, removal for shadowed ones, and disable and observe for rules with no traffic and no owner. The disable and observe step converts the worst case from an outage into a quick re-enable, which is what makes an operations team willing to proceed at pace.
- 5
Leave a process that keeps the base clean
A requirement that new rules carry a named owner and a business justification, an expiry date on anything described as temporary, and an annual review using usage data. Without those, the base returns to its previous size and the next audit produces the same findings.
What organisations ask about firewall rule audits.
Fifteen things that make the audit faster and better.
Access
- Can we get a configuration export?Read-only access is usually sufficient.
- Is rule usage data available?Hit counts over a representative period.
- How long is the usage window?Ninety days is a reasonable minimum.
- Are all devices in scope?Including branch and cloud firewalls.
- Is there a central management platform?It makes the export far easier.
Context
- Is there a network diagram?Even an out of date one helps.
- Is there a change record for rules?That is where owners come from.
- Are there seasonal or annual paths?They must not be removed on usage alone.
- Any regulatory obligation in play?It may set a review frequency.
- Which segments matter most?Prioritise the ones protecting real value.
Afterwards
- Who approves a removal?Decide before the list arrives.
- Is there a change window?Removals happen in batches.
- Do new rules require an owner?The single most effective change.
- Do temporary rules carry an expiry?Otherwise they are permanent.
- When is the next review?Annually, or the base regrows.
The pages around this one.
Count the rules in your main firewall. Then ask how many were removed last year.
If the second number is zero, the rule base is recording your history rather than your intent. That is normal, it is fixable, and the first audit consistently finds one permissive rule that changes the conversation.
Related Services
Explore more solutions that work great with this service
Network Monitoring NOC
24/7 NOC monitoring with named engineers
Penetration Testing
Black, grey, and white-box penetration testing
CIS Controls Assessment
Eighteen controls, assessed and re-assessed
Fortinet FortiGate Dubai
Sizing, deployment and managed firewall lifecycle
Sophos Firewall Dubai
Authorised Sophos XGS partner UAE
Azure Firewall
SKU choice, TLS inspection and rule base design
IT Audit Services Dubai
Assessment, technical test or certification, scoped properly
Vulnerability Assessment
Continuous vulnerability scanning and remediation