Rule bases grow with every project and almost never shrink, so after a few years nobody can say with confidence which of thousands of firewall rules are still needed or what a single change will break. Network security policy management (NSPM) tools read the configurations of firewalls, routers, cloud security groups and sometimes Kubernetes network policies, then analyse rules, model the network path between any two points, automate change requests and produce compliance reports. This vendor-neutral buyer's guide is for network security, firewall operations and audit teams evaluating NSPM, usually once the estate spans several firewall vendors or clouds. It is about the management layer, not the firewall itself: for choosing firewalls see the Firewall Buyer's Guide, and for rule design, review cadence and cleanup method see the Firewall Management Guide.
Key takeaways
- Normalisation is the foundation. Everything else depends on the tool parsing every device, object, NAT rule and cloud construct you run correctly, so test with your real configurations, not the demo set.
- Path analysis separates NSPM from rule linting. The tool must know the topology to answer "is this flow already allowed, and through which devices?" before anyone writes a new rule.
- Cleanup needs traffic evidence. Unused and shadowed rule findings are only safe to act on when backed by hit counts or logs over a long enough period.
- Automation should start with design and verification. Automatic rule push is the last step, after the tool has proven it designs correct, minimal changes.
- The NSPM server is a tier 0 system. It holds credentials to read, and often write, every firewall you own, so its service accounts and API keys need the strongest protection.
Define requirements
- Estate inventory: firewall vendors and versions, central managers, routers and switches with access lists, load balancers, and cloud platforms (security groups, network ACLs, cloud firewalls), plus any Kubernetes clusters with network policies.
- Pain points: slow change turnaround, failed audits, rule base bloat, outages caused by changes, or no visibility of cloud rules edited outside change control.
- Compliance drivers: PCI DSS v4.0.1 (requirement 1.2.7 requires network security control configurations to be reviewed at least once every six months), internal segmentation policies, ISO/IEC 27001 audits, or sector rules.
- Change process: your ITSM platform, approval stages, emergency change rules and whether infrastructure as code already manages cloud rules.
- Segmentation intent: a written zone-to-zone policy (which zones may talk to which, on what services) that the tool can check every rule against.
- Write access appetite: read-only analysis, design with manual implementation, or automated implementation on selected devices.
Capability areas
| Area | What to look for |
|---|---|
| Device and cloud coverage | Native parsing for each firewall vendor and version you run, central managers, cloud security groups and network ACLs across all accounts and subscriptions, Kubernetes network policy where relevant |
| Rule analysis | Detection of shadowed, redundant, unused, overly permissive (any source, any service), expired and undocumented rules; object and group cleanup; rule recertification workflow with owners |
| Topology and path analysis | Automatic network model including routing and NAT; query whether a flow is permitted end to end and which rules allow it; what-if simulation of changes |
| Risk and compliance | Checks against your zone matrix and built-in standards; exposure of risky services (for example SSH on 22 and RDP on 3389 from the internet); correlation with vulnerability scan data; audit-ready reports with history |
| Change automation | Request intake from ITSM, check whether access already exists, design minimal rule changes on the right devices, risk check before approval, optional push via vendor APIs, post-change verification |
| Application connectivity | Map flows to business applications so changes, migrations and decommissions are handled per application, with automatic removal of rules when an application is retired |
| Change tracking | Detect every configuration change, including changes made outside the tool or in cloud consoles, and reconcile them with approved tickets |
| Integration and security of the tool | APIs, SIEM and ITSM integration, SSO and MFA for users, role-based access, vault integration for device credentials, least-privilege read-only collection accounts |
Cloud constructs behave differently from traditional firewalls, which is why native support matters. In a typical public cloud, for example, security groups are stateful, attach to resources rather than subnets and often carry a default rule allowing all outbound traffic, with stateless network ACLs recommended as an additional layer. A tool that treats them as just another access list will misreport exposure.
Evaluation criteria
| Criterion | What good looks like | How to test it | Suggested weight |
|---|---|---|---|
| Parsing accuracy and coverage | Every in-scope device and cloud account imported with no unsupported objects or misread NAT | Import real configurations; compare a sample of rules by hand | [25%] |
| Path analysis accuracy | Correct answers for flows that cross several devices, NAT and cloud boundaries | Query ten known flows, including two you know are blocked | [20%] |
| Cleanup quality | Findings backed by hit counts or logs, low false positive rate, safe disable-then-delete workflow | Review the top fifty "unused" rules with their owners | [15%] |
| Change automation | Minimal, correct designs; risk check against the zone matrix; verification after implementation | Run five real change requests end to end | [15%] |
| Compliance reporting | Reports that map to your audit requirements with history and evidence of review | Generate a PCI segmentation report and show it to your QSA or auditor | [10%] |
| Tool security | Vaulted credentials, read-only collection by default, MFA, full audit of user actions | Review how device credentials are stored and rotated | [10%] |
| Scalability and operations | Handles your rule count and change rate; manageable upgrades for new firmware versions | Ask for parser update times after new firewall releases | [5%] |
Weights in brackets are illustrative; an audit-driven buyer will weight reporting higher, a team drowning in change requests will weight automation higher.
Questions to ask vendors
- Which of our firewall models, versions and central managers do you parse natively today, and how quickly do you support new firmware releases?
- How do you model routing, NAT, VPN tunnels and cloud transit, and how do you show uncertainty when the model is incomplete?
- How long a hit count or log history do you need before marking a rule unused, and how do you handle seasonal traffic?
- Can you show a change request where the tool finds the access already exists and closes the ticket without a new rule?
- Which devices can you push changes to, how is each change verified, and how is it rolled back?
- How do you detect and flag cloud security group changes made outside the approved pipeline?
- How are device credentials stored, can collection run with read-only accounts, and do you integrate with our secrets vault?
- What does the tool log about its own users' actions, and can those logs go to our SIEM?
- How do you check rules against our zone-to-zone segmentation policy, and how is that policy maintained?
Red flags
- Parsing gaps for one of your main firewall platforms promised "on the roadmap".
- "Unused rule" reports with no traffic evidence behind them.
- Path analysis that ignores NAT or routing, or cannot cover cloud networks.
- Automated push offered before the tool has shown accurate designs on your estate.
- A single shared administrator account on every firewall, stored in the tool's database without a vault.
- Compliance reports that are point-in-time screenshots with no history or evidence of who reviewed what.
Proof of concept
- Prepare: choose a representative slice: two firewall vendors, one central manager, one cloud account and one segment in PCI scope; create read-only collection accounts and store them in your vault.
- Import and verify: import configurations and reconcile rule counts, objects and NAT against the source devices.
- Test path analysis: query known allowed and blocked flows across several hops and one cloud boundary.
- Test cleanup: generate shadowed, redundant and unused findings, review a sample with rule owners and compare with traffic logs.
- Test change workflow: pass five real requests from your ITSM through design, risk check and approval; implement manually or by push in a lab, then verify.
- Test drift detection: make an unapproved change on a firewall and in a cloud security group, and time the alert.
- Test reporting: produce a segmentation and six-monthly review report and ask your auditor whether it would be accepted as evidence.
- Score and clean up: score against the criteria, then remove collection accounts, API keys and test integrations.
After rollout, track total rule count and the share of rules with an owner and expiry date, median change lead time, changes that caused incidents, unapproved changes detected, and overly permissive rules remaining. The Firewall Rule Review Checklist gives the review steps the tool should support, and the Service Account Security Guide covers protecting the collection and push accounts.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Firewall Management Guide · Firewall Buyer's Guide · Firewall Rule Review Checklist · Next Generation Firewall RFP Template