Firewall Rule Impact Analysis: How to Check a Change Before You Make It

Firewall rule impact analysis answers three questions before the change window opens: which traffic will the new or edited rule match, which traffic will stop matching some other rule, and what else depends on the objects you are about to touch. You answer them against the running policy, with the vendor's own match tools and hit counts, and you write the answers into the change record. If you cannot answer all three, the change is not ready.

That sounds obvious. In practice it is the step most change processes skip, because the request looks small: one source, one destination, one port. The outage rarely comes from that one rule.

Where change-caused outages actually come from

After hundreds of migrations and rule-base reviews, the pattern is boring and consistent. The rule someone asked for works. What breaks is around it.

• Shadowing. The new rule sits above a narrower rule that carried real traffic, and that traffic now takes a different action, logging profile or NAT.
• Object edits. Someone adds an address to a group "for this change". The group is used in 40 rules. Thirty-nine of them just changed too, and nobody reviewed them.
• Wrong assumptions about order. The reviewer reads the rule base top to bottom in their head and misses the NAT step, the zone the firewall really sees, or the second gateway in the cluster.

Tools help. Tufin, AlgoSec and the vendors' own AI assistants can run these checks at scale. But a reviewer who cannot do the analysis by hand has no way to tell when the tool's answer is wrong, and the approver signs whatever comes out. Learn the manual method first; then let the tool do it faster.

The six-step method

1. Write the request as flows

Turn the request into flows: source, destination, service or application, direction, and the NAT that applies. One flow per line.

10.20.4.0/24 -> 172.16.30.12  tcp/443  outbound  (no NAT)

If the requester cannot fill in a line, the request goes back. "Access to the new API" is not a flow. Many bad changes are decided at this step, because the rule gets written for what someone thought the application does.

2. Test the flow against the running policy

Do not reason about the rule base. Ask the firewall which rule matches today.

• Palo Alto Networks: test security-policy-match on the CLI, or Test Policy Match in the web interface. The PAN-OS documentation describes it as the way "to determine whether a security policy rule is configured correctly". Give it source, destination, port, protocol and, where relevant, the application and user.
• FortiGate: diagnose firewall iprope lookup <src_ip> <src_port> <dst_ip> <dst_port> <protocol> <interface>, or Policy Lookup in the GUI, called policy match from FortiOS 7.4. A result of policy ID 0 means no policy matches and the implicit deny applies.
• Check Point: search the rule base in SmartConsole in Packet Mode with the same source, destination and service, so it shows the rules that would match the connection rather than the rules that merely contain the text.

Write down the matching rule. This is your "before" picture, and it often ends the change on the spot: the flow already matches a broader rule, and the request was really a connectivity problem somewhere else.

3. Place the rule and check order and shadowing

Decide where the new rule goes, then repeat the test. Two questions:

• Does the new rule catch traffic that a rule below it used to handle? List those rules.
• Is the new rule itself shadowed by a broader rule above it? Then it will never be hit, and the change does nothing except add clutter.

Test with the addresses the firewall actually sees. On Palo Alto Networks, security policy evaluates the post-NAT zone; the rule of thumb engineers use is "pre-NAT IP, post-NAT zone". A reviewer who tests with the public address while the rule is written for the private one gets a clean result and a broken change.

4. Measure the object blast radius

If the change edits an object or a group instead of adding a rule, run Where Used on it and count the rules. An object change is a change to every one of those rules, and each of them needs the same before-and-after check. This is the step that most often turns a "small" change into a reviewed one.

5. Read the usage evidence

Look at hit counts and last-hit times for the rules around the change, and treat them as evidence, not proof.

On Check Point, the R81.20 administration guide says Hit Count is "globally enabled for all supported Security Gateways" by default, keeps data for three months by default, and "tracks the hits even if the Track option is None". It also states the limit plainly: a rule with a zero hit count "only means that in the Security Gateways enabled with Hit Count there were no matching connections. There can be matching connections on other Security Gateways."

Palo Alto Networks records Hit Count and Last Hit per rule, and FortiGate keeps policy hit counters. The same caution applies everywhere: a three-month window does not see the yearly disaster-recovery test, the quarterly batch job or the partner who connects twice a year.

Remember what the lookup tools are. Fortinet's own note says policy matching "does not generate traffic or verify whether the destination server is reachable". A clean lookup proves the policy decision, not the routing, the server or the return path.

6. Write the impact statement

Put the result into the change record in a form an approver can actually check:

Flow(s):            10.20.4.0/24 -> 172.16.30.12 tcp/443
Matches today:      rule 118 "deny-dev-to-prod"
Matches after:      new rule 117 "app-api-https"
Rules now shadowed: none (rule 119 checked, no overlap)
Objects edited:     none
Hits on neighbours: rule 118: 1,204 in 3 months (all from 10.20.9.0/24)
Rollback:           disable rule 117, no object changes to undo

Now the approver signs a set of facts, not a ticket title.

What tools and reviewers miss

These come up again and again in post-incident reviews:

• Return traffic and asymmetric routing. The policy allows the flow, but the reply leaves through another firewall or another cluster member that never saw the session.
• NAT. Testing with the public address when the rule matches the private one, or forgetting that destination NAT changes what the firewall evaluates. Fortinet notes that with VIP/DNAT the match result "may differ from the original destination IP entered by the client".
• User-based rules. On FortiOS versions without the extended lookup syntax, the lookup cannot take a user or group, so it may miss policies that need authentication.
• The wrong gateway or VRF. A lookup on the wrong cluster member, virtual system or routing table gives a confident, wrong answer.
• The rule that looks unused. Zero hits in three months, and it carries the yearly disaster-recovery test. Ask the owner and look at the last test evidence before you remove or narrow it, as in any rule decommissioning.

Make it part of the change process

Impact analysis works when it is a field in the change record, not a habit of the one senior engineer who always does it. Make the six answers mandatory for every change that adds, moves or edits a rule or an object, and reject requests that arrive without flows. Emergency changes get the same analysis afterwards, inside the emergency change workflow, and anything changed outside the process shows up in change monitoring and drift detection. The time it costs is minutes per change. The time it saves is the night you would otherwise spend finding out which of the 40 rules behind that group just changed.

Run the six steps on your next change request, and see the firewall change management guide for how impact analysis fits into the full process from request to audit evidence.