Firewall Management Guide: Rules, Reviews and Policy Hygiene

Most firewall rule bases grow for years without anyone removing a rule, until nobody can say which of thousands of entries are still needed, who asked for them or what an "any" in a rule really permits. This guide covers firewall management as an operational discipline: rule design, default deny, change control, periodic rule reviews, finding shadowed, redundant and unused rules, cleanup, hardening the firewall's own management plane, host and cloud firewalls, automation and logging. It is written for network and security engineers who run perimeter, internal and cloud firewalls, and for auditors who review them. Choosing ports to expose is covered in the Network Ports and Protocols Security Guide and zone design in the Network Segmentation Guide.

Key takeaways

• Default deny in both directions. NIST SP 800-53 SC-7(5) requires denying traffic "by default" and allowing it "by exception"; outbound rules matter as much as inbound for stopping command and control and exfiltration.
• Every rule needs an owner, a reason and an end date. Rules without a ticket reference and an accountable owner cannot be reviewed, and temporary rules without expiry become permanent.
• Review on evidence, not memory. Hit counts over a full business cycle, shadowing analysis and owner recertification find the rules to remove; PCI DSS v4.0.1 requires network security control configurations to be reviewed at least every six months.
• The management plane is the real perimeter. A firewall whose admin interface faces the internet or whose admin accounts lack MFA can be reconfigured by an attacker, which ATT&CK tracks as T1686 Disable or Modify System Firewall.
• Changes are the signal to watch. Log and alert on every configuration commit, rule addition and firewall service stop, on network, host and cloud firewalls alike.

Firewall types and where each fits

NIST SP 800-41 Rev. 1 describes the range of network traffic filtering technologies. Most modern products combine several of them, but the distinctions still decide what a rule can express.

Open source firewall distributions such as pfSense and OPNsense, both based on FreeBSD, provide stateful filtering with the same management needs: a rule base, change control, backups and logs.

Designing the rule base

• Default deny: NIST SP 800-41 says firewalls should block traffic the policy does not expressly permit, and that "deny by default policies should be used for incoming TCP and UDP traffic". End every policy with an explicit deny rule that logs, so denied traffic is visible rather than silently dropped by an implicit rule.
• Specific rules: "Firewall rulesets should be as specific as possible with regards to the network traffic they control." Name source and destination objects and the exact service. An any-any rule (any source, any destination, any service) should exist nowhere except a documented, alerted emergency bypass.
• Egress filtering: allow servers out only to the destinations they need (update services, partners, DNS resolvers), and route user web traffic through a proxy or secure web gateway. NIST also calls blocking outbound traffic with invalid source addresses egress filtering.
• Invalid and spoofed addresses: NIST states that "Traffic with invalid source or destination addresses should always be blocked". Drop inbound packets from RFC 1918 ranges, bogons and your own public ranges at the internet edge, and block inbound broadcasts and IP source routing.
• IPv6: filter IPv6 with the same policy as IPv4. If IPv6 is not used, NIST advises blocking native and tunnelled IPv6. Do not block all ICMPv6: Packet Too Big messages are required for path MTU discovery.
• Ordering: firewalls evaluate rules top down and stop at the first match. Put specific denies above broader allows, and, for performance, NIST suggests rules "that have the highest chance of matching traffic patterns should be placed at the top of the list wherever possible", as long as that does not change the outcome.
• Objects and naming: use named address and service objects with a consistent convention (H-SRV-PAY-DB01, N-DMZ-WEB, SVC-TCP-8443) instead of raw IPs in rules. Delete orphaned objects that no rule references.

Each rule should carry a standard set of metadata, either in the rule comment field or in a policy management tool:

Rule reviews and rule base hygiene

Anomalies to find and fix

• Hit count caveats: counters may reset on reboot, failover or upgrade, and a zero count can mean traffic is matched by an earlier rule. Record the counter start date before concluding a rule is unused.
• Cleanup method: disable rather than delete first, watch the logged final deny for the traffic the rule used to allow, wait two to four weeks, then delete. Restoring a disabled rule is a one-line change if something breaks.
• Optimisation: merge rules with identical sources, destinations and actions, and convert port rules to application-aware rules where the NGFW supports it.

Review cadence and recertification

• Cadence: PCI DSS v4.0.1 requirement 1.2.7 requires network security control configurations to be reviewed at least once every six months. Use quarterly reviews for internet-facing and high-risk rules and at least every six months for internal rules.
• Owner recertification: send each owner their rules with hit counts and last-hit dates and ask them to keep, narrow or remove each one. No response within the deadline means the rule is disabled.
• Traffic comparison: compare each allow rule with the flows it actually carries. A rule allowing TCP 1 to 65535 that only ever carries TCP 443 should be narrowed to TCP 443.
• Configuration review: audit the device configuration itself against vendor or CIS benchmarks: management access, logging, NTP, SNMP version, unused services and firmware version.
• Evidence: keep the review record (rules reviewed, decisions, changes made) as firewall audit evidence.

