Firewall Policy Audit in India — the Rules Nobody Dares Delete

The rule base nobody wants to touch

Every firewall I open for the first time tells the same story — not of the network as it exists today, but of the last ten or fifteen years: every project, every emergency, every vendor who once needed access, layered one on top of another like sediment. Rule number 12 dates from an era when the office had one leased line. Rule number 847 was added at 2 a.m. during an outage and never removed. Nobody remembers who wrote either of them, and nobody dares delete them.

This is the state of most firewall estates I see during a firewall policy audit in India. The hardware is current, the licences are paid, the dashboards are green — and the policy itself is an archaeological dig. The firewall still works, in the sense that traffic passes. What it no longer does is express any conscious decision about what should be allowed. That gap between what the box enforces and what the business intends is where risk lives quietly for years.

A firewall policy audit is the work of closing that gap. Not a firmware check, not a licence review — a line-by-line examination of the rule base, objects, inspection profiles and logging, measured against what the organisation needs and its auditors ask for.

What years of accumulated rules do to a network

Rules are easy to add and frightening to remove, so they accumulate. The patterns repeat across almost every estate I review.

Shadowed and duplicate rules

A broad rule placed high in the list silently swallows everything below it. Dozens of carefully written rules further down never match a single packet — they exist only as false comfort. The same permission is often defined three ways by three different administrators, and nobody is sure which is live.

Any-any rules from old emergencies

Something broke at midnight, someone added a temporary any-any permit to restore service, and the temporary rule is now four years old. It routes around every control beneath it. In most audits I find at least one, and its existence is always news to the current team.

Rules for vendors who left

The support contract ended, the vendor’s engineer moved on, but the inbound rule for their monitoring server is still open — sometimes to an IP range the vendor no longer owns. Orphaned access is one of the most common and most avoidable exposures I find.

Policies nobody can explain

The people who wrote the rules have changed jobs. The change tickets, if they existed, are gone. When your own engineer cannot tell an auditor why a rule exists, the honest answer is that the rule has no owner — and a control without an owner is not a control.

What a proper firewall rule base audit covers

A real audit goes well past exporting the config and highlighting duplicates. This is what I examine.

Rule-base rationalisation

Every rule, read and challenged: what it permits, who requested it, whether the business reason still exists, whether it is shadowed, redundant or too broad. The goal: every rule has an owner and a justification; anything with neither is removed or tightened in a controlled way.

Object cleanup

Address objects, groups and service definitions multiply faster than rules do. I find duplicate objects with near-identical names, nested groups nobody can unwind, and objects pointing at decommissioned hosts. Cleaning them up is unglamorous, but it makes the rule base readable again — and a rule base you cannot read is one you cannot defend.

Inspection-profile review

A firewall that passes traffic without inspecting it is an expensive router. I check which security profiles — IPS, application control, web filtering, SSL inspection — are actually attached to which policies, and whether they are tuned or left at defaults. Permits that bypass inspection entirely get particular attention, because that is usually where the any-any rule is hiding.

Logging completeness

I verify that the rules which matter actually log, that logs reach a collector that keeps them, and that retention matches what regulators and auditors expect. A perfect rule base with no logs still fails an audit — and leaves you blind during an incident.

How I audit without downtime

The fear behind most deferred audits is that touching the firewall will break the business. Done properly, almost none of it touches the live box.

The analysis happens off-box first, on the exported configuration: shadow and duplicate detection, object mapping, rule-hit analysis against traffic counters, policy-to-intent comparison. This phase produces findings and a proposed change list without a single packet being affected.

Enforcement changes happen only in agreed change windows, one batch at a time, starting with changes that carry no traffic risk — dead rules with zero hit counts, duplicate objects, logging gaps. Riskier tightening, such as replacing an any-any permit with scoped rules, is staged with monitoring on the affected flows.

Every change ships with a rollback plan: the exact prior configuration, the command sequence to restore it, and a named person authorised to trigger it. In thirty years I have learned that teams approve clean-up work readily when they know reversal is one step away.

The compliance angle

