A next generation firewall (NGFW) degrades quietly: rules pile up, owners leave, inspection profiles get switched off for a troubleshooting call and never switched back, and the device itself falls behind on firmware while sitting on the network edge. This health check is a quarterly review of firewalls that are already in production. It gives ten metrics with formulas and thresholds covering the rule base, logging, administrative access, firmware currency, management interface exposure and threat inspection coverage. It is for network security engineers, firewall owners and the security managers who sign off the edge. It works as a firewall audit checklist that produces numbers you can trend, rather than a one-off opinion.
This page measures the estate; it does not repeat the rule-by-rule method. For a line-by-line rule review use the Firewall Rule Review Checklist, and for day-to-day operating practice the Firewall Management Guide. The metrics are vendor-neutral and apply to hardware appliances, virtual firewalls and cloud-delivered firewall services.
What this health check covers
The review covers every NGFW enforcement point in scope (perimeter, data centre, internal segmentation and cloud), the central management system that pushes policy to them, the administrator accounts and service accounts that can change them, and the logs they send to your security monitoring platform. Host-based firewalls and web application firewalls have their own reviews and are out of scope.
- Who runs it: the firewall or network security team collects the data; security operations validates the logging metric; the head of network security or CISO signs off.
- How it differs from a rule review: the rule review decides whether each rule should exist. This health check measures the state of the whole estate, so you can show whether rule hygiene, device hygiene and inspection coverage are improving quarter on quarter.
- Typical questions it answers: "what firewall rule KPIs should we report", "how many any-any rules do we still have" and "is our firewall management interface exposed".
Key takeaways
- Measure permissive rules and unused rules separately. Any-any rules are an exposure problem; rules with no hits in 90 days are a hygiene problem with a different owner and fix.
- Every rule needs a named owner and a review date. Ownership coverage and recertification rate are the two numbers that predict whether the rule base will stay clean.
- The firewall is itself a target. Edge devices are routinely exploited, so firmware currency and management interface exposure carry the strictest thresholds on this page.
- Inspection you paid for only helps if it is on. Measure the share of internet-facing allow rules with threat prevention profiles applied.
- Log what you allow, not only what you deny. A firewall that logs only denies cannot support an investigation of what got through.
How to use this template
Copy the metrics table and the findings log into your own tracker, then run this firewall health check each quarter. Collect each figure from the data sources described, score it against the green, amber and red thresholds, and record every amber or red result as a finding with an owner and a due date. Run it per firewall cluster or policy package if your estate is large, then roll up. Keep each completed review so that the trend is visible to the approver. Replace bracketed placeholders such as [Organisation] and [Role] with your own names.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Firmware and security advisory check | Weekly, and on every supplier security advisory | Firewall engineering | Head of network security | Running versions per device, advisories reviewed, decisions |
| Management interface exposure scan | Monthly, and after any network change at the edge | Security operations | Head of network security | External and internal scan results for management services |
| Administrator account review | Quarterly | Firewall engineering | Identity and access lead | Admin account export with authentication method and last login |
| Full metrics review (this page) | Quarterly | Firewall owner | CISO or head of network security | Metrics table, rule base exports, hit count reports, findings log |
| Rule recertification campaign | Annually per rule, spread across quarters | Rule owners | Firewall owner | Recertification decisions, removed rules, change tickets |
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. "Active rule" means an enabled security rule in a policy installed on a production enforcement point. Count each rule once per policy package, not once per device.
| ID | Metric | Formula | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| FW-01 | Any-any rules | Active allow rules where source, destination or service is "any" and the rule is not a documented, time-limited exception ÷ active allow rules | Rule base export from the management system | 0% | Above 0% to 1% | Above 1%, or any allow rule with any source, any destination and any service |
| FW-02 | Unused rules (90 days) | Active rules with zero hits in the last 90 days, excluding documented seasonal or disaster recovery rules ÷ active rules | Rule hit counters, rule usage reports | Below 5% | 5% to 15% | Above 15% |
| FW-03 | Rules without owner | Active rules with no named owner (person or team) recorded in the rule metadata or linked change ticket ÷ active rules | Rule comments and tags, change management records | Below 2% | 2% to 10% | Above 10% |
| FW-04 | Shadowed rules | Active rules that can never match because an earlier rule covers all their traffic ÷ active rules | Policy analysis output from the management system or a policy analysis tool | Below 1% | 1% to 5% | Above 5% |
| FW-05 | Logging enabled rules | Active rules (allow and deny) with session logging enabled and forwarded to the central log platform ÷ active rules | Rule base export, log forwarding configuration, log platform source list | 98% or above | 90% to below 98% | Below 90% |
| FW-06 | Admin accounts with strong authentication | Administrator accounts that authenticate through central identity with multi-factor authentication, are named to one person and have logged in within 90 days ÷ all administrator accounts (excluding one vaulted break-glass account per cluster) | Device and management system admin account export, identity provider records | 100% | 95% to below 100% | Below 95%, or any shared local admin account in daily use |
| FW-07 | Firmware currency | Enforcement points and management systems running a version with no outstanding supplier security fix older than 14 days ÷ all enforcement points and management systems | Device inventory with running version, supplier security advisories | 100% | 90% to below 100%, gaps scheduled within 30 days | Below 90%, any gap not scheduled within 30 days, or any device running an end-of-support version |
| FW-08 | Management interface exposure | Enforcement points whose web, SSH or API management services are reachable from outside the dedicated management network ÷ enforcement points | External attack surface scan, internal scan from user and server segments | 0% | Reachable from internal non-management segments only, with a dated plan | Any reachable from the internet |
| FW-09 | Threat profile coverage | Active allow rules permitting traffic to or from the internet with intrusion prevention, malware and URL inspection profiles applied ÷ active allow rules permitting traffic to or from the internet | Rule base export with security profile assignments | 95% or above | 80% to below 95% | Below 80% |
| FW-10 | Rule recertification rate | Active rules recertified by their owner within the last 12 months ÷ active rules | Recertification campaign records, rule metadata | 95% or above | 80% to below 95% | Below 80% |
Reading the results together
FW-01 to FW-04 and FW-10 describe the rule base. FW-05 and FW-09 describe what the firewall actually does with traffic it allows. FW-06 to FW-08 describe the security of the firewall itself. A common pattern is a clean rule base on a device with an exposed management interface; another is good device hygiene with half of internet-facing rules uninspected. Report all three groups so the approver sees both.
FW-07 and FW-08 have the strictest bands because edge devices are a recurring entry point. In February 2025 CISA published guidance with Australian, Canadian and UK partner agencies on protecting network edge devices, including the UK NCSC's specification for the logging and forensic data that network devices should make available by default. Exploitation of public-facing applications (MITRE ATT&CK T1190) and abuse of valid accounts (T1078) are the techniques the admin and exposure metrics are built to reduce; adversaries who gain access may then change firewall policy (T1686 Disable or Modify System Firewall), which is why unexplained rule changes appear in the red flags below.
How to collect the data
- Export the rule base from the central management system for every policy package in scope, including rule name, source, destination, service, application, action, enabled state, logging setting, security profiles, comments, tags and creation date. Most of FW-01, FW-03, FW-05, FW-09 and FW-10 come from this one export.
- Pull hit counts for 90 days. Confirm hit counters were not reset during the period (a reboot, a high availability failover or an upgrade can reset them on some platforms) and record the counter start date. If they were reset, extend the window rather than reporting a misleading FW-02.
- Run policy analysis for shadowed and redundant rules with the management system's own analysis function or a separate policy analysis tool. Count only rules that are fully covered by an earlier rule for FW-04; partially overlapping rules go to the rule review.
- Match owners to people. Resolve each rule owner against the HR or identity directory. An owner who has left counts as no owner for FW-03. See Firewall Rule Review Checklist for how to record ownership.
- Reconcile log sources. Compare the list of enforcement points with the sources reporting into the central log platform in the last 24 hours. A device with logging set on its rules but not reaching the platform fails FW-05. The VPN and Firewall Log Detection Guide covers which events to keep.
- Export administrator accounts from each device and from the management system, including local accounts, API keys and service accounts used by automation or orchestration tools. Join to the identity provider to check multi-factor authentication and leavers for FW-06.
- Compare running versions against the supplier's security advisories and support lifecycle pages for FW-07.
- Scan for management services from the internet and from ordinary user and server segments, on the web, SSH and API ports your platform uses, for FW-08.
Where identity fits
Firewall estates carry non-human identities that rule reviews miss: API keys used by policy orchestration and ticketing integrations, service accounts used by backup and configuration management tools, and certificates used for TLS inspection and site-to-site VPNs. Include API keys and service accounts in the FW-06 export, give each one an owner, and rotate keys on the same schedule as other privileged credentials. See the Service Account Security Guide and, for firewall rules that reference users and groups, Firewall user authentication and captive portals.
Red flags that need action now
- A management interface (web, SSH or API) reachable from the internet.
- A device running a version with a supplier security fix that has been available for more than 30 days, or an end-of-support version on the edge.
- An allow rule with any source, any destination and any service on an internet-facing interface.
- A shared local administrator account used for daily changes, or an administrator account belonging to a leaver.
- Rule changes with no change ticket, especially new allow rules or disabled logging, which may indicate tampering rather than error.
- Threat prevention profiles removed from internet-facing rules "temporarily" with no expiry.
- An enforcement point that has stopped sending logs to the central platform.
- Configuration backups not taken in the last 30 days, or stored where firewall administrators can alter them.
Findings log
| ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-NGFW-01 | [Description, population and figure, e.g. 212 of 3,400 active rules have no hits in 90 days] | FW-02 | [Critical / High / Medium / Low] | [Role] | [Date] | [Open / In progress / Closed / Risk accepted] |
| HC-NGFW-02 | [Description] | FW-08 | [Severity] | [Role] | [Date] | [Status] |
| HC-NGFW-03 | [Description] | [Metric ID] | [Severity] | [Role] | [Date] | [Status] |
Suggested due dates: red flags within 7 days, red metrics within 30 days, amber metrics within 90 days. Rule removals follow the normal change process: disable first, monitor for a full business cycle, then delete. Risk acceptance needs the firewall owner's signature and an expiry date.
Remediation map
| Finding type | Where to fix it |
|---|---|
| Permissive, unused, ownerless and shadowed rules (FW-01 to FW-04) | Firewall Rule Review Checklist |
| Logging gaps (FW-05) | VPN and Firewall Log Detection Guide |
| Administrator access (FW-06) | Firewall Management Guide and Service Account Security Guide |
| Firmware and management exposure (FW-07, FW-08) | Firewall Management Guide and Network Security Guide |
| Inspection coverage (FW-09) | Next-generation firewall (NGFW) rollout playbook |
| Recertification backlog (FW-10) | Firewall Policy Management (if tooling is the constraint) and Network Security Policy Template |
Related guides
- Firewall Management Guide: the operating practice this review measures.
- Firewall Rule Review Checklist: the rule-by-rule review behind FW-01 to FW-04.
- Network Security Maturity Model: where these results place your network security programme.
- Network Segmentation Guide: for internal segmentation firewalls.
- Next-generation firewall (NGFW) migration playbook: if the findings point to a platform change.
References
- NIST: SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy
- NIST: SP 800-53 Rev. 5 (SC-7 Boundary Protection and SC-7(5) Deny by Default, Allow by Exception, CM-3 Configuration Change Control, AC-6(5) Privileged Accounts, SI-2 Flaw Remediation, AU-12 Audit Record Generation)
- NIST: Cybersecurity Framework 2.0 (PR.IR-01 networks protected from unauthorised access, PR.PS-02 software maintained, PR.PS-04 log records, DE.CM-01 networks monitored)
- CISA: Guidance and Strategies to Protect Network Edge Devices
- CIS: Critical Security Controls v8.1 (Control 4 Secure Configuration of Enterprise Assets and Software, Control 12 Network Infrastructure Management, Control 13 Network Monitoring and Defense)
- MITRE ATT&CK: T1190 Exploit Public-Facing Application and T1686 Disable or Modify System Firewall
Related NHI Mgmt Group resources: Firewall Management Guide, Firewall Buyer's Guide, MITRE ATT&CK T1686 Disable or Modify System Firewall, Network Security Guide.