You've configured a firewall rule to block malicious traffic. You document it, screenshot the configuration, and present it to your auditor. Control implemented, evidence collected, finding closed. Right? Not quite.
The Real Requirement
A configured rule isn't the same as a functioning control. Your auditor needs evidence that the control operates effectively throughout the audit period. ISO/IEC 27001:2022 Annex A Control 8.20 requires you to "manage and control networks" to protect information. SOC 2 CC6.6 expects "logical access security measures" to protect against external threats. Both frameworks demand functioning controls, not just their existence.
The gap: a firewall rule that never matches traffic provides no protection. It's a policy statement, not a control. If the rule is dormant for six months, you can't claim it protected anything during your audit period. Yet many teams present rule configurations as evidence without proof the rules actually fired.
AWS Network Firewall's rule hit count feature highlights this gap. It tracks how often each stateful rule matches network traffic, incrementing only when a rule match results in an alert log. Rules configured with alert, drop, or reject actions automatically generate these logs. Pass rules require the alert keyword to appear in hit counts. The firewall now tells you which rules are working.
Gathering Evidence
Rule hit counts are included with Network Firewall at no extra cost, though standard charges apply for storing and querying log data. The feature is available in all AWS Regions where AWS Network Firewall is supported, except Middle East (UAE) and Middle East (Bahrain).
The metadata appears in each alert log automatically:
"aws_metadata": {
"resource_arn": "arn:aws:network-firewall:us-east-1:123456789012:stateful-rulegroup/StatefulRuleGroup"
}
You can query this data in CloudWatch Logs Insights or Amazon Athena, or review it directly in the firewall monitoring dashboard. The dashboard shows hit counts per rule, including the signature ID, description from the msg field in your Suricata rule, and last occurrence timestamp.
Consider these audit scenarios:
Scenario one: Rules with zero hits. If your rule doesn't appear in the hit count metric during your audit period, it didn't match any traffic. You can't claim it provided protection. An auditor will ask why the rule exists if it's never triggered. You'll need to demonstrate that the rule is correctly positioned but the threat hasn't materialized, or acknowledge that the rule is misconfigured or redundant.
Scenario two: Rules with recent hits. A rule blocking traffic to known command-and-control domains shows activity during your audit period with specific timestamps. You have timestamped evidence that the control operated, satisfying the "operating effectiveness" requirement for both SOC 2 and ISO/IEC 27001.
Scenario three: Pass rules without the alert keyword. These rules don't generate alert logs by default, so they won't appear in hit count metrics. If you're using pass rules as part of your network segmentation strategy, add the alert keyword to generate logs that prove the rule is matching traffic. Without this, you have no evidence the rule is functioning.
What to Do Instead
Treat firewall rules as controls that require operating effectiveness evidence, not just design documentation.
For SOC 2 Type II engagements, your auditor will test controls over a period (typically three to twelve months). If you're citing network firewall rules as part of CC6.6 or CC6.7 (system monitoring), you need evidence those rules operated throughout the period. Rule hit counts provide this. Query your logs for the audit period, extract hit counts per rule, and document which rules matched traffic and when. Rules with zero hits need an explanation -- either the threat didn't occur (document your risk assessment), or the rule is positioned incorrectly (fix it before the audit).
For ISO/IEC 27001 surveillance or recertification audits, your lead auditor will sample controls to verify they're operating as documented. If you've claimed network segmentation controls under Annex A 8.20 or threat protection under 8.16 (Monitoring activities), you'll need to demonstrate that your firewall rules are actively enforcing those boundaries. Rule hit counts give you per-rule evidence with timestamps. A rule that blocked lateral movement attempts last month is evidence; a rule that's never fired is a gap.
For PCI DSS 4.0, Requirement 1.2.7 expects you to review firewall and router rule sets at least every six months. The requirement doesn't just say "review the configuration" -- it expects you to confirm the rules are necessary and effective. Rule hit counts let you identify dormant rules systematically. If a rule hasn't matched traffic in six months, you need to justify keeping it or remove it. This isn't optional; it's a defined control activity.
Configure your pass rules with the alert keyword if they're part of your control environment. A pass rule that allows specific application traffic as part of your network segmentation design needs to appear in your hit count data. Otherwise, you can't prove it's working.
Set a review cadence. Query your rule hit counts monthly or quarterly, depending on your compliance obligations. Document rules with zero hits and either remediate or justify them. This becomes part of your ongoing control monitoring, not a scramble before the audit.
When Documentation Still Matters
Configuration documentation still matters. Your auditor needs to see your firewall policy, understand your rule logic, and verify that your rules align with your risk treatment plan. Rule hit counts don't replace design documentation -- they supplement it with operating effectiveness evidence.
If you're operating in an environment where certain threats are rare, a rule with zero hits might still be appropriate. A rule blocking traffic to a specific malware distribution network might never fire if your environment isn't targeted by that campaign. Document your risk assessment, explain why the rule exists despite low hit counts, and demonstrate that you've reviewed it as part of your regular control monitoring. That's defensible.
But don't confuse a configured rule with a tested control. Evidence means proof of operation, not proof of intent.
