Open Paths, Closed Loop: Retiring Firewall Exceptions on a Quarterly Cycle

Most UK regulated estates do not have a firewall policy. They have a firewall archaeology. Every rule, security-group ingress and proxy allowlist entry began as a time-boxed concession to a project, a supplier or an urgent fix. The ticket closed; the path stayed open. Years later, the rulebase is the longest-lived artefact in the environment and the least understood.

The useful reframing is this: an exception is an integration. It connects a source to a destination, carries data across a trust boundary, and creates a dependency between teams. If we would not tolerate an undocumented API integration with no owner, we should not tolerate an undocumented network path with the same defects.

The most permanent phrase in networking

'Temporary' has a remarkable half-life in infrastructure. An exception form approved for a six-week migration is still present six years later, often replicated across a secondary data centre, a DR site and two cloud regions. In regulated settings the auditor's question is predictable: who approved this path, on what business justification, with which compensating controls, and when was it last reviewed? If the answer is that it lives in the firewall, that is a finding waiting to be written.

The objective is not a purge. It is proof. Every open path should be justified, monitored and reversible, and the organisation should be able to demonstrate all three from a single evidence pack.

Build the exception register first

A cull without a register is just an outage with extra steps. The register should be a controlled artefact, versioned and reviewed, with five mandatory fields for every exception:

• A unique identifier and the vendor-specific rule reference: object group, security-group ID, proxy rule number or policy stanza.
• A named technical owner, an individual engineer rather than a team alias.
• A business owner and a justification tied to a service recorded in the CMDB, not to a person who has since left.
• An expiry date. Ninety days by default, twelve months as an absolute ceiling, with renewal requiring fresh justification.
• A reversibility note: what breaks if the path closes, how that would be detected, and how the change would be rolled back.

Add the data classification that traverses the path, the compensating controls in place, and the log source that would reveal misuse. Treat the register as an integration catalogue, because that is precisely what it is.

Discovery before discipline

Rulebases drift from reality. Use firewall hit counts, proxy logs and cloud flow logs to establish which paths are actually carrying traffic. A rule with no hits over ninety days is a candidate for retirement, but absence of evidence is not evidence of absence: confirm that logging covers the segment before drawing conclusions. Hybrid UK estates complicate this, since the effective path across MPLS, SD-WAN and ExpressRoute interconnects may differ from the intended one. Draw the path as it is, not as the diagram claims.

A four-stage quarterly cull

The cull should be a scheduled control, not an incident response. A defensible cycle looks like this.

First, freeze. No new exception is granted without an expiry date and a named technical owner. This alone stops the register decaying as fast as it is built.

Second, classify. Sort every entry into stale, orphaned, shadowed or justified. Shadowed rules, where two paths reach the same destination and only one is documented, are particularly common after acquisitions.

Third, notify. Give technical and business owners fourteen days' notice with the evidence attached: hit counts, last-review date, the proposed change window and the rollback step.

Fourth, disable rather than delete. Move the rule into a monitor-only or deny-with-alert state for seven to fourteen days, watch the SIEM and application telemetry, and only then remove it. Record the closure against the exception identifier in the change record.

Reversibility is the safety net

Teams resist culling because they have been burned by an outage caused by a well-meaning tidy-up. Reversibility answers that fear with a runbook rather than reassurance: a configuration backup taken immediately before the change, a documented rollback completing in under fifteen minutes, a named engineer on call and an alert that fires if the path is unexpectedly required. This is the same discipline applied to cloud exit readiness, and it works because it converts an irreversible act into a testable one.

Measure what the board can act on

Report five figures each quarter: the proportion of exceptions with a named technical owner, the median age of open exceptions, the count past expiry, the number retired in the period, and incidents attributable to retirement. The last should be tracked honestly; a cull programme that claims zero disruption without evidence will not survive its first audit. Map the reporting to recognised frameworks such as the NCSC Cyber Assessment Framework or ISO 27001 access-control objectives so that the risk committee sees familiar language.

What four quarters of discipline delivers

The rulebase contracts. The register becomes the authoritative record of what is connected to what, which is useful well beyond security: it shortens integration discovery for new projects and reduces the scope of incident investigation. The change advisory board spends less time debating rules whose purpose nobody remembers, and auditors receive an evidence pack rather than a scramble.

Resilience through subtraction is not a slogan. It is the recognition that every path you do not have to defend, monitor and justify is capacity returned to the organisation. Begin with one estate. Export the rules, match them to the CMDB, name the owners, set the expiries, and start with the two rules that nobody can explain.