Change management and rule lifecycle

NIST SP 800-41 states that "Firewall rulesets and policies should be managed by a formal change management control process". SC-7(4) adds that each exception to the traffic flow policy should be documented with its business need and duration.

1. Request: the requester names source, destination, service, business reason, owner and end date in a standard form.
2. Risk review: a reviewer checks the request against zone policy (for example, no direct internet to database zones) and rejects any, broad ranges or cleartext management protocols.
3. Pre-change analysis: test whether the change is already permitted, whether it shadows or is shadowed by an existing rule, and which compliance zones it touches.
4. Peer review and approval: someone other than the implementer approves the exact rule text.
5. Implement and verify: commit in a change window, confirm the intended flow works and that adjacent flows are still blocked, and save a configuration backup.
6. Rollback: keep the previous configuration version; most platforms support reverting a commit. Define the rollback trigger before the change.
7. Recertify or expire: temporary rules lapse automatically; permanent rules are recertified by their owner at each review.

Emergency changes during incidents should be allowed with retrospective approval within one working day, and reviewed at the next change board.

Automation and orchestration

• Policy as code: hold rules in version control, review them by pull request, and deploy through the vendor API or infrastructure-as-code providers. The repository becomes the change record.
• Pre-deployment checks: run automated tests in the pipeline that reject any-any rules, management ports open to the internet and rules without owner or expiry fields.
• Firewall policy management tools: multi-vendor orchestration tools normalise rules across platforms, calculate shadowing and redundancy, simulate whether a flow is allowed end to end, and automate recertification. They earn their cost in estates with hundreds of firewalls or several vendors.
• Central managers: use shared objects and policy templates in the vendor console so a rule is defined once, and protect the console as a tier 0 system.

Hardening the firewall and its management plane

Firewalls are edge devices, and recent joint guidance from ASD's ACSC, CISA, NCSC-UK and the Canadian Centre for Cyber Security treats them as prime targets. ATT&CK T1190 notes that adversaries "may also exploit edge network infrastructure and related appliances".

• Management interfaces: ASD's practitioner guidance states "Networked management interfaces for IT equipment are not directly exposed to the internet". Put management on a dedicated out-of-band network reached from privileged access workstations, and restrict it with ACLs to named administrator subnets.
• Protocols: HTTPS and SSH only for administration, SNMPv3 if SNMP is needed, and disable unused VPN services, APIs and IP versions on the device.
• Patching: NIST says "Firewall software should be patched as vendors provide updates". ASD recommends a vulnerability scanner run "at least daily" against internet-facing network devices. Track end-of-life dates and replace unsupported models.
• Backups and integrity: back up configuration after every change to a store the firewall cannot write to, and compare the running configuration with the approved baseline daily.
• High availability: test failover after upgrades and confirm that both members hold the same policy. Decide whether each device should fail closed (SC-7(18) Fail Secure) or open, and document why.

Where identity fits

• Administrator accounts: authenticate admins through central AAA (TACACS+ or RADIUS) with phishing-resistant MFA and per-person accounts; ASD advises keeping edge device authentication separate from the corporate directory and managing local break-glass accounts through PAM or secrets management. See the Privileged Access Management Guide and the Break-Glass Account Guide.
• Automation credentials: API keys and tokens used by orchestration tools and infrastructure-as-code pipelines can rewrite policy on every firewall. Scope them to the minimum, store them in a vault and rotate them. See the API Key Management Guide.
• The firewall's own identities: cloud firewalls and WAFs run with cloud roles, and NGFWs bind to directories with service accounts for user identification. The Capital One Breach 2019 showed how a firewall's cloud role credentials exposed data on 106 million people.

Host-based and cloud firewalls

• Windows Defender Firewall: manage by Group Policy or Intune, enable all three profiles (Domain, Private, Public), block inbound by default, disable local rule merging so users and local admins cannot add exceptions, and enable logging of dropped packets. CIS Controls v8.1 safeguards 4.4 and 4.5 call for firewalls on servers and end-user devices.
• Linux: manage nftables or firewalld rules through configuration management, with a default drop policy on the input chain and rules held in version control.
• Cloud: security groups are stateful and attach to workloads; network ACLs are stateless and attach to subnets, so return traffic needs explicit rules. Reference security groups by ID rather than CIDR where possible, and block 0.0.0.0/0 on management ports with policy guardrails.
• Drift: treat cloud console changes that differ from the infrastructure-as-code definition as unauthorised.

Implementing a firewall management programme

