Skip to main content
emnode
Sign up
Compliance Medium severity

AWS Security Hub · NetworkFirewall

NetworkFirewall.3: Policies should have >= 1 rule group

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub NetworkFirewall.3 check?

NetworkFirewall.3 checks the AWS::NetworkFirewall::FirewallPolicy resource and fails when a policy has zero stateless and zero stateful rule groups associated. The policy is the container; the rule groups are what actually inspect packets, so an empty policy enforces nothing.

Why does NetworkFirewall.3 matter?

The firewall sits in the traffic path and your architecture diagrams treat it as an enforcement point, but with no rule groups every packet just takes the default action. Lateral movement between VPCs, egress to known-bad domains, exfiltration over allowed ports: none of it is stopped. You are paying for an inspection point that inspects nothing while the diagram claims you are protected.

How do I fix NetworkFirewall.3?

  1. Create or reference at least one stateless or stateful rule group with real rules.
  2. Associate the rule group(s) with the firewall policy.
  3. Set a sensible default action and confirm the intended rules are being matched in the logs.

Remediation script · bash

# Attach the AWS Managed Rules common baseline to an empty web ACL, in Count mode.
# update-web-acl REPLACES the entire Rules array, so supply the full desired set and the current LockToken.
aws wafv2 update-web-acl \
  --scope REGIONAL --name public-alb-waf --id a1b2c3d4-0000-1111-2222-3333 \
  --lock-token e4f5g6h7 --default-action Allow={} \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=public-alb-waf \
  --rules '[{"Name":"AWS-CommonRuleSet","Priority":0,"Statement":{"ManagedRuleGroupStatement":{"VendorName":"AWS","Name":"AWSManagedRulesCommonRuleSet"}},"OverrideAction":{"Count":{}},"VisibilityConfig":{"SampledRequestsEnabled":true,"CloudWatchMetricsEnabled":true,"MetricName":"AWS-CommonRuleSet"}}]'

# Associate a baseline web ACL with an unprotected API Gateway stage (the resource ARN is the stage, not the API).
aws wafv2 associate-web-acl \
  --web-acl-arn arn:aws:wafv2:us-east-1:111122223333:regional/webacl/prod-api-baseline/1a2b3c4d \
  --resource-arn arn:aws:apigateway:us-east-1::/restapis/a1b2c3d4e5/stages/prod

# Protect a Network Firewall from accidental deletion.
aws network-firewall update-firewall-delete-protection \
  --firewall-name prod-egress-inspection --delete-protection

Full walkthrough (console steps, edge cases and verification) in the lesson Protect APIs and edge with WAF.

Is NetworkFirewall.3 a false positive?

A firewall policy can enforce a real posture using only its default actions, with zero rule groups attached, and that still fails this control because it checks specifically for at least one stateless or stateful rule group association. The textbook case is a deliberate default-deny guardrail policy whose stateless default action is aws:drop (or a baseline policy that forwards everything to a stateful engine that itself isn't populated yet during staged rollout): traffic is being handled exactly as intended, but no rule group is present. Before suppressing, sanity-check that the default action really is drop/forward and not aws:pass: an empty policy that passes by default is a genuine gap, not a false positive. If the default-only design is intentional, document it and set the finding to SUPPRESSED (manually or via a Security Hub automation rule keyed on ComplianceSecurityControlID and the policy's ResourceId) rather than attaching a placeholder rule group just to clear the check.

Full lesson Protect APIs and edge with WAF Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for NetworkFirewall controls ↗ Check your own account for NetworkFirewall.3 →
Part of the learning path Lock down access

More NetworkFirewall controls