A strong firewall is one whose configuration is tight, current and watched. Four things decide that: a default-deny rule set with every rule owned, prompt patching, a locked-down management interface, and logs someone reads. A device with many features and an overgrown rule set is weaker than a plain one that is well kept.
Why not judge by features?
NIST SP 800-41 Rev. 1 covers firewall technologies, their capabilities and their relative advantages and disadvantages, and then spends as much effort on policy, configuration, testing, deployment and management. That balance is telling. A firewall enforces only the rules you give it, so the quality of the rules and the operation around them decide the outcome.
What does a tight rule set look like?
Default deny. Anything not explicitly allowed is blocked, inbound and outbound.
Specific rules. Named source, destination and port, not any to any. Each rule has an owner, a purpose and, for temporary access, an expiry date.
Ordered and reviewed. Rules are processed in order, so a broad rule high in the list can make later rules useless. Periodic review removes rules for systems that no longer exist.
Outbound control. Many rule sets filter inbound carefully and leave outbound open, which gives malware an easy way out.
A constructed example: a firewall holds 900 rules after ten years. A review finds 240 reference decommissioned servers, 60 have no owner, and 14 allow any source to a database port, added for a vendor who left in 2021. None of those rules were visible on a feature sheet. Each is a path.
What about the device itself?
Firewalls are software, and software has flaws. Devices at the network edge are reachable from the internet, so they are attractive targets. The CISA Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of exploitation, and it is worth searching for the products you run. Subscribe to your vendor's advisories and set a patch deadline for edge devices that is shorter than for internal systems.
Protect the management interface as much as the traffic. It should not be reachable from the internet, should sit on an administrative network, require MFA, use named accounts, and log every change.
What about logs and testing?
Logs turn a firewall into a sensor. Send them to central storage, keep them long enough to cover a slow investigation, and alert on patterns such as a burst of denied outbound connections from one host. NIST 800-41 also recommends testing, so confirm that the rules do what you think by testing from outside and inside, and keep a backup of the configuration with change history.
A strong firewall also sits in a design with other layers. NIST SP 800-207 argues that network location should not be the only basis for trust, so pair the firewall with identity, endpoint and segmentation controls.
What should you do after a change?
Treat each change as a small project. Record the request, the reason and the approver, apply it in a maintenance window, test it, and review the log afterward. Emergency changes happen, but they should be written up within a day and reviewed for removal. A change process that people skip becomes the way rules pile up.
How to check or apply this
- Export the rule set and mark each rule with an owner, purpose and review date.
- Find any rules that allow any source, any destination or any port, and replace them with specific rules.
- Confirm the last rule denies all traffic, in both directions.
- Remove rules that reference systems that no longer exist or have no owner.
- Check the firmware against vendor advisories and the KEV catalog, and set a patch deadline.
- Restrict management access to an admin network with MFA and named accounts.
- Send logs to central storage and alert on unusual denied traffic.
- Test the rules from outside and inside each quarter, and keep a configuration backup.
Quick check
Does a next-generation firewall make a stronger firewall?
Not on its own. More inspection features help only if they are configured, maintained and monitored. A clean rule set and patched firmware matter first.
How often should rules be reviewed?
At least yearly, and whenever a system is retired or a vendor engagement ends. Temporary rules should expire on their own.
Sources
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
- CISA, Known Exploited Vulnerabilities Catalog
- NIST SP 800-207, Zero Trust Architecture
Last reviewed: 18 October 2026.