1. Inventory: list every firewall, virtual firewall, cloud security control and WAF, with owner, firmware, support status and management address.
2. Baseline: export each rule base, record current hit counts and enable logging on the final deny rule.
3. Secure the management plane first: remove internet exposure, enforce MFA and central AAA, and patch.
4. Stop the growth: introduce the request form, metadata fields and expiry for new rules before cleaning old ones.
5. Clean up in rings: start with expired, disabled and orphaned rules, then shadowed and redundant rules, then unused rules after a full business cycle, then narrow overly permissive rules from traffic logs.
6. Test every cleanup batch: disable in a change window, monitor deny logs and help desk tickets, and re-enable on a defined trigger.
7. Automate: move recurring reviews, expiry and pre-change analysis into tooling and pipelines.

Choosing an approach

• Small organisations: one perimeter firewall with a short, documented rule base, host firewalls on every endpoint and a twice-yearly review is achievable with spreadsheets and the vendor console.
• Large or multi-vendor estates: central managers per vendor plus a policy management tool, policy as code for cloud, and a dedicated firewall change board.
• NGFW or stateful: an NGFW earns its place at the internet edge and between high-value zones; stateful filtering plus host firewalls is enough for many internal segments.

Logging, detection and measurement

• Central logging: ASD advises that "Log events from edge devices should be sent in real time to a centralised system" and that devices "should not have access that allows the modification or deletion of any logs". Send traffic, threat, system and configuration logs to the SIEM. See the SIEM Guide.
• Configuration change alerts: every commit, rule change, admin login and failed login on network firewalls; on Windows, Security events 4946, 4947 and 4948 (rule added, modified, deleted) and 4950 (setting changed); on cloud, API events that modify security groups and network ACLs.
• Tampering: ATT&CK T1686 Disable or Modify System Firewall (sub-techniques T1686.001 Cloud Firewall, T1686.002 Network Device Firewall, T1686.003 Windows Host Firewall) lists detection of netsh and PowerShell firewall cmdlets, sc stop mpssvc, iptables or nftables changes and unusual network device configuration commits.
• Traffic anomalies: spikes in denies from one internal host (scanning), allowed traffic on rules marked for removal, and outbound connections to unusual destinations.

Metrics:

• Percentage of rules with owner, ticket and review or expiry date.
• Number of any-any or any-service allow rules, target zero.
• Percentage of rules with zero hits in 90 days, and rules removed per quarter.
• Percentage of firewall changes with an approved ticket, compared with commits in the logs.
• Firewalls with management interfaces reachable from the internet or running unsupported firmware, target zero.
• Mean time to apply critical firewall security patches.

Framework mapping

Common failure patterns

• Temporary rules that never expire: troubleshooting and project rules outlive the people who requested them and become the broadest rules in the policy.
• Internet-facing management: admin web interfaces reachable from anywhere turn every new appliance vulnerability into a direct compromise path.
• Stolen device credentials: shared admin passwords and secrets stored in device configurations help attackers stay inside networks for years, as in the Salt Typhoon Telecom Intrusions 2025.
• Reviews without traffic evidence: owners recertify everything because they cannot see what each rule carries, so the review changes nothing.
• Implicit deny without logging: blocked traffic leaves no trace, so scanning and failed exfiltration go unseen and troubleshooting leads to broad allows.
• Cloud rules outside change control: a console edit opening SSH or a database port to 0.0.0.0/0 bypasses the firewall team entirely.

Practitioner checklist

• Inventory every firewall and cloud firewall control with owner, firmware and support status.
• Remove internet exposure of management interfaces and enforce MFA through central AAA.
• End every policy with a logged explicit deny and apply default deny to outbound traffic.
• Require owner, ticket and expiry or review date on every new rule.
• Run shadowing, redundancy and hit-count analysis and clean up in tested batches.
• Review internet-facing rules quarterly and all rules at least every six months, with owner recertification.
• Back up configurations after every change and compare running configuration with the baseline daily.
• Manage host and cloud firewalls through Group Policy, Intune, configuration management or infrastructure as code.
• Vault automation API keys and service account credentials used by firewalls and orchestration tools.
• Alert on configuration changes and firewall tampering, and report the metrics above.

Standards and references

• NIST: SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy
• NIST SP 800-53 Rev. 5 (CSF Tools): SC-7 Boundary Protection
• ASD's ACSC: Mitigation Strategies for Edge Devices, Practitioner Guidance
• CISA: Guidance and Strategies to Protect Network Edge Devices
• CIS: Controls Assessment Specification, Control 4 Secure Configuration
• MITRE ATT&CK: T1686 Disable or Modify System Firewall
• MITRE ATT&CK: T1599 Network Boundary Bridging
• Microsoft Learn: Audit MPSSVC Rule-Level Policy Change

Related NHI Mgmt Group resources: Network Segmentation Guide · Network Ports and Protocols Security Guide · Network Access Control (NAC) Guide · Privileged Access Management Guide