Firewall and Perimeter Review

A scanner tells you which ports answer; a rule-base review tells you why they answer and what else the same rule permits. Those are different questions. An external scan sees the perimeter from one vantage point at one moment, so it cannot see a rule that is shadowed by an earlier entry and never evaluated, a rule with a zero hit count that nobody dares remove, or an any-any entry that happens to be masked today by a device further down the path. It also cannot see the rules that permit inbound access to internal zones from source ranges far wider than the business case behind them. We parse the exported configurations, trace those paths by hand, and run the external checks as well, because live exposure and documented intent often disagree. The report tells you which of the two is wrong. If you want the exposed services themselves exploited rather than mapped, that is our penetration testing work, not this review.

Three things: the configurations, the picture of the network they sit in, and the change history behind them. Concretely that means running configurations and rule-base exports from each firewall, VPN concentrator and edge router in scope; network diagrams with VLAN or zone definitions, so a rule permitting traffic into a zone can be judged against what lives there; recent firewall change records and approvals; and rule hit counts where the platform records them, because a hit count is the difference between a rule we suspect is unused and one we can show is unused. We also need the external IP ranges you agree we may probe. Collection is read-only, worked from exports rather than by logging into live devices. Your engineers are needed mainly at the scoping call and the evidence handover. If a diagram is out of date, say so then rather than fixing it first; the gap is itself a finding.

We work across the common enterprise firewall, VPN and edge platforms, and we name no product here as a recommendation. The practical test is not the badge on the device but whether we can obtain a readable configuration export and whether the platform has a published hardening guide or CIS benchmark to measure it against. Where both exist the review runs the same way: parse the rule base, compare device settings to the baseline, then hand-review what the baseline does not cover. Where a device is unusual, end-of-life or has no published baseline, we say so during scoping and agree what it will be measured against instead, rather than quietly grading it on a guide written for something else. Cloud-native firewalls and security groups sit better in our Cloud Security Configuration Assessment, and host firewalls in the Operating System Hardening Review, so scoping often splits an estate across those engagements.

Removing rules breaks things, which is why we sequence the cleanup rather than hand you a list. We do not touch your devices; your team applies changes through your own change process. What we provide is an order of work ranked from lowest to highest change risk, and the tightened rule wording for each change, so your engineer approves a specific edit rather than interpreting a recommendation. Low-risk items come first: shadowed rules that never evaluate, duplicates, and exposed management planes. Rules with no recorded hits come next, and those are best staged through a logging-only or deny-with-alert period on your side before deletion, because a quarterly job may be the only traffic that ever matched one. Broad any-any rules carrying real production traffic come last and usually need decomposing into narrower rules. Once your changes land we re-review the configuration and rescan the perimeter, and that re-check is part of the engagement.

Once a year for the full review, plus a shorter re-look whenever the perimeter changes shape. The argument for a yearly cycle is simply that rule bases grow and rarely shrink: twelve months of change requests, project exceptions and temporary openings that were never closed is enough to undo a cleanup. The events that should pull a review forward are structural rather than calendar-driven: a firewall replacement or migration, a new site or data centre joining the network, a merger that connects a second estate to yours, an internal service moved to the edge, or an audit that needs current evidence of perimeter control. Between reviews the cheapest discipline is your own: require a named business owner and an expiry date on each new rule, and revisit zero-hit rules quarterly. The re-check after remediation is already included here, so the first cycle is covered by this engagement.