CIS AWS Foundations v1.2 4.2: Security groups should not allow ingress from 0.0.0.0/0 or ::/0 to port 3389

To meet cis aws foundations v1.2 4.2: security groups should not allow ingress from 0.0.0.0/0 or ::/0 to port 3389 requirement, you must prevent any AWS Security Group rule that exposes RDP (TCP/3389) to the public internet over IPv4 (0.0.0.0/0) or IPv6 (::/0). Operationally, this means inventorying security groups, removing or narrowing offending rules, and enforcing preventive guardrails plus continuous detection ¹. ²

Key takeaways:

• Block public RDP by eliminating TCP/3389 ingress from 0.0.0.0/0 and ::/0 in all security groups. ³
• Replace direct RDP exposure with controlled access paths (VPN, bastion, SSM Session Manager) and least-privilege CIDRs. ³
• Keep evidence that proves both point-in-time compliance and ongoing monitoring via Security Hub findings and rule change logs. ²

This requirement targets a common, high-impact misconfiguration: exposing Windows Remote Desktop Protocol to the public internet. CIS AWS Foundations v1.2 control 4.2 is narrowly scoped and easy to test: a security group is noncompliant if it allows inbound traffic to port 3389 from 0.0.0.0/0 (any IPv4 address) or ::/0 (any IPv6 address). ³

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalize this is to treat it as a simple rule with clear exceptions: public RDP is not allowed; administrative access must be restricted to known networks or moved to a brokered/admin channel that is not open to the world. AWS Security Hub provides a mapped control for this benchmark item (EC2.14), which you can use for detection, reporting, and evidence collection across accounts and regions. ²

Your job is to make sure the engineering team can: (1) find every violating rule quickly, (2) remediate safely without breaking production, (3) prevent reintroduction through guardrails, and (4) retain artifacts that an auditor can re-check without re-running your investigation.

Requirement name (for your control matrix)

cis aws foundations v1.2 4.2: security groups should not allow ingress from 0.0.0.0/0 or ::/0 to port 3389 requirement

Mapped detection in AWS: AWS Security Hub CIS control EC2.14. ²

Regulatory text

Excerpt (provided): “Implement CIS AWS Foundations Benchmark v1.2 requirement 4.2 as mapped in AWS Security Hub.” ^{3 2}

Operator interpretation: You must implement the CIS benchmark expectation that no security group in scope allows inbound TCP/3389 from anywhere (0.0.0.0/0 or ::/0). Because the excerpt explicitly references the AWS Security Hub mapping, you should run and retain the Security Hub control results (EC2.14) as your primary, repeatable verification mechanism, then back it with configuration evidence (security group rules, change history, and exceptions). ²

Plain-English interpretation

• What’s prohibited: Any security group ingress rule that permits RDP on port 3389 from the entire internet (IPv4 or IPv6). ³
• What’s allowed: RDP access that is restricted to a narrow, justified source (for example, corporate VPN egress IP ranges) or replaced with safer administrative access patterns that do not require public inbound 3389. ³
• What auditors expect: You can prove you have (a) removed existing exposures, (b) a process/guardrail to stop recurrence, and (c) monitoring that detects drift. ²

Who it applies to

Entity scope

• Any organization operating workloads in AWS that claims alignment to CIS AWS Foundations Benchmark v1.2, or uses AWS Security Hub CIS mappings as a baseline. ^{3 2}

Operational scope

• All AWS accounts and regions where EC2 security groups exist (including shared services, sandbox, and legacy accounts).
• Any team that can create or modify security groups: infrastructure, platform, DevOps/SRE, application teams, and managed service providers/third parties with delegated access.

Asset scope

• EC2 instances and ENIs behind security groups, including bastions, domain controllers, jump hosts, and “temporary” troubleshooting instances.

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

1) Decide the approved admin access pattern (so remediation is consistent)

Pick one standard for Windows administration and write it down in an internal control note:

• Preferred: Remove inbound RDP entirely and administer via AWS-managed channels (common pattern: SSM Session Manager) or through a tightly controlled bastion behind VPN.
• Acceptable (with constraints): Allow RDP only from explicitly approved IP ranges (corporate VPN egress, dedicated admin network), never from 0.0.0.0/0 or ::/0. ³

