Hardening Cloud Posture

Hardening Cloud Posture

A CSPM scan returns a thousand findings. Almost none of them are the way in. The job is not to close a thousand findings; it is to find the handful that form an attack path and close those, then set guardrails so they cannot recur. Posture work that treats every finding as equal drowns the real one.

The organizing principle: identity is the perimeter. In cloud, the attack path is almost always a chain of IAM permissions, not a network hop. Rank by "what does this let a principal reach?", not by a scanner's severity label.

When to Use

• Reviewing an AWS/Azure/GCP account or organization's security posture
• Triaging a Prowler, ScoutSuite, Security Hub, or Defender for Cloud report
• Deciding which of many misconfigurations actually matter
• Setting preventive guardrails (SCPs, Azure Policy, org policies)
• Enabling the logging and controls an investigation will later depend on

When NOT to Use

• Actively investigating a live incident — use investigating-aws-incidents, investigating-azure-incidents, or investigating-gcp-incidents
• Attacking the environment to prove the path — use exploiting-cloud-platforms
• Kubernetes cluster-plane hardening — use defending-kubernetes
• Ranking CVEs in workloads rather than cloud config — use managing-vulnerabilities

Rank by Attack Path, Not Finding Count

Work findings in the order an attacker would exploit them, not the order the scanner lists them:

1. Public exposure of data or compute. Public S3/GCS buckets and storage accounts, publicly reachable databases, management ports open to 0.0.0.0/0. These need no credential — they are pre-authentication. Close first.
2. Identity that over-reaches. Wildcard Action/Resource policies, roles assumable by * or by external accounts without a condition, users with iam:PassRole to a privileged role, service principals with Owner. This is where a foothold becomes account-takeover.
3. Missing or disabled audit logging. CloudTrail not multi-region, GCP Data Access logs off, Azure diagnostic settings absent. This does not create the breach but it blinds the investigation — enable it now, because you cannot retroactively log the incident you are about to have.
4. Unencrypted data and absent key management. Real, but rarely the entry path. Fix after the above unless a compliance obligation reorders it.

A public bucket with customer data outranks a hundred "encryption not enabled" findings, even though the scanner may score them alike.

Read CSPM Output Critically

Prowler, ScoutSuite, Security Hub, and Defender for Cloud are the standard tools and they are useful — but their output is a starting point, not a verdict:

• Severity is generic. The tool does not know your environment. A "medium" on a role assumable cross-account may be your worst finding; a "high" on an internal-only resource may be noise.
• Findings lack blast radius. The tool reports that a policy has *; it does not tell you that role is attached to an internet-facing function. You supply the reachability.
• Suppressions hide real risk. A finding suppressed months ago "because it was accepted" may no longer be acceptable. Review the suppression list as carefully as the open findings.
• Green is not clean. The scanner checks what it checks. A passing scan with Data Access logging disabled has a large blind spot it will never report as a finding.

Map the top findings to CIS Benchmark controls where a compliance frame helps, but do not let the benchmark set your priority — the benchmark is comprehensive, your remediation budget is not.

Guardrails Beat Findings

A fixed misconfiguration recurs the next time someone provisions a resource. A guardrail prevents the whole class:

• AWS: Service Control Policies to deny public S3 org-wide, deny disabling CloudTrail, restrict regions; s3:BlockPublicAccess at the account level.
• Azure: Azure Policy with deny effects for public network access, required encryption, required diagnostic settings.
• GCP: Organization Policy constraints (storage.publicAccessPrevention, iam.disableServiceAccountKeyCreation, compute.requireOsLogin).

Prefer the org-level deny over the per-resource fix. The point-fix closes one finding; the guardrail closes the class and every future instance of it.