AWS Security Improvement
A sequenced hardening arc for an AWS estate: root and IAM hygiene first, then organization guardrails and encryption defaults, then detection and a rehearsed security response.
Every step is executable work: what, why, prerequisites, implementation, validation you can check, and the failure modes to avoid. Dependencies make the order explicit — a step marked Requires waits on those steps completing first.
Phase 1
Identity and access first
Nothing else holds while root is exposed and IAM is flat. Close the identity holes before buying more controls.
Lock down root: MFA, no keys, no daily use
P0XSFull step — what, why, how, failure modes
WHAT. Every account's root user has hardware or TOTP MFA, holds no access keys, and is used only for the handful of tasks that require it — behind a sealed-envelope or vault-held password. WHY. Root bypasses every guardrail you will ever build; a root access key in a leaked file defeats the entire rest of this roadmap in one line. PREREQUISITES. None — this is the cheapest, highest-leverage step in the arc. IMPLEMENTATION. For each AWS account: enable MFA on root, delete any root access keys, remove root from daily workflows, and store the password in the break-glass vault. For an organization, require the above via account-level checks and audit monthly. TOOLS. AWS IAM credential report; your secrets vault for the password custody record. COMMON FAILURE MODES. Enabling MFA on one account but not the sandbox nobody watches — attackers take the unwatched one. EXPECTED IMPACT. The single most privileged credential in the estate becomes unusable for attackers and unused by habit. EVIDENCE. The credential report export and the vault entry reference (not the secret).Validation — before you call it done
IAM credential report shows root MFA enabled on 100 percent of accounts, 0 root access keys, and root last used more than 90 days ago on every account.
Right-size IAM policies and eliminate wildcards
P0LRequires: Lock down root: MFA, no keys, no daily useFull step — what, why, how, failure modes
WHAT. Inventory roles and policies, delete the ones nobody uses, and replace wildcard actions/resources with scoped statements generated from access-activity data. WHY. Most estates carry policies written in a hurry with Action: s3:* Resource: * — the audit finding that turns a compromised Lambda into estate-wide data access. PREREQUISITES. Root hygiene done, so the cleanup itself is the widest open hole left. IMPLEMENTATION. Generate IAM access advisor and CloudTrail-based policy findings, attach unused-policy detection to a deletion queue with a 30-day notice, and generate right-sized policies from the last 90 days of activity. Replace user-long-lived credentials with roles and SSO everywhere. TOOLS. IAM Access Analyzer; access advisor; CloudTrail; an IAM linting tool such as iam-policy-validator in CI. COMMON FAILURE MODES. Right-sizing from activity data while a quarterly job was idle — the November batch job then fails (loudly) or worse, someone re-adds the wildcard. EXPECTED IMPACT. A compromised workload credential reaches exactly its workload's data and no further. EVIDENCE. Policy inventory before/after plus the exception list with signatures.Validation — before you call it done
Zero customer-managed policies contain Action * or Resource * except a documented, owner-signed exception list under 5 entries per account.
Kill long-lived access keys: roles and SSO only
P0MRequires: Right-size IAM policies and eliminate wildcardsFull step — what, why, how, failure modes
WHAT. No IAM-user access keys older than 90 days anywhere: humans federate via SSO, automation assumes roles, and anything that must hold a credential does it for hours, not quarters. WHY. Long-lived keys leak from laptops, repos, and CI logs; a role assumption is a bounded, auditable, revocable act while a key is a standing credential that outlives the person who made it. PREREQUISITES. IAM right-sizing underway so role boundaries exist to assume. IMPLEMENTATION. List every access key with its last-used date, revoke dead keys immediately, migrate live consumers to role assumption (cross-account roles for AWS-to-AWS, OIDC federation for CI), and set an org policy alerting on any key crossing 90 days. TOOLS. IAM credential report; GitHub Actions OIDC or equivalent federation; SSO (AWS IAM Identity Center). COMMON FAILURE MODES. Migrating CI to roles but leaving the old key 'temporarily' — the temporary key is the one that leaks. EXPECTED IMPACT. The most common leak vector in cloud incidents stops existing in your estate. EVIDENCE. Credential report export and the CI provider's role-federation config (secret-free).Validation — before you call it done
IAM credential report shows zero access keys older than 90 days in active use, and CI systems authenticate via OIDC federation with no stored AWS secrets.
Phase 2
Organization guardrails
Make the dangerous configurations undeployable, and the estate observable, with org-level controls and logging.
Turn on organization-wide CloudTrail and Config
P0SFull step — what, why, how, failure modes
WHAT. One multi-region CloudTrail (management + data events for crown-jewel buckets) at the org level, plus AWS Config recorders with a conformance-pack baseline in every account. WHY. Without an org-level trail, a compromised account's first move is to turn logging off in that account; detection, forensics, and half this roadmap's validations all read from this trail. PREREQUISITES. None technically; do it early because every later step validates against it. IMPLEMENTATION. Create the organization trail into a dedicated log-archive account with bucket-level deny policies on deletion, enable Config recorders org-wide, and ship the trail to your SIEM or at minimum S3+ Athena for queryable history. TOOLS. AWS Organizations; CloudTrail; Config conformance packs; Athena or your SIEM. COMMON FAILURE MODES. Per-account trails created by enthusiasts — the org trail is the one an attacker cannot quietly switch off; treat account trails as optional extras. EXPECTED IMPACT. Every control-plane action in the estate is recorded, queryable, and tamper-resistant. EVIDENCE. Trail status output, the denied StopLogging test event, and the Athena/SIEM query result.Validation — before you call it done
A query over the last 24 hours of the org trail returns events from every active account and region, and a test StopLogging attempt in a member account is denied by the org policy.
Close the network holes: no 0.0.0.0/0 management ports
P0MRequires: Turn on organization-wide CloudTrail and ConfigFull step — what, why, how, failure modes
WHAT. Security groups audited so no SSH (22) or RDP (3389) is reachable from the internet, management paths ride SSM or bastion-in-VPN, and databases sit in private subnets. WHY. The exposed management port is still the most common initial-access vector in cloud intrusions, and it is visible to every scanner on earth within minutes of creation. PREREQUISITES. CloudTrail and Config give you the audit surface to find the offenders. IMPLEMENTATION. Query the network inventory for ingress 0.0.0.0/0 on management ports, replace direct SSH with Session Manager (no inbound ports at all), move data stores to private subnets, and add a Config rule alerting on any new 0.0.0.0/0 management ingress so the hole never reopens. TOOLS. AWS Config network rules; Session Manager; VPC Reachability Analyzer. COMMON FAILURE MODES. Fixing the console-created groups but not the Terraform that recreates them on the next apply — fix the module, then the estate. EXPECTED IMPACT. The whole class of scanner-driven compromise stops at the perimeter. EVIDENCE. The inventory query output and the Config rule compliance timeline.Validation — before you call it done
A network-inventory query returns zero internet-reachable management ports across all accounts, and the Config rule reports compliant for 30 consecutive days.
Enforce service control policies for the top dangerous actions
P1MRequires: Turn on organization-wide CloudTrail and ConfigFull step — what, why, how, failure modes
WHAT. A small set of SCPs blocking the catastrophic few: public S3 block at org level, region restriction, encryption-required policies, and deny on leaving the guardrails themselves. WHY. Guardrails scale because they are enforced before deployment — the intern cannot ship a public bucket at 5 p.m. Friday, so nobody has to catch it at 5:01. PREREQUISITES. CloudTrail on — so guardrail denials are visible and explainable rather than mysterious. IMPLEMENTATION. Start with org-level Block Public Access, a deny for unencrypted S3 puts and EBS creates, and a region allow-list. Attach to OUs progressively (sandbox, then production), and monitor CloudTrail for DeniedByPolicy to catch teams the guardrail surprises. TOOLS. AWS Organizations SCPs; Block Public Access at org level. COMMON FAILURE MODES. FullCISAccess-style kitchen-sink SCPs attached before anyone reads them — teams lose the ability to work and someone detaches the whole thing under pressure. EXPECTED IMPACT. The catastrophic class of misconfiguration becomes undeployable rather than punishable after the fact. EVIDENCE. SCP JSON attached to the doc, plus the CloudTrail denial events from the test.Validation — before you call it done
An attempted public-bucket creation and an out-of-region launch both fail with an explicit deny in a sandbox account, and a weekly CloudTrail query (last 7 days) shows the deny events reaching your dashboard.
Make encryption the default everywhere
P1SRequires: Enforce service control policies for the top dangerous actionsFull step — what, why, how, failure modes
WHAT. KMS encryption by default on S3, EBS, RDS, and queues — customer-managed keys for regulated data — enforced by policy, not habit. WHY. Encryption-at-rest is nearly free when default and expensive when retrofit; after a guardrail denies the unencrypted create, defaults make the compliant path the lazy path. PREREQUISITES. The encryption SCP in place or landing with it, so both push and pull agree. IMPLEMENTATION. Set account-level S3 encryption defaults with a customer-managed key, default EBS encryption per region, and RDS storage encryption on every new instance. Inventory existing unencrypted resources and migrate the crown jewels first on a dated plan. TOOLS. AWS KMS; account default settings; AWS Config rules for drift detection. COMMON FAILURE MODES. Defaulting new resources while the existing fleet of unencrypted volumes sits quietly — the inventory is the step people skip. EXPECTED IMPACT. Data-at-rest exposure drops to a tracked, shrinking list instead of an unknown. EVIDENCE. Default-encryption settings export and the shrinking unencrypted-resource report.Validation — before you call it done
Creating a bucket, volume, and database without specifying encryption yields encrypted resources in a sandbox account, and the unencrypted-resource inventory shrinks by at least 25 percent quarter over quarter with a documented plan for the remainder.
Phase 3
Detection and response
See the bad thing, then have a rehearsed answer for it — the difference between an incident and an anecdote.
Enable GuardDuty and Security Hub with the CIS standard
P1SRequires: Turn on organization-wide CloudTrail and ConfigFull step — what, why, how, failure modes
WHAT. GuardDuty on every account and region, findings piped to Security Hub with the CIS AWS Foundations standard enabled, and both feeding the on-call channel — not a console nobody opens. WHY. The logs exist (you did that); detection is the part that tells a human in minutes instead of months; Security Hub CIS mapping turns raw findings into the benchmark's own language. PREREQUISITES. Org CloudTrail and Config — the detectors read from and correlate with them. IMPLEMENTATION. Enable GuardDuty as a delegated administrator across the org (all regions), enable Security Hub with CIS standards, aggregate findings to the security account, and route high-severity findings to the on-call pipeline with a documented triage SLA. TOOLS. GuardDuty; Security Hub; EventBridge routing to chat/on-call. COMMON FAILURE MODES. Findings delivered to a mailbox — detection without a human attached is a very expensive log viewer. EXPECTED IMPACT. Attacker dwell time in your estate starts being measured in minutes, and benchmark gaps are a score you watch, not a PDF you archive. EVIDENCE. The alert screenshot and the Security Hub CIS score history.Validation — before you call it done
A planted test finding (e.g., generated credential-exposure event) reaches the on-call channel within 15 minutes, and Security Hub shows CIS pass-rate for the account above 80 percent with the failures triaged.
Write and rehearse the cloud security incident runbook
P1MRequires: Enable GuardDuty and Security Hub with the CIS standardFull step — what, why, how, failure modes
WHAT. A one-page-per-scenario runbook for the big three — compromised credentials, cryptomining, and data-exposure — with containment moves, evidence rules, and a rehearsed game day behind it. WHY. During an incident you cannot remember guardrail names or evidence-preservation orders; the runbook is what you execute, and the rehearsal is what makes it executable (NIST 800-61's handling guide maps the same phases). PREREQUISITES. Detection wired (GuardDuty/Hub) so the rehearsal has a trigger to start from. IMPLEMENTATION. Write the three runbooks with concrete first commands (which key to revoke, which role to detach, which SG to close), a forensic do-not-delete list, and escalation contacts. Run one game day in a sandbox: plant a rogue user, detect, contain, and time each phase. TOOLS. The runbook repo; sandbox account; your incident channel convention. COMMON FAILURE MODES. Runbooks that begin with log into the console — during the real thing the console is the thing being attacked; prefer CLI commands with exact role names. EXPECTED IMPACT. A security incident becomes a contained, timed, reviewed process instead of an improvisation with an audience. EVIDENCE. The runbooks in the repo, the game-day timeline with clocks, and the closed action list.Validation — before you call it done
The game day closes the planted rogue-user scenario with containment inside 30 minutes and evidence intact, and the post-drill action list is fully closed within 2 weeks.
Run quarterly access reviews backed by last-used data
P2SRequires: Kill long-lived access keys: roles and SSO onlyFull step — what, why, how, failure modes
WHAT. Every quarter, each account owner reviews who and what has access, with last-used evidence attached, and anything unused-but-privileged is revoked as part of the review. WHY. Access accumulates like sediment: the contractor from March, the pipeline replaced in June; last-used data turns the review from a rubber stamp into a decision with evidence (the CIS benchmark calls for exactly this). PREREQUISITES. Roles-not-keys migration done — the review surface is roles and SSO groups, not a hundred scattered keys. IMPLEMENTATION. Stand up a recurring review: generate access lists with last-used stamps per account, collect owner verdicts (keep/revoke) with a deadline, apply revocations automatically on non-response, and record the review as evidence for audits. TOOLS. IAM Access Analyzer; your review tracker (issue template is fine). COMMON FAILURE MODES. Reviews that only ask do you still need this — with last-used data visible the answer is mostly already known, and the question becomes why. EXPECTED IMPACT. Standing privilege in the estate decays instead of compounding, and audits become exports instead of scrambles. EVIDENCE. The four review records with owner verdicts and the applied-revocation diffs.Validation — before you call it done
Four consecutive quarterly reviews completed with 100 percent of accounts covered, and each shows a revoke rate above zero with every revocation applied within the cycle.
Sources
- Tier 2 — AuthoritativeAWS Well-Architected — Security Pillar ↗— AWS(verified 2026-09-19)
- Tier 1 — PrimaryCIS Amazon Web Services Foundations Benchmark ↗— CIS(verified 2026-09-19)
- Tier 1 — PrimaryNIST SP 800-61r2 — Computer Security Incident Handling Guide ↗— NIST(verified 2026-09-20)
Start from where YOU are
This roadmap is the general path. An assessment tells you which steps you can skip and which are critical — then generates a version of this plan from your actual findings, tracked to done in your workspace.