CIS AWS Foundations v1.2 4.3: VPC default security groups should not allow inbound or outbound traffic

To meet the cis aws foundations v1.2 4.3: vpc default security groups should not allow inbound or outbound traffic requirement, you must ensure every VPC’s default security group has no inbound rules and no outbound rules, then prove it with recurring detection and remediation evidence across all AWS accounts and regions (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table).

Key takeaways:

• Default security groups must be “deny-all” for both ingress and egress; do not use them for workloads.
• You need continuous detection (Security Hub control EC2.2) plus a documented remediation path (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table).
• Evidence should show current state, change control, and periodic verification across accounts and regions.

CIS AWS Foundations v1.2 control 4.3 is simple in wording and easy to fail in practice: teams accidentally attach instances or ENIs to the default security group, or they leave permissive egress rules behind during build automation. The risk is not theoretical. The default security group exists in every VPC, it is familiar, and it often becomes the path of least resistance during incident response, debugging, or “just make it work” deployments.

Operationalizing this requirement means doing three things well: (1) remove all ingress and egress rules from each VPC default security group, (2) prevent drift by detecting and remediating any future changes, and (3) preserve evidence that you enforced the baseline consistently across your AWS footprint. AWS Security Hub maps this requirement to a measurable control (EC2.2), which makes ongoing monitoring and audit responses much easier if you set it up and keep it clean (AWS Security Hub CIS AWS Foundations mapping table).

This page gives requirement-level implementation guidance a CCO, Compliance Officer, or GRC lead can hand to a cloud owner and expect a predictable outcome, with artifacts that stand up in a security review (CIS AWS Foundations Benchmark).

Regulatory text

