Firewall Ruleset Review: Manual vs Automated (and How to Get Audit-Ready)

Pull the running config off any firewall that has been in production for five years and count the rules. On a mid-sized bank edge I audited last year, the number was 1,247. When I asked the network lead which of those rules were still needed, he went quiet, then said the honest thing: nobody knew. Half of them predated him. Two of the change tickets referenced a project that had been decommissioned in 2019.

That is the real state of most firewall rulesets in India. Not a clean, documented, least-privilege policy. A sediment of every emergency change, every vendor pilot, every any-any rule someone added at 2am to make an application work and forgot to remove. The device still passes traffic. It just no longer means anything. And when an auditor asks you to justify a rule, silence is not an acceptable answer.

It is tempting to treat rule sprawl as housekeeping. It is not. Every stale permit rule is a path an attacker can use that you are no longer watching. When you cannot explain why a rule exists, you also cannot tell whether it is being abused. The rule that once allowed a retired jump host to reach the card database is now a quiet lateral-movement route that survives because nobody dares touch it.

There is a compliance cost too, and it is concrete. If you process card data, PCI DSS v4.0 requirement 1.2.7 makes you review network security control rulesets at least once every six months. Requirement 1.2.1 makes you keep configuration standards that define what is allowed and deny everything else by default. For CERT-In empanelled audits and the RBI supervisory expectations that flow from the RBI Cyber Security Framework, an unreviewed firewall is a standing finding. SEBI-regulated entities face the same expectation under the SEBI Cybersecurity and Cyber Resilience Framework. The regulator does not care that traffic flows. The regulator asks who approved this rule, when, and why it is still here.

There is also a performance and blast-radius angle. Shadowed rules, redundant rules, and overly broad rules make the policy slower to evaluate and much harder to change safely. Every future change becomes a gamble because you cannot predict what a bloated ruleset will do. That is how a small edit takes down a payment gateway on a Friday evening.

When you actually sit down to review a policy line by line, the same defects recur across every organisation. Name them, because you cannot fix what you cannot categorise.

A healthy review does not just find these. It produces a decision for each one: keep with justification, tighten to least privilege, or remove. A finding with no decision is just a longer to-do list.

Manual review means an engineer reading the ruleset, mapping each rule to a business need, checking hit counts, and deciding its fate. Done well, it is the gold standard for judgement. A human can tell that a permit to a third-party payment aggregator is legitimate business even though it looks broad, and that a tidy-looking rule to an internal subnet is actually the ghost of a dead project.

The problem is that humans do not scale to 1,200 rules across a dozen firewalls twice a year. What actually happens is this. The review gets scheduled for a quarter. Two weeks in, the engineer has read 300 rules, found real issues, run out of time, and signed off on the remaining 900 as reviewed because the review window is closing. The document says the ruleset was reviewed. The reality is that two thirds of it was rubber-stamped. When I test this in an audit, I pick ten rules at random from the untouched end of the file and ask for the justification. The gap shows up in minutes.

Automated tooling — firewall policy analysers such as those built into vendor management consoles, or dedicated tools like Tufin, AlgoSec, FireMon, or open-source options like Nipper and pfSense config parsers — reads the entire ruleset in seconds. It reliably flags shadowing, redundancy, any-any rules, unused rules by hit count, and objects that no longer resolve. It does not get tired at rule 900. It produces a consistent, repeatable report you can diff between reviews.

What it cannot do is know your business. A tool will flag a broad permit to a regulatory reporting gateway as overly permissive. It cannot tell you that the rule is mandated, approved, and correct. It will happily recommend removing a rule that a quarterly RBI return depends on. Automation finds the candidates. It does not make the call. Anyone who lets a tool auto-remediate a production firewall policy without a human decision layer is one config push away from an outage and a very awkward incident review.

The answer is not manual versus automated. It is automated for detection and coverage, manual for judgement and sign-off. The tool builds the shortlist. The engineer, with a change record and a business owner in the room, decides.

Here is the sequence I look for when I audit a mature firewall management practice. If your process skips a step, that is usually where the finding lives.

Export the running configuration with a timestamp and a hash. Every conclusion you draw is only valid against a fixed baseline. Auditors want to see that the reviewed config and the live config are the same object.

Let the tool find shadowed, redundant, unused, and overly broad rules. Pull hit counts over a meaningful window — at least 90 days — so a rule that only fires at quarter-end is not mistaken for dead.

This is the manual heart of it. Each surviving rule needs a business owner, a documented reason, and a linked change ticket. Rules with no owner and no justification go on the remediation list, not the keep list.

For each flagged rule: keep with recorded justification, tighten the scope, or remove. Record who decided and when. A decision without a name attached is not evidence.

Removals and tightening go through your normal change process, with rollback ready. You do not clean up a firewall by editing the live policy on a hunch. You stage it, you test it, you have a back-out plan.

After changes, re-export, re-run the analyser, and confirm the ruleset now matches the approved state. That closing snapshot becomes the baseline for the next cycle.

A firewall review is only worth anything if it produces evidence an auditor accepts. Most reviews fail here — the work was done, but there is no artefact that proves it. When I sit in the audit room, this is the evidence set I ask for, and the exact questions I ask against it.

Notice what is not on that list: a screenshot of the firewall GUI. A screenshot proves a moment, not a process. Auditors have learned to distrust them. What holds up is a chain — snapshot, analysis, decision, change record, sign-off — that a stranger can follow six months later and reach the same conclusion you did.

A fintech client, RBI-regulated, PCI DSS in scope for the cardholder data environment. Their firewall had 640 rules. The team had run a tool, produced a clean-looking PDF, and told me the review was done. I asked for the justification register. There wasn't one — the PDF listed findings but no decisions.

So we opened the config together. Rule 118 was a permit from a /16 corporate subnet straight into the cardholder data environment on a database port. The tool had flagged it as overly permissive. The team had waved it through because it was old and things depended on it. When we traced it, the rule had been opened for a data migration in 2021 and never closed. The migration host was long gone. That single rule put the entire corporate network one compromised laptop away from the card database — a direct PCI DSS requirement 1.3 violation, network segmentation of the cardholder data environment, sitting undiscovered for over two years.

We tightened it to the two application hosts that genuinely needed it, raised a change ticket, and logged the decision with the CISO as owner. The whole fix took forty minutes. The point is not that the tool missed it. The tool caught it. The process around the tool had no step that forced a decision, so the finding died in a PDF nobody read.

People underestimate the effort because they think of it as one review. It is a repeating cycle, and the first one is always the heaviest because you are paying down years of debt.

Under the Digital Personal Data Protection Act 2023, a breach that traces back to a firewall rule you could not justify is not just a security failure — it is a demonstrable lapse in reasonable security safeguards, which is exactly what the Data Protection Board will weigh when it sets a penalty. The economics are not subtle. The recurring review is a rounding error against a single avoidable incident.

If you do nothing else this quarter, work through this. It is the shortlist I would hand your network lead.

Come back to that bank edge with 1,247 rules and a network lead who went quiet. The device was not broken. It had simply outlived anyone's understanding of it. A firewall you cannot explain is not protecting you — it is a liability wearing a security badge. The goal of a review is not a tidier config. It is being able to point at any rule and answer, without hesitation, who approved this and why it is still here.

If your last firewall review was a rubber-stamped PDF and you would rather find the stale rules before an examiner or an attacker does, our team at CyberSigma are senior CERT-In empanelled auditors and PCI QSAs who do this line by line, hands-on — not from a template.