KEY TAKEAWAY
Enabling posture management is an afternoon. Acting on it is the whole job. The first scan of any mature account produces hundreds of findings, and the value comes entirely from deciding which ones matter and who owns them.
What this lab covers
You enable AWS Security Hub CSPM against an account, work through the findings it produces in both the console and the command line, and reason about which of them represent genuine risk.
Using the command line matters more than it sounds. A dashboard is for reading, and an API is for automating, and posture management only becomes a control once the findings are queried and routed automatically.
It assumes basic command line knowledge and no prior AWS experience, and suits anyone who has inherited a cloud estate and needs to know what state it is in.
How Security Hub CSPM works
Security Hub runs automated checks against your resources, mapped to standards such as the AWS Foundational Security Best Practices and CIS benchmarks. Each check produces a finding with a severity and a resource reference.
It also aggregates. Findings from GuardDuty, Inspector, Macie and third-party tools arrive in a single normalised format, which is what makes triage possible across sources rather than tool by tool.
Severity is assigned to the check rather than to your situation. A critical finding on an isolated development resource may matter far less than a medium one on an internet-facing production system, and nothing in the tool knows that distinction. Adding your own context is the analyst's contribution.
How to detect this in your own environment
Route new high severity findings to alerting and leave the rest in a queue. A dashboard reviewed occasionally is not a detection mechanism, and the categories that matter deserve to interrupt someone.
Measure how long findings stay open rather than how many exist. Total count reflects the size of your estate, and open duration reflects whether the process works.
Watch for findings that recur after remediation, which indicates a pipeline or template producing them. Those are worth escalating because fixing the source removes the whole class.
How to prevent it
Enable it across every account and region through your organization, since findings in regions nobody uses are a recurring discovery.
Push the equivalent checks into your deployment pipeline so misconfigurations are prevented rather than reported. Posture management tells you what is wrong now, and pipeline checks stop it recurring.
Suppress deliberately, with a reason and an owner recorded. Suppression is legitimate and it is also how findings quietly disappear without anyone fixing anything.
Real-world context
Cloud misconfiguration is consistently among the most reported causes of cloud data exposure, and it usually results from a resource nobody knew existed or a setting that drifted rather than from anyone not knowing the correct configuration.
The common failure of posture programs is well documented: a large finding count, no ownership, and remediation slow enough that the tool becomes evidence for auditors rather than a control that changes anything.
It addresses the conditions behind MITRE ATT&CK T1530 Data from Cloud Storage Object and T1078.004 Cloud Accounts by removing exposure before it is exploited.
Applying this at work
- Enable Security Hub across all accounts and regions through your organization.
- Query findings with the CLI rather than only reading the dashboard, so the output can be routed and automated.
- Assign owners for the top severity categories and set a target time to remediate.
- Record a reason and an owner for every suppression.
- For any finding that recurs, fix the template or pipeline producing it rather than the instance.
Frequently asked questions
What does AWS Security Hub CSPM actually do?
It runs automated configuration checks mapped to security standards and aggregates findings from other AWS and third-party tools into one normalised view, so posture can be triaged across sources rather than tool by tool.
Why is severity not enough to prioritize?
Because severity describes the check, not your exposure. A critical finding on an isolated development resource can matter less than a medium one on an internet-facing production system, and the tool has no way to know that.
How do I stop the same findings coming back?
Fix the template or pipeline that produces them and add equivalent checks to your deployment process. Remediating instances individually is endless if something keeps creating them.
Do I need my own AWS account to practice this?
No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.
Which certification covers this in depth?
The Amazon Cloud Red Team Professional (ACRTP) covers AWS attack and detection paths in full, including IAM abuse and privilege escalation, and is assessed hands-on in a live AWS account.
aws.png)