Excerpt (provided): “Implement CIS AWS Foundations Benchmark v1.2 requirement 4.3 as mapped in AWS Security Hub.” (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

What the operator must do: Configure each VPC’s default security group so it contains no rules that allow inbound traffic and no rules that allow outbound traffic, and monitor for any deviation using the AWS Security Hub mapping for CIS (AWS Security Hub CIS AWS Foundations mapping table). In practice, “no outbound” is the part teams miss because AWS commonly starts default groups with an allow-all egress rule.

Plain-English interpretation

• The default security group in a VPC should be an unused, deny-all “parking lot.”
• You should never rely on it as a functional security boundary for production workloads.
• If a resource is accidentally associated to it, it should not become reachable, and it should not be able to reach out to other networks by default.

Who it applies to (entity and operational context)

Applies to:

• Any organization operating workloads in AWS that wants alignment with CIS AWS Foundations v1.2 (CIS AWS Foundations Benchmark).
• Cloud security, platform engineering, and network teams that own VPC standards, account baselines, and guardrails.
• Compliance/GRC teams who must demonstrate baseline configuration control coverage across accounts and regions.

Operational contexts where this fails most often:

• New VPC creation via console or automation that doesn’t harden the default security group.
• Migrations where legacy templates assume permissive default egress.
• Incident debugging where engineers temporarily open rules in the default group and forget to revert.

What you actually need to do (step-by-step)

Step 1 — Inventory every VPC default security group (all accounts, all regions)

1. Enumerate AWS accounts in scope (prod, dev, sandbox, shared services).
2. For each region in each account, list VPCs and identify the default security group per VPC.
3. Create a tracking register with: Account, Region, VPC ID, Default SG ID, Owner, Current ingress rule count, Current egress rule count, Last modified date (if available from your tooling), and “Remediated Y/N”.

What auditors will look for: proof you didn’t only check one “main” account or one region.

Step 2 — Remove all inbound rules from each default security group

Action:

• Edit the default security group inbound rules to none.

Notes that matter operationally:

• Many environments already have empty inbound rules; don’t assume.
• If you find inbound rules, treat it as a control failure and open a ticket with root cause (template, manual change, break-glass).

Step 3 — Remove all outbound rules from each default security group

Action:

• Edit the default security group outbound rules to none.

Why this is the real control:

• Default egress is frequently permissive in practice; this is how “accidental association” becomes “accidental exfil path.”

Implementation caution:

• Confirm no workloads depend on being attached to the default security group for required egress. If they do, that is an architecture problem: move them to a purpose-built security group with documented rules and ownership.

Step 4 — Prevent future drift (detect + respond)

Set up continuous verification using the Security Hub CIS mapping:

1. Enable AWS Security Hub in each account and region in scope (or through centralized Security Hub administration where your org uses it).
2. Turn on the CIS AWS Foundations checks and verify the mapping for this requirement is reporting (AWS Security Hub CIS AWS Foundations mapping table).
3. Define an operational response:
   • Triage owner (cloud secops or platform team).
   • SLA expectations (your internal policy; don’t invent external numbers).
   • Remediation procedure (remove rules; investigate who/what changed it; prevent recurrence).

If your program uses ticketing:

• Auto-create a ticket when the check fails.
• Require linkage to a change request or documented break-glass approval.

Step 5 — Make default security group usage hard (guardrails)

This requirement is stronger when you also reduce the chance of attachment:

• Update golden templates (Terraform/CloudFormation) so workloads never reference the default security group.
• Add CI checks (infrastructure-as-code scanning) that flag references to the default security group ID.
• Require new security groups to have:
  • Named owner/team
  • Ticket or service association
  • Documented inbound and outbound intent

Step 6 — Periodic verification and executive reporting

For audit readiness:

• Run a recurring report that lists all default security groups and confirms zero ingress/egress rules.
• Keep a rolling evidence set (see next section).
• Report exceptions as time-bound with explicit owner and compensating controls.

Required evidence and artifacts to retain

Keep artifacts that prove design, implementation, and ongoing operation:

1. Policy / standard

   • Cloud network/security standard stating: “Default security groups must have no inbound or outbound rules and must not be used by workloads,” with scope and ownership (CIS AWS Foundations Benchmark).

2. Configuration evidence (point-in-time)

   • Exported configuration snapshots showing empty inbound and outbound rule sets for default security groups per VPC.
   • Screenshots are acceptable for small environments, but structured exports scale better.

3. Monitoring evidence

   • Security Hub evidence that the CIS check for this control is enabled and reporting (AWS Security Hub CIS AWS Foundations mapping table).
   • A sample of pass results and any fail findings with resolution notes.

4. Change management / incident trail

   • Tickets/PRs for remediation changes.
   • Break-glass approvals (if you allow temporary exceptions) plus documented rollback.

5. Exception register

   • If any default security group cannot be hardened temporarily, record: business justification, timeframe, compensating controls, and approval.

Common exam/audit questions and hangups (with operator-ready answers)

Auditor question	What they’re testing	What to show
“How do you know all VPCs are covered?”	Completeness across accounts/regions	Inventory register + Security Hub coverage evidence (AWS Security Hub CIS AWS Foundations mapping table)
“Can a default security group be used for production?”	Control intent vs. practice	Policy statement + IaC guardrails + evidence of non-use
“What happens if someone adds an egress rule?”	Ongoing monitoring	Security Hub finding workflow + a closed remediation ticket (AWS Security Hub CIS AWS Foundations mapping table)
“Do you have exceptions?”	Governance maturity	Exception register with approvals and expiry

Hangup to anticipate: Some teams interpret “no inbound” as enough. CIS 4.3 requires no inbound or outbound in the default security group (CIS AWS Foundations Benchmark).

Frequent implementation mistakes and how to avoid them

1. Fixing only the “default VPC” and missing custom VPCs

   • Avoid by using an account/region inventory and reconciling it to Security Hub reporting coverage (AWS Security Hub CIS AWS Foundations mapping table).

2. Leaving the allow-all egress rule in place

   • Avoid by explicitly checking outbound rules in your runbook and evidence templates.

3. Hardening the default SG, then attaching workloads to it anyway

   • Avoid by enforcing IaC guardrails: no default SG IDs in templates, and require explicit security groups per workload.

4. No owner for failures

   • Avoid by assigning a named resolver group and creating an operational procedure for Security Hub findings (AWS Security Hub CIS AWS Foundations mapping table).

5. Treating Security Hub as proof without validating configuration

   • Avoid by keeping a configuration export/snapshot as independent evidence alongside Security Hub results.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific CIS control, so you should frame risk in operational terms, not penalty terms.

Risk implications to communicate internally:

• A permissive default security group increases blast radius for misconfigurations. If an engineer attaches a workload to the default group (intentionally or accidentally), the default rule set can become an unintended access path.
• Allow-all egress on the default group can create an unreviewed outbound channel for systems that should have constrained egress (for example, only to required AWS services or internal destinations).

For a CCO/GRC lead: the audit risk is straightforward. If you cannot show coverage across accounts/regions and a repeatable verification loop, you will struggle to demonstrate that the baseline is operating, even if some VPCs are configured correctly (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table).

Practical 30/60/90-day execution plan

First 30 days (Immediate baseline + visibility)

• Establish scope: which AWS accounts and regions are in your compliance boundary.
• Build the VPC/default security group inventory and identify all noncompliant default groups.
• Remediate: remove all inbound and outbound rules from each default security group.
• Turn on Security Hub CIS reporting for the environment and validate the mapped check visibility (AWS Security Hub CIS AWS Foundations mapping table).

Deliverables:

• Inventory register, remediation tickets/PRs, and an initial evidence export.

Next 60 days (Guardrails + workflow)

• Update IaC templates to prevent default security group usage.
• Add CI checks to flag default SG references and permissive rules where applicable.
• Define Security Hub finding handling: triage owner, response steps, and evidence retention rules.
• Stand up exception handling with approvals and expirations.

Deliverables:

• Written standard, runbook, and a working “finding-to-ticket-to-remediation” loop.

By 90 days (Operational maturity + audit-ready pack)

• Demonstrate repeatable verification with periodic exports and Security Hub reports (AWS Security Hub CIS AWS Foundations mapping table).
• Run a tabletop for “default SG drift” (someone adds rules; someone attaches a workload) and prove you can detect and remediate.
• Create a single audit packet: policy, inventory, current state evidence, and samples of closed findings/tickets.

Where Daydream fits cleanly: use Daydream to map CIS 4.3 to your internal controls, assign owners, track evidence (inventory exports, Security Hub artifacts, remediation tickets), and schedule periodic verification so the control doesn’t degrade between audits (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table).

Frequently Asked Questions

Do we need to delete the default security group?

No. You generally can’t delete the VPC default security group, and the requirement does not ask you to. You harden it by removing all inbound and outbound rules and preventing workload reliance on it (CIS AWS Foundations Benchmark).

Will removing outbound rules break things?

Only if a workload is attached to the default security group and depends on its egress. The fix is to move that workload to a dedicated security group with reviewed outbound rules and clear ownership.

Is “no inbound rules” enough to pass CIS 4.3?

No. CIS 4.3 is explicit that default security groups should not allow inbound or outbound traffic (CIS AWS Foundations Benchmark). You must remove egress rules too.

How do we prove this across multiple AWS accounts?

Keep an inventory of VPCs and default security groups across accounts/regions plus Security Hub CIS check reporting for the same scope (AWS Security Hub CIS AWS Foundations mapping table). Auditors want completeness and an operating verification loop.

What does AWS Security Hub check for this requirement?

AWS Security Hub maps CIS AWS Foundations v1.2 requirement 4.3 to a specific control in its CIS benchmark coverage (AWS Security Hub CIS AWS Foundations mapping table). Use that control’s findings as monitoring evidence, backed by configuration exports.

Can we allow temporary rules in the default security group for break-glass?

If you do, treat it as a time-bound exception with explicit approval, documented rollback, and retained evidence. Your default stance should remain “deny-all,” with non-default security groups used for emergency access patterns.