Your approval decision becomes your “policy” for engineers and your audit narrative.

2) Inventory all security groups and identify violations

Use Security Hub as the primary detection surface for CIS 4.2 because the requirement is explicitly mapped there. Capture the list of failed findings for EC2.14 across accounts. ²

Also run an independent config query for defensibility and to catch any visibility gaps:

• Query security group ingress rules where:
  • protocol = TCP (or all)
  • from_port <= 3389 and to_port >= 3389 (or explicitly 3389)
  • cidr_ipv4 = 0.0.0.0/0 OR cidr_ipv6 = ::/0

3) Triage each finding to avoid downtime

For each violating security group:

• Identify attached resources (instances/ENIs, load balancers, etc.).
• Determine whether RDP is actually required, and by whom.
• Check if the rule is “temporary” but forgotten; these are common. Document the owner and ticket the remediation.

A practical triage rubric:

• High urgency: Internet-facing RDP to production instances (especially bastions or directory services).
• Medium urgency: Non-production with public RDP.
• Low urgency: No attached resources (or obsolete groups), but still fix to reduce noise and prevent future attachment.

4) Remediate safely: remove or narrow the ingress rule

Remediation options, in preferred order:

1. Remove the 3389 public rule entirely if administration can be done without inbound RDP. ³
2. Restrict the source from 0.0.0.0/0 and ::/0 to a tight CIDR list that reflects approved admin egress (for example, VPN NAT IPs).
3. Time-box exceptions only if you have a documented business need and a compensating control (for example, temporary incident response). Track them with an owner, expiry, and revalidation.

Implementation notes that reduce operational risk:

• Stage changes in lower environments first if the same security group pattern is reused.
• If a security group is shared across many instances, consider cloning it and migrating attachments to avoid unexpected access loss.

5) Put preventive guardrails in place (so the finding doesn’t come back)

Auditors care about recurrence. Build at least one preventive control and one detective control.

Detective (minimum):

• Keep Security Hub enabled for CIS controls and route findings to your ticketing/alerting workflow for EC2.14 failures. ²

Preventive (recommended):

• Add an IAM/SCP guardrail that denies AuthorizeSecurityGroupIngress when the request includes:
  • port 3389, and
  • CIDR 0.0.0.0/0 or ::/0
• Add IaC policy checks (for example, CI checks on Terraform/CloudFormation) to block merges that introduce public RDP.

Even if your org is not ready for a hard deny, start with a “warn and require approval” workflow, then tighten.

6) Validate and document closure

• Re-run Security Hub control evaluation and confirm EC2.14 returns to passing for the affected resources. Retain the updated findings export or screenshots and the remediation tickets. ²
• Maintain an exception register for any approved deviations with expiry.

Required evidence and artifacts to retain

Keep evidence that answers: “Was public RDP prevented, and how do you know it stays prevented?”

Minimum evidence pack:

• Security Hub: CIS benchmark enabled status and EC2.14 control results (pass/fail history, affected resources). ²
• Configuration snapshots: before/after security group rule exports for remediated groups (rule listing with CIDRs and ports).
• Change records: tickets/PRs/Change Requests approving the rule removal/restriction; include owner and date.
• Exception register (if any): scope, justification, compensating control, approver, and expiry.
• Guardrail proof: SCP/IAM policy text or CI policy output showing blocks for public 3389.

Practical tip: store these artifacts in a dedicated “Cloud Baseline / CIS Evidence” folder per audit period, indexed by control (4.2 / EC2.14).

Common exam/audit questions and hangups

• “Show me how you detect public RDP exposure.” Provide Security Hub EC2.14 outputs and your alert/ticket workflow. ²
• “Does this cover IPv6 too?” Yes; auditors may explicitly ask about ::/0. Your query and guardrails must include it. ³
• “How do you prevent engineers from re-adding the rule?” Show the preventive control (SCP/IAM/IaC checks) plus periodic review. ³
• “Are there any exceptions?” If yes, show a controlled exception process with expiry and compensating controls.

