AWS Security Issues You Can Actually Fix With Settings

AWS Security Issues You Can Actually Fix With Settings

Most AWS security incidents are not caused by zero-day exploits or nation-state attacks.

They happen because a default was left unchanged, a policy grew over time, or an automation path quietly gained more privilege than intended.

The good news: many of today’s highest-impact AWS security risks can be fixed immediately using settings you already have access to.

Below are issues I keep seeing in real environments, along with how teams are fixing them without buying new tools.

---

1. IAM Roles Quietly Becoming “Permanent Credentials”

The issue

IAM roles were designed to be short-lived and tightly scoped. In practice, many production roles now behave like permanent credentials:

• Broad wildcard permissions (*:*)
• Long session durations
• Reuse across environments
• Assumed by CI/CD, humans, and automation

This creates a single compromise point with no expiration pressure.

Why this still happens

Because nothing breaks immediately.

The blast radius only shows up during an incident.

Fix (pure settings)

• Reduce MaxSessionDuration on sensitive roles (1–2 hours, not 12)
• Split roles by actor (human, pipeline, service)
• Add IAM policy Condition blocks:
  • aws:SourceVpc
  • aws:PrincipalArn
  • aws:RequestedRegion
• Enable IAM Access Analyzer findings and treat them as defects, not suggestions

Why this matters: This is one of the highest-ROI security fixes in AWS, and it costs nothing.

---

2. CloudTrail Logging Exists… But it Isn’t Defensible

The issue

Most accounts have CloudTrail enabled.

Very few have it configured to survive an attacker who already gained access.

Common gaps:

• Logs stored in the same account being attacked
• No log file integrity validation
• No alerts on trail changes

Fix (pure settings)

• Send CloudTrail logs to a central logging account
• Enable log file integrity validation
• Add EventBridge rules for:
  • StopLogging
  • DeleteTrail
  • UpdateTrail
• Block CloudTrail modification using SCPs in production OUs

Logging that can be deleted is not logging. It’s optimism.

---

3. Security Groups Used as “Temporary Fixes” Permanently

The issue

Security groups are often modified during incidents or debugging.

“Just open it to my IP for now.”

Those rules almost never get removed.

Over time:

• CIDRs widen
• Ports accumulate
• Original intent is lost

Fix (pure settings + discipline)

• Enable AWS Config rules to:
  • Disallow 0.0.0.0/0 on sensitive ports
  • Flag unused security group rules
• Use security group referencing instead of IPs wherever possible
• Require PRs or change tickets for security group updates via IaC

Security groups are infrastructure. Treat them like code.

---

4. S3 Buckets Are “Private” Until They Aren’t

The issue

Most S3 breaches involve not public buckets.

They are implicitly accessible buckets caused by:

• Over-permissive bucket policies
• Forgotten cross-account access
• IAM roles with s3:* on *

Fix (pure settings)

• Enable S3 Block Public Access at the account level
• Turn on Access Analyzer for S3
• Require bucket policies to explicitly deny:
  • Unencrypted uploads
  • Non-TLS access
• Enforce S3 server-side encryption

If a bucket contains data you wouldn’t post publicly, its policy should read like a contract, not a guess.

---

5. CI/CD Pipelines With More Power Than Production

The issue

Build systems often have broader permissions than runtime services:

• Can create IAM roles
• Can modify networking
• Can read secrets across environments

If CI/CD is compromised, production is already lost.

Fix (pure settings)

• Scope pipeline roles to deployment-only permissions
• Separate build and deploy roles
• Enforce iam:PassRole restrictions
• Rotate pipeline credentials aggressively
• Use AWS-managed OIDC instead of static secrets

Your pipeline is part of your attack surface. Configure it like one.

---

6. GuardDuty Enabled But Ignored

The issue

GuardDuty is enabled, and findings exist, but:

• Nobody owns them
• No severity mapping
• No automated response

This creates alert fatigue with zero protection.

Fix (pure settings)

• Route high-severity findings to EventBridge
• Auto-tag compromised resources
• Trigger isolation playbooks (security groups, IAM disable)
• Define escalation paths per severity

Detection without response is noise.

---

Final Thought

Most AWS security problems in 2026 are not caused by missing tools.

They are caused by unconfigured intent.

The platform already provides controls like IAM conditions, SCPs, Config rules, centralized logging, and event-driven responses. The gap is not in capability. It’s attention.

Security improves fastest when teams stop asking:

“What should we buy?”

and start asking:

“Which defaults should never have been trusted?”