Cloud Security Maturity

About this program

Controls (20)

1. Are root / global-admin accounts protected with hardware MFA and reserved for break-glass only?

   Medium

   This control ensures that accounts with the highest privilege levels (root, global administrator, enterprise admin) are protected by hardware-based multi-factor authentication tokens (e.g., FIDO2 security keys, smart cards) and are used exclusively for emergency break-glass scenarios, not routine administration. Normal…

   How to test + evidence

   Risk: Root is the most-attacked credential. Hardware MFA + sealed credentials make it both unusable by attackers and auditable.

   Testing procedure: Inspect root account configuration. Verify hardware MFA registered, no API keys, alerting on every use, and sealed-vault storage of credentials.

   Evidence to collect: Root MFA status (hardware token registered) Last-used timestamp + alert log Credential storage location (sealed vault) Break-glass procedure document

2. Are all human identities federated through SSO (no local IAM users)?

   Medium

   This control mandates that all human user accounts authenticate through a centralized Single Sign-On (SSO) identity provider rather than using locally-created identity and access management (IAM) accounts within cloud platforms, applications, or infrastructure. Federation maps external identity provider credentials to…

   How to test + evidence

   Risk: Federated identity centralises lifecycle (joiner/mover/leaver) and MFA. Local IAM users drift and outlive the people they were created for.

   Testing procedure: List all IAM users in each cloud account. Verify only break-glass + service accounts exist; humans federate through SSO.

   Evidence to collect: IAM user inventory per account SSO config (IAM Identity Center / Entra ID / Workload Identity) Justification for any local IAM user Quarterly access review of remaining local users

