AWS Cloud Infrastructure Posture Kit

Three in four scanned AWS accounts have something publicly exposed right now. A 2026 index built from live configuration data across roughly three thousand organisations found 76% of AWS accounts had at least one publicly exposed service — the highest of the three major clouds — and 87% of S3 buckets did not enforce HTTPS. Across every provider, 99% of cloud identities carry more permissions than they need, and 35% of cloud incidents are valid-account abuse: a stolen or over-permissioned credential used exactly as intended, no exploit involved. This kit finds out which side of those numbers your account sits on, and what it would actually cost you.

Scored against the benchmark Security Hub itself uses. The CIS Amazon Web Services Foundations Benchmark v3.0.0 — sixty-plus controls across IAM, storage, logging, monitoring and networking — is the backbone of the hardening checklist, condensed to the highest-impact controls with section references per row. No invented framework, no disclosed substitution. It is a configuration and architecture posture assessment, not a penetration test, and it sits above Prowler, Security Hub and Config rather than replacing them.

Why three cloud kits rather than one. The same 2026 data shows near-zero overlap between each cloud's top misconfiguration categories: AWS leads on raw public exposure, Azure on misconfigured services and identity gaps, Google Cloud on identity hygiene despite the best network posture of the three. So the trilogy is scoped per platform on one scoring scale — this kit first, the Azure Cloud Infrastructure Posture Kit second, and the Google Cloud Platform Posture Kit closing it, on the same five modules and the same bands, so a multi-cloud estate gets comparable numbers — and the trilogy is cheaper than buying all three.

The 2026 incident the kit points at. A supply-chain compromise through a widely used AI-gateway library exposed cloud credentials across more than two and a half thousand organisations and roughly four hundred thousand CI/CD pipelines. Whether AWS credentials are used in CI/CD is a question on the Account Structure tab for that reason, and OIDC federation for pipelines is scored in file 02.

The detection finding is a wiring gap. The benchmark requires fourteen paired CloudWatch metric filters and alarms. The common real-world state is that the filter exists and the alarm has no subscriber — logging enabled, nobody listening. File 06 makes that row the headline.

What you get

01 Assessment Methodology (DOCX) — the numbers, the benchmark as backbone, the five modules, run order, cross-links and assumptions.

02 Identity & Access Review Workbook (XLSX) — Root Account Protection (hardware MFA, zero access keys, usage alarms, no routine use), IAM Policy & MFA (password policy to CIS minimums, MFA for every console user, 90-day key rotation, 45-day unused-credential cleanup), Least Privilege & Roles (no wildcards, roles over long-lived users, review cadence) and Federation & CI-CD Access (IAM Identity Center or an external IdP, OIDC or short-lived roles for pipelines, cross-account trust scoped to named accounts), rolling into one identity posture score.

03 Blast Radius Scoring Tool (XLSX) — the flagship module. Record the Account Structure first — single account or Organizations, primary workload, credentials in CI/CD — run the S3 public-access-block audit and IAM Access Analyzer, then answer the control questions across public storage exposure (account-level Block Public Access, HTTPS-only bucket policies, default encryption, versioning and object lock on audit buckets), IAM over-permission, logging gaps and network & credentials. One score, a band on the same bands as every posture kit, and a closure list ranked by risk-weighted points.

04 CIS-Aligned Hardening Checklist (XLSX) — IAM, Storage (S3 and EBS), Logging (CloudTrail in all regions, log-file validation, a private and encrypted trail bucket) and Monitoring & Networking (the fourteen filter-alarm pairs, no 0.0.0.0/0 to admin ports, VPC Flow Logs, restricted default security groups), scored gap-to-target with a hardening percentage per family.

05 Data Governance Review (DOCX) — encryption at rest across S3, EBS and RDS (RDS encryption cannot be added retroactively without a snapshot and restore), KMS key management and whether key access matches who should have it, and data classification coverage.

06 Detection Readiness Matrix (XLSX) — CloudTrail, S3 data events, GuardDuty, Config and Config Rules, Access Analyzer and Security Hub, each row stating whether it is on by default and whether anything alerts proactively.

07 Executive Summary Template (DOCX) — one page: the four module scores, top five findings, plain-language meaning, remediation timeline, and the note to run the Azure and Google Cloud kits alongside for a multi-cloud estate.

aws01.json — scoring bands, surfaces, account-structure components, the benchmark and the module map.

A worked example throughout. Brindlewood Media, a fictional streaming company with heavy S3 usage across a multi-account Organization, with Block Public Access on account-wide and one legacy bucket still to prove.

Where it sits. An EKS cluster inherits this account's IAM risk — the Docker & Kubernetes Security Posture Kit follows the chain from the pod to here. The GitHub / GitLab Security Posture Kit covers the pipeline that holds the credentials; the Okta / Identity Provider Security Posture Kit covers federated access into the account. The IR Runbook Library is the response layer. Run it against a vendor's account with the TPRM Program Kit; hand file 07 to the Director's Cyber Oversight Kit.

Written against AWS service names, defaults, published statistics and CIS AWS Foundations Benchmark v3.0.0 as of Q3 2026, marked verify. Benchmark references are section mappings to a condensed control set, not full-benchmark coverage. Not a penetration test. Scores are a prioritisation aid, not a certification, an audit opinion or an insurance-underwriting determination. Not legal advice.