A firewall rule set only grows. Rules are added for a project, a vendor, a migration or a test, and almost nobody comes back to remove them. The review is the one moment when every rule has to earn its place again. This post is a checklist for that moment: 12 questions for every inbound rule, a way to check the rule set from the outside before you open the console, and a one-line record that makes the next review easier than this one.
The reason to take it seriously is simple. An attacker never sees your rule set. They see what it allows. Every inbound rule is an exposure, and an exposure nobody can justify is the one nobody is patching.
Why rules outlive their reason
Most stale rules were right when they were written. A vendor needed SFTP for a quarter. A team opened a port to test something. A migration needed two systems to talk for a weekend. Then the quarter ended, the test finished, the migration completed, and the rule stayed, because removing it was nobody’s task and the person who knew why it existed moved on.
The standards know this pattern. PCI DSS asks for a documented business justification for each firewall and router configuration, and for the rule sets to be reviewed at least every six months. The UK’s Cyber Essentials scheme asks for every inbound firewall rule to be approved and documented by an authorised person, including the business need, and for unnecessary rules to be removed when they are no longer needed. NIST SP 800-53 puts the default the other way round: deny network traffic by default and allow it by exception. A review is where you find out how far the rule set has drifted from that default.
Start from the outside
Do not start in the firewall console. Start with a list of what is actually reachable from the internet: every public IP address and hostname, every open port, every service answering on it. An external scan gives you that list. This is the ground truth of your rule set, whatever the documentation says, because it is what the rules allow in practice.
Then open the rule set and compare the two lists. Every item lands in one of three places.
- Reachable, but no rule you know of. The traffic is getting in another way: a second firewall, a cloud security group, a load balancer listener, a port forward on a router. Find the path before you do anything else.
- A rule, but nothing reachable behind it. The system is gone, or the rule never matched. It is a candidate to remove.
- A rule and a reachable service. This is the normal case, and it gets the 12 questions below.
The comparison takes an hour and finds the rules a console-only review never sees, because a console-only review can only review what the console shows.
The 12 questions for every inbound rule
- What service does this rule allow? Name the system, not only the port. “TCP 443 to 203.0.113.10” is a rule. “The customer portal” is an answer.
- Why does it need to be reachable from the internet at all? Needed and public are two different questions. A service can have every reason to run and no reason to be public.
- Is it a management interface? SSH, RDP, database ports, the admin pages of firewalls, routers and VPN devices, hypervisor and backup consoles. These almost never need to be public. CISA’s directive to US federal agencies orders them taken off the public internet, or put behind zero-trust access control, within 14 days of discovery; CISA’s performance goals for critical infrastructure say the same in one line: assets on the public internet expose no exploitable services, such as remote desktop protocol. If the interface must stay reachable, Cyber Essentials asks for a documented business need and multi-factor authentication or an IP allow list in front of it.
- Who asked for this rule, and who approved it? A rule without an approver is a rule nobody will defend in the next review either.
- Who owns it now? The team that gets the ticket when something is found behind this rule. If the answer is a person who has left, the rule has no owner.
- Is it temporary? If yes, until when? A temporary rule without an end date is a permanent rule. If the date has passed, the review is over for this rule.
- Is the source as narrow as it can be? “Any” is a decision, not a default. If only three partner addresses need this, the rule should say so.
- Is the destination and the port as narrow as it can be? A rule that allows a range of ports to a range of hosts for one service is a rule that allows much more than one service.
- Is it still used? Hit counters and logs answer this. A rule with no traffic over the last review period is a candidate to disable now and remove after a grace period, so an annual batch job can still object before it is gone.
- Is the service behind it patched and supported? The external scan shows the versions an attacker sees. CIS Controls asks for externally-exposed assets to be scanned for vulnerabilities at least monthly, which is a useful cadence for this question too.
- Does a scan from the outside confirm what the rule says? The rule says one port to one host. The scan says what is really open. When they disagree, the scan is right.
- Is the justification written down where the next reviewer will find it? One line is enough: what the service is, why it has to be reachable from the internet, who approved it, and until when. This is the same line an attack surface inventory keeps for each exposed asset, so write it once and keep it in both places or in one place both can read.
The review record
Keep the record in a table, one row per inbound rule, and keep it next to the rule set rather than in a report that nobody opens twice.
| Rule | Service | Public because | Approved by | Owner | Until | Decision | Verified from outside |
|---|---|---|---|---|---|---|---|
| FW-0142: TCP 22 from any to 203.0.113.20 | SSH on the build server | Contractor access during the migration | Head of IT, 2025-11 | Platform team | 2026-01-31 | Move off the internet: VPN only; remove the rule | 2026-10-30: port 22 open to the world |
Four decisions cover almost every rule: keep as it is, narrow it, move the service off the internet, or remove the rule. The second and third are where the attack surface actually shrinks, and both cost a ticket.
How often
At least every six months, which is the floor PCI DSS sets for rule set reviews. Also after every change to the perimeter, such as a new public service, a new cloud account or a merger. And on the date written in each temporary rule, without waiting for the next full review. Between reviews, let the outside view do the watching: a port that opens after the review should reach you as a change, not as a surprise six months later.
Where Vulmon Recon fits
The outside list in this checklist is what Vulmon Recon produces and keeps current: your domains and IP addresses, the open ports and services on them, and the certificates they present. Its asset review records the justification and the owner for every exposed asset and every port in the same one-line form as question 12, so the firewall review and the asset review share one record. And because it keeps scanning, a new port or a new host shows up in the inventory as a change rather than waiting for the next review.
The method behind this checklist, from finding what you expose to deciding what stays, is on How to reduce your external attack surface. If you want the outside list for your own perimeter first, request a trial; trials run for 14 days with the full product and no card on file.
Related: What a vulnerability scanner cannot see and Introducing Vulmon Recon.