Firewall change management is a lifetime problem, not an approval problem

Firewall change management gets measured on the thing that is easiest to measure: how fast a request moves from ticket to deployment. That number can look excellent while the estate gets steadily worse. A reviewer reading a three-line diff can tell you whether a permit is narrow and whether the requester's manager approved it. They cannot tell you that the rule will shadow a deny three objects further down the policy, that the vendor CIDR it references gets reassigned in eighteen months, or that the temporary exception from 2021 is still passing traffic from a decommissioned subnet. Approval is the cheapest part of the lifecycle and the least predictive of incidents.

The unit of firewall risk is the rule, not the ticket

Every metric your process reports is ticket-shaped, and tickets disappear the moment they close. Rules do not. If your estate carries 12,000 rules across a few hundred policies and you process 30 changes a week, you are adding on the order of 1,500 rules a year before anyone removes one. Run that forward three years and ask what fraction of the rule base has a current, reachable owner. The honest answer is usually the fraction that changed recently — the minority.

Sort your rule base by last-modified date and the pattern is hard to miss: the genuinely dangerous rules cluster in the oldest decile, added before the current tagging standard, inherited from a migration, or created by a script nobody still owns. Meanwhile the diff a reviewer sees is three lines. The blast radius is whatever those three lines expose or shadow, which is a function of the other 11,997.

Second-order effects are what page you at 2 a.m.

The rules that hurt you are almost never the ones in this week's change window. They are the ones that changed meaning without changing text. A contractor's home-office /32 is permitted to the jump host — correct on day one. Fourteen months later the ISP has reassigned that address, the contractor has left, and the rule still passes traffic. Nobody changed anything, which is precisely why nothing caught it.

Shadowing works the same way. A permit added for a migration lands above a deny that was protecting a PCI segment. The deny is still in the config, so a grep-based audit cheerfully reports the control as present. Order matters, and any review process that reads rules instead of evaluating them will miss this every single time. The control you think you have and the control the packet path actually enforces are two different artifacts.

Expand–contract is the only change shape that survives production

Additive-first is not a stylistic preference; it is the difference between a change you can reverse and one you cannot. The sequence:

1. Add the new permit alongside the old one, scoped as narrowly as the flow logs permit.
2. Let it run for an observation window that covers your slowest recurring job — a monthly batch means 31 days, not 7.
3. Confirm hit counters on the old rule. Zero hits across the full window is the only evidence that counts.
4. Remove the old rule in a separate change, with its own approval and its own rollback.
5. Re-verify with a policy simulation run, not a ping from one host.

A seven-day window is the default in most tooling, and it is wrong for anything with a monthly cadence. Pick the window from the job schedule, not from the sprint.

A firewall change is not finished when it is deployed. It is finished when the old rule is gone.

Four fields or it is already debt

Metadata is the control. A rule without these four attributes is not governed, regardless of how tidy the ticket looked:

• Owner — a person or a standing team, never a distribution list that quietly grew a -noreply alias.
• Expiry — a real date, or an explicit permanent flag with a written justification.
• Reason — the originating ticket plus one sentence a stranger could understand in six months.
• Scope justification — why this CIDR and port range, and what narrower option was rejected.

Quarterly recertification at a 5% random sample is theater; nobody reads the sample carefully. The version that works is expiry-driven: the system asks about a rule when it comes due, the owner must actively re-justify it, and silence is treated as a decision to remove. Removal becomes the default, which is the only way the rule count ever goes down.

Rollback you have not executed is a hypothesis

Ask for the rollback command during review, run it in staging against a copy of the policy, and time it. Changes that take more than 15 minutes to reverse are the ones that turn into hour-long incidents, because the on-call engineer discovers the problem at the same moment they discover the recovery path. If the rollback is restore the last configuration backup, you do not have a rollback — you have a revert of every unrelated change made since that backup, including the fix someone else deployed forty minutes ago.

Estimate blast radius before you need it: how many distinct source-destination pairs does this rule touch, and how many tier-one services sit in the affected object groups? Two numbers, computed in a minute, tell you more about risk than the entire approval thread.

The change board is becoming a policy author

Firewalls are drifting toward continuous evaluation: policy expressed as code, rule lifetime as a first-class attribute, drift detected hourly instead of at audit time. As agents begin proposing changes — with signed diffs, simulation results, and expiry already attached — the board's leverage moves upstream. Its job stops being reading permits and starts being writing the constraints automation must satisfy: no rule without a named owner, no permit to 0.0.0.0/0 without an exception record, no lifetime past twelve months without active recertification, no change without a timed rollback in the plan. The tickets will still exist. They will simply stop being the control.