Last reviewed:
How to use AWS Security Hub control results without mistaking posture status for SOC detection coverage.
Security Hub is AWS's central security findings service. Its controls check whether resources meet the requirements of enabled standards such as AWS Foundational Security Best Practices. A failed control is strong posture evidence. It is not proof that the SOC can detect attacker behaviour.
That difference matters during coverage reviews. A control can say that CloudTrail should be enabled, that S3 public access should be blocked, or that IAM root access keys should not exist. Those findings describe risk or readiness. They do not show the SIEM alert that would fire if a stolen access key called ListBuckets from a new network.
Use two evidence labels when reviewing Security Hub: posture-control evidence and detection evidence. Posture-control evidence comes from the Security Hub control, standard, resource and compliance status. Detection evidence comes from CloudTrail, GuardDuty, SIEM rules, hunt queries or another log source that shows behaviour.
A failed control can still create SOC work. If Security Hub reports that CloudTrail logging is disabled in an account, the detection backlog is not 'write a Security Hub rule'. The backlog is to restore logging, test whether the SIEM receives CloudTrail again, then review detections that depend on that source.
Treat failed controls as triage prompts. Start with the affected resource, then ask what attacker behaviour the gap would hide or make easier. A public S3 bucket, disabled CloudTrail trail and unused admin access key all need different detection work.
The useful output is a small backlog item with an owner. It should name the AWS source to collect, the ATT&CK technique if one fits, the SIEM rule or hunt to test, and the posture fix that removes the exposure. This keeps Security Hub in its CSPM lane while still helping the SOC act.
def security_hub_evidence_kind(finding):
if finding.workflow_status == 'SUPPRESSED':
return 'posture-control:review-suppression'
if finding.compliance_status == 'FAILED' and finding.has_linked_cloudtrail_rule:
return 'posture-plus-siem-detection'
if finding.compliance_status == 'FAILED':
return 'posture-control:coverage-backlog'
return 'posture-control:passed'
Do not colour an ATT&CK cell green because a Security Hub control exists. Mark it as posture context unless the team can point to a detector over the relevant behaviour. For AWS identity work, that usually means CloudTrail or GuardDuty evidence, plus SIEM tuning where the customer owns the rule.
DCV helps by storing the evidence class beside the mapped technique. The practical value is the gap list: controls that are failing, detections that depend on missing logs, and rules that exist but have not been tested against the AWS field names the SIEM receives.