/hardening-cloud-posture

name: hardening-cloud-posture
description: Proactively harden a cloud account or organization before an incident — prioritizing IAM and identity risk over checkbox findings, closing the exposures that become attack paths (public storage, over-broad roles, missing audit logging, unencrypted data), reading CSPM output critically, and enforcing guardrails at the org level. Use when reviewing a cloud environment's security posture, triaging a Prowler/ScoutSuite/Security Hub report, deciding which misconfigurations actually matter, or setting preventive controls across AWS, Azure, or GCP.
verified: 2026-07-27

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.

Rationalizations to Reject

• *"We closed all the high-severity findings."* Severity is the scanner's guess

about a generic environment. The finding that matters is the one on the attack path, whatever it is labelled.

• *"The scan is green, so the account is secure."* The scan covers its checks.

Disabled logging, an over-broad role the tool rates low, and a suppressed finding are all invisible to a green result.

• *"Encryption-at-rest is our top gap."* Rarely the entry path. A public bucket

or a cross-account-assumable admin role outranks it unless compliance forces the order.

• *"We fixed the public bucket."* One bucket. Without an org-level guardrail the

next team makes the same bucket public next week. Fix the class.

• *"That finding was accepted as a risk."* By whom, when, and is it still true?

Stale acceptances are where real exposure hides.

• *"IAM is too complex to audit fully."* Then audit the escalatio