Network Configuration & Firewall Rules Review
A firewall that parses cleanly can still leave the door open. We read your rulebase and network design the way an attacker would — judging every rule not by whether it works, but by what it actually exposes.
Veteran researchers. CERT-In empaneled. We find the permissions you forgot you granted.
Your rulebase is a record of every decision you forgot you made
A firewall rulebase is rarely designed once and left alone.
It accretes. Every project, migration, incident and "just open it temporarily" leaves a rule behind, and over time the policy that was meant to enforce least privilege becomes an archaeology of intentions no one fully remembers. The device is healthy, the rules parse, traffic flows — and yet the configuration may quietly permit far more than the business ever needed.
A network architecture and firewall configuration review reads that reality directly. Rather than only probing the perimeter from the outside, we examine the actual rulebase, object database, segmentation and management configuration — comparing what the network allows against what it should allow, and surfacing the gap. We do it with an attacker's eye: the overly-permissive rule, the forgotten any-any exception, the flat zone where there should be a boundary, and the management interface reachable from places it never should be are not housekeeping issues. They are the paths an intruder uses once they are inside.
"We don't ask whether the firewall is running. We ask what it lets through — and to whom."
What a rulebase quietly hides
Most rulebases carry the same recurring defects. We hunt for the ones that widen your attack surface without anyone noticing.
Overly-permissive rules
"any" sources, "any" destinations, wide service ranges and wildcards that grant far more access than the business actually requires.
Shadowed & redundant rules
Rules that can never match because an earlier rule already does, and duplicates that clutter the base and mask the real policy.
Stale & expired rules
Access opened for a project, vendor or incident that ended long ago, and objects pointing at hosts that no longer exist.
Broken or absent segmentation
Flat zones, weak DMZ boundaries and trust relationships that let an attacker move sideways once a single host falls.
Exposed management plane
Administrative interfaces, default credentials, weak protocols and management access reachable from far wider than it should be.
Missing or insufficient logging
Rules and devices that don't record what they permit or deny, leaving incidents invisible and audits unprovable.
Unmanaged change
Rules with no owner, no business justification and no record of who added them or why — the hallmark of a rulebase no longer under control.
A structured review, an adversarial reading
Our methodology is repeatable and defensible — aligned with recognized firewall and network-security guidance (NIST SP 800-41, the CIS Benchmarks for the relevant platform, and the segmentation expectations of standards such as PCI-DSS) — while the analysis itself stays adversarial: every rule is read for what an attacker could do with it. Each engagement moves through a clear sequence, from defining scope to auditing the processes that govern the rulebase.
Reading the rulebase, not just rattling the door
A configuration review and a network penetration test answer different questions. We are explicit about which this is — and why the two are strongest together.
Tests the perimeter from outside
A network penetration test probes your defences blind, as an external attacker would — useful for confirming real-world exposure. But it sees only what it can reach from the outside. A perimeter that holds against today's probe can still rest on a rulebase that is permissive, untidy and one forgotten exception away from a problem.
Reads the actual rulebase from within
We work from the real configuration and rulebase — a white-box reading of exactly what the network permits. That lets us find the shadowed rule, the stale any-any exception, the flat zone and the exposed management interface that no external probe would ever reveal, and to judge the design against least-privilege and benchmark expectations. Most mature programs run both: the pentest validates the edge, the review proves the design behind it.
Every rule, read three ways
A rule can be syntactically perfect and still be wrong. We judge each one on three axes at once.
The configuration and rule syntax itself — correctness, hardening, ordering, and the device-level settings that determine how each rule is actually enforced.
What the rule permits versus what the business genuinely needs. We document, in plain language, the activity each rule allows and disallows, and surface the gap between intended and actual access.
How devices are administered and governed: the authorization process for changes, who owns each rule, the justification behind it, and whether the rulebase is under disciplined control or drifting unmanaged.
What we review
Across an engagement we systematically examine the configuration controls that determine how much a network truly exposes — benchmarked against CIS guidance for the platform in scope and NIST firewall guidance:
Segmentation is the control that decides how far an attacker gets
A breach is rarely the end of the story — it is the beginning of lateral movement.
Segmentation is what decides whether a single compromised host stays contained or becomes a foothold into everything. We review your zoning the way an attacker would test it: looking for the boundary that exists on the diagram but not in the rulebase.
How an engagement works
A clear path from kickoff to recertification — designed to leave your team with a rulebase they understand and control.
What you receive
Every engagement ends in a report your team can act on — written for both the engineers who will tighten the configuration and the leaders who must understand the exposure.
Executive summary
Network exposure and business risk in plain language for leadership.
Rule-by-rule findings
Each issue with severity, the affected rule or setting, what it currently exposes, and clear evidence.
Prioritized remediation guidance
Specific, ordered fixes — which rules to tighten, remove or re-justify first — not generic advice.
Segmentation & architecture assessment
How well the design contains an attacker, and where to strengthen it.
Standards & benchmark mapping
Findings mapped to CIS Benchmark and NIST firewall guidance, with the segmentation context relevant to PCI-DSS and similar requirements.
Remediation retest
We re-verify the corrected configuration so you can confirm the exposure is genuinely closed.
Direct researcher access
A debrief with the people who did the review, not a handoff to a call centre.
Supports ISO 27001, SOC 2 and RBI/SEBI assessment requirements
Frequently asked questions
How is a configuration review different from a network penetration test?
A penetration test probes your defences from the outside, blind, as an attacker would — it confirms what is reachable. A configuration review reads the actual rulebase and network design from within, so it finds the permissive, shadowed, stale and poorly-segmented configuration an external probe would never see. The two answer different questions; mature programs run both.
Do you need to touch our production firewalls?
For most of the work, no. A configuration review can be performed on exported configurations and rulebases offline, with no impact on live devices. Where a hands-on look at the management plane or a verification step adds value, we coordinate read-only access with your team and agree the approach in advance.
We run multiple vendors — Cisco, Palo Alto, Fortinet, Check Point. Can you review a mixed estate?
Yes. Our methodology is vendor-neutral and our researchers work across the major platforms, applying each vendor's hardening guidance and the relevant CIS Benchmark while keeping a single, consistent view of your overall posture.
How often should a rulebase be reviewed?
A rulebase drifts continuously, so review should be regular — at minimum annually and after any significant change to the network, and more frequently where standards such as PCI-DSS require periodic validation of segmentation. Many teams pair an annual deep review with lighter ongoing hygiene.
Do you retest after we make the changes?
Yes. Remediation retesting is included, so you can confirm each tightened rule and corrected setting genuinely closes the exposure we identified.
Find out what your rulebase really allows.
Send us your scope — the devices, vendors and zones in question — and we'll shape a review that fits, or connect you directly with a researcher.