Security groups & firewall rules
Security groups and firewall rules are the most frequently edited network control in any cloud estate — nearly every new service, deploy, and debugging session adds or widens one — and that constant churn is exactly why they drift open. They look deceptively simple (a source, a port, a protocol), but their real behavior depends on statefulness, rule ordering and priority, group-to-group references, IPv4/IPv6 parity, and how they interact with subnet-level ACLs. A single overly broad line — 0.0.0.0/0 to all ports, or a rule that trusts the default group — can quietly undo the segmentation the rest of the network was designed to enforce. This page covers how we assess the effective, combined rule set, not just individual lines, across every account, subscription, project, and region in scope.
Overview
What this check looks like in practice
Security groups and firewall rules are the primary gatekeepers of cloud traffic, and they drift toward permissive over time as teams open ranges to unblock work and forget to close them. Broad source ranges, whole-port openings, and rules that reference other broad groups quietly widen what is reachable. We review every ingress and egress rule for how far it opens and whether that width is justified by an actual workload.
Why it matters
To an attacker, an open security group is the cheapest possible foothold: internet-wide scanners find a newly opened admin or database port within minutes of it going live, and a group that trusts a broad source turns one compromised host into reach across an entire tier. To an auditor, the security-group configuration is direct, sampleable evidence for PCI-DSS firewall and segmentation requirements, CIS networking benchmarks, and ISO 27001 network controls — a wide-open rule is a finding on its own. The danger compounds because rules accrete rather than get cleaned up: nobody removes the "temporary" range, duplicate and shadowed rules make the effective policy impossible to reason about by eye, and IPv6 rules are routinely left open when their IPv4 twins get tightened. Reviewing the effective combined policy — rather than trusting that each line looked reasonable the day it was added — is the only reliable way to know what is actually reachable.
What we assess
What we look for
- Ingress rules that allow 0.0.0.0/0 or ::/0 to sensitive management and data ports — SSH (22), RDP (3389), database engines (3306, 5432, 1433, 27017), and remote-management or orchestration endpoints — where the source has no business being public.
- Default security groups (AWS), default NSG behavior (Azure), and the legacy default VPC network with its default-allow-ssh/rdp/internal rules (GCP) left permissive or still attached to production workloads.
- Group-to-group and all-ports trust: security groups that reference another group (or an over-broad application security group, network tag, or service account) across the full port range instead of the specific listening port.
- IPv4/IPv6 parity gaps — an IPv6 (::/0) rule left wide open after its IPv4 twin was tightened, or a rule that only restricts one address family.
- Over-broad abstractions: Azure service tags such as Internet or VirtualNetwork used where a narrower scope applies, and GCP target/source tags or service accounts that grant more reach than the workload needs.
- Duplicate, shadowed, and unused rules, plus the interaction between stateful groups and stateless subnet ACLs — a tight security group undone by a permissive network ACL, or an ACL deny overridden by rule ordering/priority.
- Missing NSGs on sensitive subnets, and absent preventive/detective guardrails (AWS Config or Firewall Manager rules, Azure Policy on management ports, GCP hierarchical firewall policies and firewall rules logging) that would catch a newly opened over-broad rule.
- Rules lacking a description or owner tag, and drift between the live configuration and the infrastructure-as-code that is supposed to define it.
Across your clouds
AWS, Azure & Google Cloud
AWS
AWS uses stateful security groups (allow-only, evaluated per elastic network interface, referenceable by security-group ID) layered over stateless, ordered network ACLs at the subnet level that require explicit ephemeral return-port rules. We review both, flag default security groups left permissive or attached to production, and check for detective/preventive coverage via AWS Config managed rules (restricted-ssh, vpc-sg-open-only-to-authorized-ports), VPC Reachability Analyzer, and Firewall Manager or SCP guardrails.
Azure
Azure network security groups are stateful and priority-ordered (numeric rules from 100 upward with default rules that AllowVnetInBound and AllowInternetOutbound), and are best scoped with application security groups and service tags (Internet, VirtualNetwork, AzureLoadBalancer) rather than raw CIDRs. We check for high-priority AllowAny/0.0.0.0/0 rules, overly broad service-tag use, NSGs missing on sensitive subnets, and whether Azure Policy enforces restrictions on management ports.
Google Cloud
Google Cloud VPC firewall rules are stateful with explicit allow/deny actions and numeric priority (0-65535), sitting on top of the implied allow-egress and deny-ingress rules — and the legacy default network ships permissive default-allow-ssh, default-allow-rdp, and default-allow-internal rules. We review targets and sources expressed as network tags or service accounts, flag broad 0.0.0.0/0 allows and default-network exposure, and check for hierarchical firewall policies at the org/folder level plus firewall rules logging.
Example finding
Production database security group trusts the default security group on all ports
Risk: The default security group is attached to many unrelated instances across the VPC, so this single all-ports rule effectively lets any workload in the network reach the database on every port. One compromised web, batch, or utility host reaches straight into the data tier with no further barrier, and the rule's breadth hides which service legitimately needs the access — collapsing the segmentation the rest of the architecture assumes.
Fix: Replace the group-to-group all-ports allow with a rule scoped to the specific application security group on only the database's listening port; remove the default security group from production interfaces and leave it with no rules. Codify the tightened rule in infrastructure-as-code and add a Config/Policy check that flags all-port openings and default-group references so the pattern cannot recur.
Remediation
How to close it
- 1 Inventory every security group, NSG, firewall rule, and network ACL across all in-scope accounts, subscriptions, and projects, and export the effective rules so the review is of combined reachability, not individual lines.
- 2 Rank exposure by real risk: internet-facing admin and data ports (0.0.0.0/0 or ::/0) first, then broad group-to-group or default-group trust, then wide port ranges on internal rules.
- 3 Replace broad CIDR sources with scoped ones — reference security groups, application security groups, network tags, or service accounts, or specific CIDRs — and narrow every port range to the exact ports the workload uses, applying the same restriction to the IPv6 rule.
- 4 Strip permissive rules from default groups and default networks, stop attaching them to production, and give every remaining rule a description and an owner tag so its purpose is auditable.
- 5 Codify the tightened rule set in infrastructure-as-code, reconcile it against the live configuration, and eliminate out-of-band console drift so the repository is the single source of truth.
- 6 Add preventive and detective guardrails — Firewall Manager or SCPs, hierarchical firewall policies, or Azure Policy, plus Config rules or flow-log alerting — so a newly opened over-broad rule is blocked or surfaced immediately.
Questions
Do you check network ACLs too, or only security groups?
Both. Security groups (AWS SGs, Azure NSGs, GCP VPC firewall rules) are stateful and evaluated per instance or interface, while network ACLs are stateless subnet-level filters that evaluate in order, mix allow and deny, and need explicit return-traffic rules. Misconfigurations often hide in the interaction — a tight security group undone by a permissive ACL, or an ACL deny silently overridden by rule ordering — so we assess both layers and the effective combined result.
We have hundreds of rules across many accounts — can this be done without agents or scanning?
Yes. Rules and their memberships are readable through the provider APIs (describe security groups, NSG rules, firewall rules, and ACLs), so we evaluate the effective policy read-only across every account, subscription, and project. Nothing is installed, no traffic is sent, and nothing in production is changed.
How do you tell a legitimately broad rule from a dangerous one?
We correlate each rule with the workload behind it: the ports the service actually listens on, whether the source genuinely needs to be public, and whether an owner or description justifies it. A load-balancer health-check port open to the provider's own range is fine; a database port open to 0.0.0.0/0, or an all-ports group-to-group trust, is not. The finding is the gap between what a rule permits and what the workload requires.
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
