AWS Security Group Review
Audit all security groups for overly permissive rules (0.0.0.0/0), unused groups, and cross-account access.
Tested against aws-cli 2.x · cursor-0.45+ · windsurf-1.6+
You are an AWS network security engineer. Your task is to audit every security group for overly permissive rules, stale groups, and cross-account exposure. Context: - You have read-only access to list and describe security groups and network interfaces. - This is a review; you will not modify security groups. Steps: 1. List all security groups: aws ec2 describe-security-groups and note group IDs, VPCs, and descriptions. 2. For each, inspect ingress and egress rules: aws ec2 describe-security-groups --group-ids <id> and read CidrIp values. 3. Flag any rule with CidrIp "0.0.0.0/0" or "::/0" on ports 22, 3389, 5432, 3306, 6379, or high-risk admin ports. 4. Detect unused groups: cross-reference group references from aws ec2 describe-network-interfaces and aws ec2 describe-instances; a group with no ENI is orphaned. 5. Check cross-account references (UserIdGroupPairs) and flag those not in an allowlist of trusted accounts. Output format: - Table: group id, vpc, open ports, 0.0.0.0/0 present, referenced?, verdict. - A remediation list: which groups to tighten and which to delete. Constraints: - Read-only; never authorise/revoke rules. - Do not recommend deleting a group that is actively referenced. - Only flag ports on public ranges; internal trusted CIDRs are acceptable. Example: Input: sg-1a2b3c allows 0.0.0.0/0 on 22, and is attached to one bastion ENI. Output: sg-1a2b3c, 22 open to world (high), referenced (1 ENI); suggest restricting port 22 to the admin CIDR and leaving the group in place.
Why this directive matters
Security groups are the front door of AWS networking, and a single open rule is all an attacker needs. The most common findings are almost embarrassingly easy to see once you look: port 22 or 5432 open to 0.0.0.0/0, groups left behind after an instance is deleted, and cross-account references nobody remembers adding. The catch is that a ten-thousand-rule account is too big to eyeball, which is exactly where this directive earns its keep. It has the agent enumerate every group, read the ingress and egress, and flag public CIDRs on high-value ports, then it checks whether each group is still attached to a network interface before suggesting deletion. That last step matters, because deleting a detached group is fine while deleting a referenced one breaks traffic. The output is a compact verdict table and a short remediation list, safe to run whenever the network surface needs a quick audit.
Test Command
aws ec2 describe-security-groups --query 'SecurityGroups[?IpPermissions[??IpRanges[?CidrIp==\"0.0.0.0/0\"]].{Id:GroupId,Name:GroupName}]'Prerequisites
- AWS CLI with ec2:Describe* access
- Region or all-region scope
- Read access ok
Expected Outputs
- Security group verdict table
- Open port findings
- Refresh/delete suggestions
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This beginner directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.