In India, a firewall configuration review is no longer optional hygiene. CERT-In’s 2022 directions require logs to be retained for 180 days within Indian jurisdiction and mandate incident reporting within six hours — obligations you cannot meet if your firewall is not logging the right sessions, or if the logs never leave the box. A messy rule base is where logging gaps hide.

For ISO 27001, the rule base maps directly to access-control and network-security controls, and certification auditors increasingly ask for evidence of periodic review: who reviewed the policy, when, what changed, and who approved it. “The firewall team looks at it sometimes” is not evidence. An audited rule base with named owners and a review trail is.

RBI and SEBI-regulated entities get the same questions from examiners. I have watched an auditor pick a rule at random and ask the room to justify it. The room that can answer has done an audit. The room that goes quiet has not.

What you receive as deliverables

An audit that ends in a verbal summary is worth little at your next certification. My deliverables are built to be handed over:

• An audited policy base — every rule annotated with its owner, its business justification, and the decision taken: keep, tighten, merge or remove.
• A deduplicated object inventory, with naming standards your team can maintain.
• Inspection-profile baselines showing which security profiles attach to which policies, and the gaps closed.
• A logging and retention matrix mapped against CERT-In directions and auditor expectations.
• An evidence pack — findings, change records, approvals and rollback logs — structured so an external auditor can trace every decision.

How I work

The shape is the same whether the estate is one firewall or two hundred. Assess: off-box analysis of the full configuration and traffic data, with findings ranked by risk. Architect: the target rule base designed with your team — what stays, what tightens, what goes, and why. Deploy: changes executed in windows, with monitoring and rollback for every batch. Operate: a review cadence and ownership model so the rule base never rots back into sediment.

My deepest experience is on FortiGate, but I audit Cisco, Check Point and Palo Alto estates too — the discipline is vendor-neutral, only the syntax changes.

If you want the audit run for you, or ongoing management after it, my team at PJ Networks does exactly that — see their firewall audit services in India and their managed firewall services for estates that need continuous rule hygiene, not a once-a-year clean-up.

Frequently asked questions

How often should firewall policies be audited?

Annually at minimum, and after any major change: a merger, a new data centre, a cloud migration, a change of network team. High-change environments — e-commerce, multi-branch retail — benefit from a light quarterly review between full audits. The real test is simpler: if nobody can explain why a rule exists, you are overdue.

Can you audit without taking the firewall offline?

Yes. The analysis runs entirely off-box from exported configurations and traffic counters, so production is untouched. Only the remediation changes touch the live firewall, and those happen in agreed maintenance windows with a tested rollback plan for every change. Most audits complete with zero unplanned downtime.

What does a firewall audit cost in India?

It depends on estate size: number of firewalls, size of the rule base, and whether remediation is included or only the report. A single-firewall audit with a few hundred rules is short; a multi-site estate with thousands of rules across vendors takes proportionally longer. I scope after seeing the exported configuration, so the quote reflects the real work, not a guess.

How long does an audit take?

A typical single-site rule base takes one to two weeks for the full analysis and report. Multi-vendor or multi-site estates run three to six weeks depending on size and how much remediation is bundled in. The timeline stretches mainly when rule owners are hard to identify — the technical analysis is usually the fast part.

Do you fix what you find, or just report?

Both, if you want both. The audit report stands alone — findings, risk ranking, proposed rule changes and the evidence pack. Remediation is a separate, optional phase: I execute the approved changes in maintenance windows with rollback plans, or hand the change list to your team. Some clients only want the report; most ask me to at least remove the dead weight.

What do we get as evidence for auditors?

An evidence pack containing the audited rule base with an owner and justification per rule, the deduplicated object inventory, inspection-profile baselines, a logging and retention matrix mapped to CERT-In and ISO 27001 expectations, and the full change and approval trail. It is structured so an external auditor can trace any rule to its justification without interviewing your team.

Start with a working session

If your firewall policy has been growing untouched for years, the fastest way to know where you stand is an honest look at the exported configuration. No appliance gets rebooted, nothing on the network changes — you just find out what your rule base actually says.

Book a working session and bring the config export. I will tell you plainly what I would keep, what I would delete, and what an auditor will ask about first. You can also read how I work or start from the homepage.

Based in Delhi, working with enterprises across India.