Hangup you will see: teams confuse “security groups on private subnets” with “safe.” CIS 4.2 still evaluates the rule itself; misrouting, future changes, or peering can expose the service later.

Frequent implementation mistakes (and how to avoid them)

1. Fixing only IPv4 and forgetting IPv6. Block 0.0.0.0/0 and ::/0 consistently in detection and prevention. ³
2. Relying on “temporary” rules. Enforce expiry for any exception; no expiry means permanent exposure.
3. Remediating in console without updating IaC. The rule returns on the next deployment. Require IaC as the source of truth or reconcile immediately.
4. Breaking admin access with no backout plan. Confirm alternative access (VPN/SSM/bastion) works before cutting over, and schedule changes during controlled windows.
5. Leaving unused security groups unmanaged. Delete or quarantine them; they become “compliance debt” and can be attached later.

Enforcement context and risk implications

No public enforcement cases were provided in the approved source catalog for this requirement, so treat this as a benchmark-alignment and security exposure issue rather than a claim about regulator actions.

Risk is still concrete:

• Public RDP increases the attack surface for password spraying, credential stuffing, and exploitation of unpatched services.
• An exposed bastion or admin host can become a stepping stone to internal systems.

From a governance standpoint, repeated EC2.14 failures usually indicate weak change control around network access, and that becomes an audit narrative problem even when there is no incident. ²

Practical execution plan (30/60/90-day)

You asked for speed; use phases rather than time-bound promises.

First 30 days (Immediate containment)

• Turn on or confirm Security Hub CIS benchmark visibility and begin tracking EC2.14 findings centrally. ²
• Inventory all violating security groups, identify owners, and open remediation tickets.
• Remediate the highest-risk exposures first (internet-facing production/admin hosts).
• Stand up an exception register for truly unavoidable cases.

Next 60 days (Standardize and prevent recurrence)

• Publish an internal standard for Windows admin access (no public RDP; approved alternatives and allowed CIDRs). ³
• Implement preventive guardrails (SCP/IAM/IaC checks) to block creation of 0.0.0.0/0 or ::/0 inbound 3389.
• Add automated ticket creation from Security Hub EC2.14 findings and define SLAs by environment tier.

By 90 days (Operationalize as “business as usual”)

• Establish periodic evidence capture for audits (Security Hub exports, config snapshots, exception review).
• Reduce residual noise: delete unused security groups; fix IaC drift.
• Run a tabletop: “Engineer tries to add public RDP” and confirm it is blocked, alerted, and documented.

If you use Daydream to manage requirement-level evidence, map CIS 4.2 directly to EC2.14 outputs and attach the remediation and exception artifacts to the control record so audit support becomes a retrieval task, not a reinvestigation. ²

Frequently Asked Questions

Does this control ban all RDP in AWS?

No. It bans RDP exposure to the public internet via 0.0.0.0/0 or ::/0 on port 3389. RDP can still be allowed from restricted, approved CIDRs or replaced with controlled admin access patterns. ³

What if we need emergency access during an incident?

Use a documented exception with a named owner, a short-lived change, and an expiry you actually enforce. Keep the ticket and the before/after security group rule export as evidence, then remove the exception promptly.

Is a security group compliant if the instance is in a private subnet?

CIS 4.2 evaluates the security group rule itself, not your intent for routing. A “private subnet” design can change, and attachments can change, so keep the rule restricted regardless. ³

How should we handle shared security groups used by many applications?

Avoid making ad hoc edits that break unknown dependencies. Clone the security group, apply compliant rules, migrate attachments in a controlled change, then retire the old group once confirmed.

Will Security Hub catch every violation automatically?

Security Hub’s CIS mapping includes the relevant control (EC2.14), and it is the right primary signal for audits. Keep an independent configuration query as a secondary check for completeness and troubleshooting. ²

What evidence is “enough” for an auditor?

Provide Security Hub EC2.14 results plus proof of remediation (change record and config snapshots) and proof of prevention (guardrail policy or CI checks). That combination shows design and operating effectiveness. ²

Footnotes

1. AWS Security Hub control EC2.14

2. AWS Security Hub CIS AWS Foundations mapping table

3. CIS AWS Foundations Benchmark