3. Do you enforce least privilege for cloud roles (no wildcard / *:* policies)?

   Medium

   This control requires that all cloud identity and access management (IAM) roles, policies, and service principals be configured with the minimum permissions necessary to perform their intended functions, explicitly prohibiting the use of wildcard permissions (e.g., '*:*', 'Action: *', 'Resource:…

   How to test + evidence

   Risk: Wildcard IAM is the most common cloud finding. Automated analysis flags drift fast; JIT eliminates standing over-privilege.

   Testing procedure: Run IAM Access Analyzer / Azure Privileged Identity Management report. Flag any wildcard (*:*) policies and any unused permissions.

   Evidence to collect: IAM Access Analyzer findings Sample policies showing scoped permissions JIT elevation tooling configuration + logs Last review of role policies + reviewer

4. How do you manage long-lived access keys / service account credentials?

   Medium

   Long-lived access keys and service account credentials (e.g., AWS access keys, API tokens, service principal secrets) present persistent attack surface if compromised. This control establishes lifecycle management practices including rotation schedules, usage monitoring, deactivation of unused credentials, and secure storage…

   How to test + evidence

   Risk: Leaked long-lived keys are the #2 cloud breach root cause. IAM roles + short-lived tokens make leakage inert.

   Testing procedure: Inspect long-lived credentials inventory. Check rotation cadence and storage. Run secret scanning across code repos for leaked credentials.

   Evidence to collect: Credential inventory with last-rotation date Vault / KMS access logs Secret scanning report on repos IAM role usage replacing keys

5. Do you run continuous cloud posture management (CSPM) — Wiz, Lacework, Defender for Cloud, native Security Hub, etc.?

   Medium

   Cloud Security Posture Management (CSPM) is a category of tooling that continuously monitors cloud infrastructure configurations against security best practices, compliance benchmarks, and organizational policies. CSPM platforms such as Wiz, Lacework, Microsoft Defender for Cloud, and AWS Security Hub automatically…

   How to test + evidence

   Risk: Cloud configurations drift hourly. Without CSPM you can't see misconfigurations as they happen — and findings sit unactioned without auto-remediation.

   Testing procedure: Inspect CSPM tooling output. Verify coverage of all accounts/subscriptions. Sample 10 high-severity findings + remediation timestamps.

   Evidence to collect: CSPM dashboard with secure-score Coverage map (accounts / subscriptions / projects) Auto-remediation policy + recent actions Findings register with severity + status

6. Is cloud infrastructure managed via IaC (Terraform, CloudFormation, Bicep, Pulumi)?

   Medium

   Infrastructure as Code (IaC) management requires that cloud infrastructure provisioning, configuration, and lifecycle changes are defined in version-controlled declarative or imperative code using tools such as Terraform, AWS CloudFormation, Azure Bicep, or Pulumi. This approach replaces manual console-based changes with…

   How to test + evidence

   Risk: IaC + PR review enforces controls in tooling rather than trust. Click-ops produces undocumented changes that drift over months.

   Testing procedure: Sample 10 production cloud resources. For each, verify it can be reconciled to an IaC definition. Check drift detection tooling output.

   Evidence to collect: IaC repository + state files Drift detection tool output PR review process for IaC changes Runbook for emergency click-ops + retroactive IaC

7. Do you measure against a recognised baseline (CIS Benchmarks, AWS Foundational Security, Azure Security Benchmark)?

   Medium

   This control ensures that an organization measures its infrastructure and application configurations against recognized, industry-standard security baselines such as CIS Benchmarks, AWS Foundational Security Best Practices, Azure Security Benchmark, or equivalent. These baselines provide prescriptive hardening guidance for operating systems,…

   How to test + evidence

   Risk: Baselines give a measurable target. Auditors increasingly expect CIS-aligned configurations; gaps without justification are findings.

   Testing procedure: Inspect CSPM report against CIS / vendor baseline. Verify compliance percentage and that exceptions have business justification.

   Evidence to collect: CSPM report against baseline Compliance percentage trend Exception register with justification + review Remediation plan for non-compliance

8. Is workload network access restricted (private endpoints, no public S3/Storage by default, no 0.0.0.0/0 SSH/RDP)?

   Medium

   This control restricts cloud workload network access by eliminating public exposure of resources through enforcement of private connectivity patterns. It mandates the use of private endpoints or private links for PaaS services, disables public internet access to object storage (S3,…

   How to test + evidence

   Risk: Internet-exposed services are the most common initial access vector. Default-deny with documented exceptions is the only scalable model.

   Testing procedure: Run a CSPM check for "0.0.0.0/0 on port 22/3389/3306/etc.". Verify block-public-access on storage. Sample exceptions for justification.

   Evidence to collect: CSPM findings for open ports Block-public-access account-level settings Exception register with expiry dates Network architecture using private endpoints

9. Is data at rest encrypted with customer-managed keys where possible?

   Medium

   This control ensures that data stored at rest in cloud environments and on-premises systems is encrypted using cryptographic keys managed directly by the organization (customer-managed keys or CMKs), rather than relying solely on provider-managed default encryption. Customer-managed keys give organizations…

   How to test + evidence

   Risk: CMK gives you the cryptographic boundary. Provider-managed keys are encrypted but you can't demonstrate control or revoke access.

   Testing procedure: Sample storage / database / volume resources. Verify encryption enabled with CMK + rotation. Check KMS access logs.

   Evidence to collect: Encryption status report per service KMS key inventory + rotation schedule Sample KMS access logs CMK policy enforcement (e.g. SCP)

10. How are secrets (API keys, DB passwords) stored and accessed?

    Medium

    This control governs the secure storage, retrieval, and lifecycle management of secrets such as API keys, database passwords, encryption keys, certificates, and service account credentials. Secrets must be stored in dedicated vaults or secrets managers with encryption at rest, fine-grained…

    How to test + evidence

    Risk: Secrets in code or env files leak. Centralised secret management with auditing makes the loss containable and observable.

    Testing procedure: Inspect secret manager usage. Run secret scanning across repos for leaked credentials.

    Evidence to collect: Secret manager inventory Access audit log Secret scanning report (GitHub / GitLab native or Trufflehog) Rotation policy + recent rotations

11. Do you know where your sensitive data lives across cloud services (DSPM / data discovery)?

    Medium

    Data Security Posture Management (DSPM) and data discovery controls enable organizations to automatically identify, classify, and track sensitive data across cloud services, SaaS applications, databases, and storage repositories. These tools scan cloud environments to detect personally identifiable information (PII), protected…

    How to test + evidence

    Risk: Cloud data sprawls into unintended places. DSPM finds sensitive data in unexpected buckets, dev environments, and shadow accounts.

    Testing procedure: Inspect DSPM tooling output (Wiz, Cyera, Varonis) or manual data inventory. Verify classification labels are applied + reviewed.

    Evidence to collect: DSPM scan report Sensitive data inventory Classification policy + applied labels Records of processing for GDPR if applicable

12. Are cloud workload backups isolated from the production account/credentials?

    Medium

    This control ensures that cloud workload backups are stored in separate accounts or protected by independent credentials that are isolated from the production environment. The isolation prevents a single compromised credential set from enabling both production system access and backup…

    How to test + evidence

    Risk: A compromised production account can delete in-account backups. Cross-account + immutable defeats this.

    Testing procedure: Inspect backup architecture. Verify cross-account / cross-tenant separation, immutability, and last successful restore test.

    Evidence to collect: Backup architecture diagram Cross-account replication policy Object lock / immutability config Restore test report

13. Are control-plane logs (CloudTrail, Activity Log, Audit Log) enabled, centralised, and monitored?

    Medium

    Control-plane logs (AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) record API calls, administrative actions, and configuration changes across cloud infrastructure. Enabling these logs across all regions and accounts, centralizing them in a tamper-resistant storage location (such as a…

    How to test + evidence

    Risk: Control-plane logs are forensic gold during a cloud incident. Without centralisation, an attacker who deletes them is invisible.

    Testing procedure: Inspect CloudTrail / Activity Log status across all accounts. Verify centralised log destination + tuned detection content.

    Evidence to collect: CloudTrail / Activity Log status per account Central log archive (separate account) SIEM detection rules for cloud events Sample alerts triaged in the period

14. Are workload-level logs (VPC flow, container, app) sent to your SIEM?

    Medium

    This control ensures that workload-level logs—including VPC flow logs, container runtime logs, and application logs—are forwarded in near-real-time to a centralized Security Information and Event Management (SIEM) system. Proper log ingestion enables correlation of network traffic patterns, containerized workload activity,…

    How to test + evidence

    Risk: Control-plane logs alone miss runtime threats. VPC flow + container logs catch lateral movement and exfiltration.

    Testing procedure: Sample workloads. Verify VPC flow logs + container logs are forwarded with sufficient retention.

    Evidence to collect: VPC flow log configuration Container log forwarding (FluentBit / similar) Detection rules for cloud-specific TTPs

15. Do you have runtime cloud workload protection (CWPP / agent or eBPF) detecting active threats?

    Medium

    Cloud Workload Protection Platform (CWPP) solutions deploy runtime agents or eBPF (extended Berkeley Packet Filter) sensors on cloud workloads (VMs, containers, serverless functions) to monitor process execution, file integrity, network connections, and system calls in real time. These sensors detect…

    How to test + evidence

    Risk: Runtime threats (cryptojacking, lateral movement, container escapes) are invisible without CWPP. Coverage gaps are where attackers hide.

    Testing procedure: Inspect CWPP coverage report (Wiz Runtime, Sysdig, Falco, Aqua, etc.). Verify production workloads have agent + alerting.

    Evidence to collect: CWPP coverage report Sample runtime alerts triaged Auto-response policy for high severity

16. When a critical cloud alert fires (e.g. credential exposure), how is it triaged?

    Medium

    This control governs the documented process by which critical cloud security alerts—such as credential exposure, root account usage, public S3 buckets, or IAM privilege escalation—are received, classified, assigned, investigated, and resolved within defined SLAs. It ensures that high-severity events trigger…

    How to test + evidence

    Risk: A great alert that nobody acts on is worse than no alert. 24/7 with runbooks closes the loop.

    Testing procedure: Inspect alert routing + on-call rota. Sample 5 high-severity alerts in the period and verify investigation timestamps.

    Evidence to collect: Alert routing policy On-call schedule Sample triage records with timestamps Mean-time-to-acknowledge metric

17. Is security testing integrated into CI/CD (SAST, dependency scanning, IaC scanning, secret scanning)?

    Medium

    This control ensures that automated security scanning tools are embedded within the Continuous Integration/Continuous Deployment (CI/CD) pipeline to detect vulnerabilities before code reaches production. Static Application Security Testing (SAST) analyzes source code for security flaws, dependency scanning identifies vulnerable third-party…

    How to test + evidence

    Risk: Shifting left catches issues at $0.10 instead of $10,000. Advisory-only scanning gets ignored.

    Testing procedure: Inspect CI/CD pipeline definition. Verify SAST + SCA + IaC scan + secret scan are required for merge with blocking on critical findings.

    Evidence to collect: Pipeline config showing security gates Sample PRs with findings + resolution Tool reports for SAST + SCA + IaC scanning Block-on-critical policy enforcement

18. Are container images scanned, signed, and pulled from a controlled registry?

    Medium

    This control ensures that container images used in production and non-production environments are scanned for vulnerabilities before deployment, cryptographically signed by trusted parties to verify authenticity and integrity, and retrieved exclusively from organization-approved registries. Image scanning detects known vulnerabilities (CVEs),…

    How to test + evidence

    Risk: Unsigned images from public registries are supply-chain risk. Signing + scanning + admission control gives end-to-end provenance.

    Testing procedure: Inspect registry config + cluster admission control. Verify only signed images can be pulled and scanning is required.

    Evidence to collect: Registry scan policy Image signing config (cosign / Notary) Cluster admission policy (Kyverno / OPA Gatekeeper) Sample blocked-image events

19. Are workloads ephemeral and frequently rebuilt (vs long-lived snowflakes)?

    Medium

    Ephemeral workloads are compute instances, containers, or serverless functions that are frequently destroyed and recreated from immutable images or infrastructure-as-code templates rather than maintained as persistent, manually-configured systems. This approach eliminates configuration drift, reduces the attack surface from accumulated changes,…

    How to test + evidence

    Risk: Immutable infrastructure means attackers can't establish persistence — every rebuild wipes them. Snowflakes accumulate state and exposure.

    Testing procedure: Sample workloads. Verify image age (uptime) and deployment cadence. Long-lived servers without recent rebuilds are flagged.

    Evidence to collect: Workload uptime distribution Deployment cadence per service Patch / config drift evidence on long-lived hosts

20. Are cloud configuration changes peer-reviewed and traceable to a ticket?

    Medium

    This control ensures that all configuration changes made to cloud infrastructure (such as IAM policies, network security groups, compute instances, storage permissions, and service configurations) undergo mandatory peer review by a second qualified individual before deployment, and that each change…

    How to test + evidence

    Risk: Reviewed PR-driven changes give an audit trail and a second pair of eyes. Console changes hide and bypass the control.

    Testing procedure: Sample 10 cloud changes. Verify each has IaC PR + reviewer + ticket reference. Click-ops changes should be flagged for retroactive IaC.

    Evidence to collect: Sample PRs with reviewer + ticket reference CloudTrail audit showing change source (IaC vs console) Process for emergency click-ops + retroactive IaC