Alibaba Cloud
AWS
Google Cloud
Microsoft AzureOverview
Firewalls/security groups allowing all traffic from the internet increase the attack surface of your cloud estate. When these are used to control the traffic to compute resources (most commonly VMs), attackers might be able to take advantage of various vulnerabilities present on these resources to infiltrate into the cloud environment. Then, if the compute resource has permissions to access data stores or other resources, the attacker might move laterally through the environment or access potentially sensitive data.
Remediation guidance
AWS:
- For S3 buckets or DynamoDB, remove the permission from the IAM Role attached to the compute resource, which grants access to the data stores.
- For SQL DB instances, ensure that the DB is not part of the same security group as the compute resources, separating their network access.
GCP:
- For BigQuery and Buckets, modify the data store's access policy to remove the compute resource's access, revoking any permissions granted.
Azure:
- Remove the managed identity assigned to the compute resource, which grants access to the data store. This ensures that the compute resource no longer has the ability to connect to the data store.
Service-wide remediation
Recommended when many resources are affected: fix the platform baseline first so new resources inherit the secure setting, then remediate the existing flagged resources in batches.
AWS
Use AWS Organizations guardrails, AWS Config rules or conformance packs where they fit, approved account baselines, and IaC modules so new resources inherit the secure setting.
Azure
Use management group or subscription Azure Policy assignments, remediation tasks where supported, landing-zone standards, and IaC modules so drift is prevented at scale.
Alibaba Cloud
Use Resource Directory guardrails, account baselines, and IaC modules so the secure setting is applied consistently across environments.
Google Cloud
Use organization or folder policies where available, shared project templates, logs and alerting baselines, and IaC modules so new resources inherit the secure setting.
Operational rollout
- Fix the baseline first at the account, subscription, project, cluster, or tenant scope that owns this control.
- Remediate the currently affected resources in batches, starting with internet-exposed and production assets.
- Re-scan and track approved exceptions with an owner and expiry date.
Query logic
These are the stored checks tied to this control.
Security Groups allowing public connections
Connectors
Covered asset types
Expected check: eq []
{
securityGroups(where: {
rules_SOME: {
direction: "Inbound",
action: "Allow",
OR: [
{sources_INCLUDES: "cidr:0.0.0.0/0"},
{sources_INCLUDES: "cidr:::/0"},
{sources_INCLUDES: "tag:Internet"},
{sources: []}
]
}
}) {
...AssetFragment
}
}Firewalls allowing internet traffic
Connectors
Covered asset types
Expected check: eq []
{
firewalls(
where: {
rules_SOME: {
direction: "Inbound"
OR: [
{ sources_INCLUDES: "cidr:0.0.0.0/0" }
{ sources_INCLUDES: "cidr:::/0" }
]
}
}
) {
...AssetFragment
}
}
