Last reviewed:
A practical route from S3 exposure findings to SOC detection coverage, with posture signals kept separate from object access and exfiltration telemetry.
S3 exposure work goes wrong when every signal is treated as the same kind of evidence. A public bucket policy, a failed Security Hub control and an object read by an unknown principal are different facts. The first two describe configuration risk. The third can show access to data.
Keep those lanes separate in the coverage model. Posture evidence says a bucket could be reachable because public access blocks, bucket policy, access control lists or account-level settings permit it. Audit-log evidence says a principal called an S3 API. Exfiltration evidence needs object access volume, caller context and destination clues rather than a public flag alone.
Start with AWS sources that can answer different questions. Security Hub and AWS Config help find exposed buckets. CloudTrail management events show policy and logging changes. CloudTrail S3 data events show object-level API calls when collection is enabled for the bucket. S3 server access logs can add requester, bucket, object key and HTTP details, although many teams prefer CloudTrail data events for SIEM routing.
GuardDuty adds managed findings for suspicious S3 activity, including discovery, exfiltration and impact families. Treat those as managed-finding evidence. They help triage faster, but they do not replace the need to know which buckets emit object-level events into the SIEM and which parser fields the detection actually receives.
A failed S3 posture check should not become a vague SOC task. Translate it into the behaviour that an analyst would need to see. If a bucket is public, ask whether the SIEM can detect policy widening, external object reads, high-volume GetObject calls, unusual ListObjects activity and logging tamper for that bucket.
This is where coverage prioritisation matters. A marketing image bucket and a customer document bucket should not receive the same detection work. Rank by data sensitivity, internet exposure, business owner, prior access patterns and whether object-level events are already collected. The backlog item should say which missing source, rule or tuning decision blocks honest coverage.
ATT&CK mapping should reflect what the evidence proves. A Security Hub control that says public access is allowed is posture context. A CloudTrail data event showing GetObject by a suspicious principal is audit-log evidence. A GuardDuty Exfiltration:S3 finding is managed-finding evidence. A tuned SIEM rule with parser validation is SIEM-detection evidence.
That labelling prevents a common reporting error: marking Data from Cloud Storage as covered because a bucket policy scanner exists. The scanner can find exposure, but it cannot prove object access. Count T1530 coverage only when the team can point to object reads or managed findings that describe data access. Count T1619 only when bucket or object enumeration is visible, usually through ListBuckets, ListObjects or GuardDuty discovery detail.
def s3_evidence_kind(signal):
if signal.source == 'security_hub' and signal.control_family == 's3_public_access':
return 'posture-context:exposure'
if signal.source == 'cloudtrail_data' and signal.event_name in {'GetObject', 'HeadObject'}:
return 'audit-log:T1530'
if signal.source == 'cloudtrail_data' and signal.event_name in {'ListBuckets', 'ListObjects', 'ListObjectsV2'}:
return 'audit-log:T1619'
if signal.source == 'guardduty' and signal.finding_type.startswith(('Exfiltration:S3', 'Impact:S3')):
return 'managed-finding:review-s3-data-access'
return 'correlation-context'
Review S3 detection coverage whenever a sensitive bucket is created, public exposure is found, data-event collection changes or an incident shows object access that the SOC did not alert on. The review should test both collection and logic. A rule over GetObject is not useful if the bucket is outside the data-event selector or the parser drops the object key.
A good review asks five questions: which exposed buckets hold sensitive data, which buckets emit object-level events, which detections separate listing from reads, which GuardDuty S3 findings already route to the SOC, and which posture fixes remove the exposure. DCV helps by keeping those evidence labels beside the mapped techniques, so a green cell does not hide a missing log source.