A PCI Firewall Policy That Allows Everything and Logs Nothing

1. The deny rule never runs. DFW evaluates rules top-down and stops at the first match. Rule 5000 with Source = Any and Service = Any matches essentially every flow to the db group, so evaluation never reaches 6000. The deny rule is not weak or mis-scoped - it is unreachable.

2. The database is reachable from everywhere for the same reason. Source = Any plus Service = Any is a wide-open permit to the db group. It was probably a proof-of-concept rule that was never tightened. The re-IP to 10.20.41.0/24 did not break it because the rule is tag-based, not IP-based: the moved VMs kept the db tag and stayed in the destination group.

3. No denies are logged because no rule is logging. Log = off on rule 5000, so permitted traffic is invisible. Rule 6000 never matches, so it logs nothing. The default rule carries the drop behaviour but does not log unless explicitly enabled. A quiet log is evidence of missing logging configuration, not evidence that nothing is being denied.

A hidden fourth problem: the db tag on two web VMs means the destination group is wrong. Any future corrected rule of the form app -> db will silently permit those two web VMs to reach the database, which is itself an audit finding.

Design the policy around the default drop, not around an explicit deny.

• Order 100: Allow, Source = group app-tier, Destination = group db-tier, Service = TCP 5432, Applied To = PCI-VMs, Log = on.
• Order 200: nothing else for intra-zone traffic. The default rule handles the deny.
• Default rule: DFW Default Layer3 Rule, action Drop, Log = on. This is the audit evidence for default-deny; enabling logging here is usually the single change that satisfies the auditor.

Remove rule 5000 entirely. Editing it in place to be correct is acceptable, but the wide-open version is safer deleted than inverted, because an editing mistake leaves a permit in place.

Scoping. Applied To = PCI-VMs means enforcement happens at the vNIC of each in-scope VM. Traffic between two in-scope VMs is evaluated at both the source and destination vNIC. Traffic from a VM outside the group to an in-scope VM is only evaluated at the destination vNIC, so the destination group must be precise - which is why the tag problem matters.

Expect stale successes. The firewall is stateful; sessions established under the old rule keep their verdict until they time out. Test with fresh connections, and expect some applications to keep working for a while after enforcement begins.

Fix the group membership first, before tightening any rule.

• Open the db-tier group and inspect both the configured criteria and the effective member list, including resolved IPs per member. The effective-member view is what the firewall actually uses; the criteria view alone will not show the two web VMs.
• Remove the db tag from the two web VMs, then re-check effective membership and the security-group IP mapping before moving on.
• Verify that all 12 relocated database VMs on 10.20.41.0/24 are present in the group. Tag-based groups survive a re-IP automatically; this is the one advantage they have over IP-set groups, which would have silently dropped the moved VMs out of scope and produced a mysterious "database unreachable after re-IP" ticket instead.

Prevent recurrence:

• Define tag vocabulary with a single owner per tag. Shared, free-form tagging is how a web VM becomes a database.
• Prefer groups whose criteria combine a tag and a segment or VM name pattern, so a single bad tag cannot pull an unrelated VM into a PCI rule.
• Add a pre-change check that re-validates effective group membership for every PCI group, and re-run it after any re-IP, migration, or tagging exercise.
• Log the group membership review - the auditor will ask for it.