Firewall Modernization: From Rules to Risk

Firewall modernization is usually scoped as a hardware refresh or a vendor change. The project plan counts devices, licenses and cutover windows. What it rarely counts is how much of the risk the old platform carried will be copied across with the configuration.

Three things carry risk in a firewall estate, and a modernization program should address all three. The first is the rules: what traffic is allowed and why. The second is the device: a security product that sits on the internet boundary and is itself a target. The third is the process: how rules and configuration change, who approves them and how long they live.

The rules: what accumulates over time

Rule bases grow in one direction. Projects need temporary access and the rule outlives the project. An outage leads to a broad rule added at speed and never narrowed. Staff leave and take the reason for an exception with them. Over time the rule base contains shadowed and redundant entries, broad source and destination ranges, and rules nobody can explain.

NIST’s guidance on firewalls and firewall policy is an older publication, and its survey of firewall technology predates current application-aware and cloud-integrated platforms. Its central point still holds: firewall behavior should follow a written policy that is selected, configured, tested and managed deliberately, rather than assembled one request at a time.

A useful way to review a large rule base is to rank rules by exposure rather than by age. Age alone tells you little. Exposure and sensitivity tell you where to look first.

Review lens	Question to ask	Typical action
Exposure	Does the rule allow traffic from untrusted networks, or from broad internal ranges?	Narrow sources and destinations; add inspection where it is warranted.
Sensitivity	Does it reach administrative services, identity infrastructure or crown jewel systems?	Require an owner justification and, where possible, an identity condition.
Ownership	Is there a named owner and a current business reason?	Assign one, add an expiry, or schedule the rule for retirement.
Evidence	Is the rule logged, and what does its hit history show?	Enable logging and observe before removal; disable in stages.
Dependency	Does it support disaster recovery, batch, seasonal or audit processes?	Confirm with the process owner before any change.

Hit counts need care. A rule with no recent hits may be unused, or it may support a recovery path that has not been exercised. Removing it on the numbers alone is how a clean-up becomes an incident. Disable first, monitor, then delete.

Consider a hypothetical migration in which several thousand rules are exported from the old platform and imported into the new one by script. The project closes on time and the new devices perform well. The broad rules, the stale exceptions and the unowned entries are all still there, now running on a platform that was bought to be a security improvement.

The device: a security product that is also a target

Joint guidance from the Australian Signals Directorate’s ACSC, CISA and international partners on edge devices makes a plain observation. Firewalls, routers and VPN gateways sit at the internet boundary, usually with public addresses, so attackers can find and probe them from anywhere. Targeting these devices has become a common tactic, including by state-sponsored actors, and a compromised edge device can help an attacker bypass boundary protections and reach internal systems.

The guidance’s recommendations for owners translate directly into modernization requirements.

Know what you have. Keep a current inventory of every edge device and its vendor support timeline, so devices approaching end of support are visible before they become a risk.
Protect the management plane. Manage devices only from a separate out-of-band network or a dedicated, hardened administrative workstation, and keep management interfaces off the internet.
Log off the device. Send logs to a central system at the most detailed level practical, and alert on administrative logins, configuration changes and hardware changes.
Baseline and review configuration. Document a baseline, change default credentials, disable unneeded services and apply vendor hardening guidance. Require a second person to review security configuration changes, and protect administrative access with phishing-resistant MFA.
Plan for end of life. Replace or remove devices before support ends. Where that is not possible, put compensating controls in place, because unpatched flaws stay exposed after support lapses.
Consider vendor diversity. The guidance suggests using more than one vendor for edge functions to reduce supply chain risk, and expecting devices to ship hardened.

A modernization project is the cheapest moment to build these in. Retrofitting an out-of-band management network, central logging and configuration review onto a platform already in production is slower and more disruptive than designing them into the cutover.

The process: how rules are requested, approved and retired

Cleaning the rule base without changing how rules are created produces a clean rule base for a short time. The process needs a few properties to keep it clean.

Every rule request carries an owner, a business purpose, a scope and an expiry or review date.
Rules are recertified on a schedule, with owners confirming they are still needed, and unanswered rules treated as candidates for removal.
Changes to security-relevant configuration are reviewed by a second person and logged.
Emergency changes are allowed but are reviewed afterwards and either made permanent properly or reversed.

Policy-analysis and automation tools can help with shadowed rules, unused objects and change workflows. They support the process rather than replacing it, and their value depends on the quality of the ownership data they work from.

Decisions to make before the cutover

Like-for-like or redesign

A like-for-like migration is faster and lower risk to availability. A redesign takes longer and finds undocumented dependencies the hard way. The practical middle path is to migrate the rules that pass the review above, restructure the zones where the current design is clearly wrong, and set a date for revisiting the remainder.

What stays address-based

Some access can move to identity-aware controls, where policy refers to a user, device or workload rather than an address. If that work is planned, the firewall rule base should shrink as it lands. Carrying every address-based rule across unchanged, while identity-aware enforcement is built elsewhere, leaves two overlapping policy sets and unclear ownership of each. The sequencing of the two programs is an architecture decision, not a firewall detail.

Inspection depth

Decrypting and inspecting traffic gives visibility into what is crossing the boundary. It also adds performance cost, certificate management, and privacy and legal considerations that differ by data type and jurisdiction. Decide which traffic is inspected and why, rather than enabling everything the platform supports.

Cloud and virtual firewalls

Where workloads have moved to cloud platforms, check whether virtual appliances are duplicating controls the provider’s native network controls already offer, or whether they are providing consistency that the team needs. The answer varies by environment, and both choices have operational costs.

Measuring the result

The number of rules removed is an easy figure to report and a poor measure of risk reduction. Better indicators describe exposure and control.

Management interfaces reachable from the internet: the target is none.
Share of rules with a named owner and a review or expiry date.
Edge devices past, or within a defined window of, vendor end of support.
Time from a vendor security advisory affecting an edge device to the device being patched or mitigated.
Administrative and configuration changes reviewed by a second person.

A PRACTICAL TEST

Choose any five rules that allow access to administrative services or sensitive systems. For each, can someone tell you who owns it, why it exists and when it was last confirmed? If not, the migration will carry unmanaged exposure across to the new platform.

What to do next

Before the next refresh is scoped, add three items to the project plan alongside the hardware: a risk-ranked review of the existing rules, the management plane and logging requirements for the new devices, and the rule lifecycle process that keeps the result clean. If you want a second view on rule base review, platform selection or how the work should be sequenced with identity-aware segmentation, a firewall assessment ahead of the cutover is the most useful point to bring in outside support.

Sources

NIST SP 800-41 Revision 1, Guidelines on Firewalls and Firewall Policy. National Institute of Standards and Technology
Guidance and Strategies to Protect Network Edge Devices. Cybersecurity and Infrastructure Security Agency, with the Australian Signals Directorate’s ACSC and international partners. Includes the joint publication Security Considerations for Edge Devices
Microsegmentation in Zero Trust, Part One: Introduction and Planning. Cybersecurity and Infrastructure Security Agency. Source for network-level enforcement points, including next-generation firewalls