S3 Bucket Exposure and CASB Blind Spot

Contain in an order that stops ongoing loss before preserving evidence:

1. Block the known-bad domain at DNS and egress. Umbrella or the firewall should sinkhole the domain and block its resolved IPs. DNS filtering alone is insufficient if applications use direct IPs, so add an egress rule for the observed destination.
2. Isolate the 42 endpoints, not the whole user population. Use EDR network containment and collect volatile data. Isolating all 900 users would disrupt the launch and is not supported by the evidence.
3. Remove public access from the bucket and audit for other public buckets. Apply account-level S3 Block Public Access where policy allows, and use AWS Config or an SCP to prevent regression. Do not delete the bucket or ACL history; snapshot the policy and CloudTrail events.
4. Rotate credentials for the developer role and review its trust policy. A PutBucketAcl by a role may indicate misuse or compromise. Rotate access keys and session tokens, then inspect CloudTrail for AssumeRole and GetObject patterns.
5. Preserve logs. Copy CloudTrail, VPC Flow Logs, Umbrella, and EDR telemetry to a restricted account before remediation changes metadata.

The 1.2 GB POST suggests data left the environment; the public-read window may be unrelated to the POST but must be scoped. Treat both as one incident until proven separate.

The failures are coverage and enforcement gaps:

• S3 Block Public Access was not enforced at the organization level. Six of 14 accounts had it, so a developer could set a public ACL in a remaining account. CloudTrail recorded the API call, but no event rule or Config rule evaluated PutBucketAcl against a public-read outcome. Logging is not detection.
• GuardDuty does not replace S3 policy governance. GuardDuty can flag suspicious S3 access, but it will not stop a deliberate public-read change and may not alert on the ACL itself.
• Split tunneling removed proxy visibility. Microsoft 365 direct routing is reasonable, but all other traffic must still traverse a secure web gateway or have equivalent DNS and endpoint telemetry. Umbrella DNS saw the domain but not the content or POST volume.
• The CASB was API-only and scoped to two SaaS apps. It had no AWS connector and no inline coverage, so it could not see S3 ACL changes or unsanctioned uploads.
• No data-loss control inspected outbound POSTs. DNS filtering can block a domain after discovery, but it does not classify 1.2 GB of uploads or prevent first contact.

The root cause is not one missing tool; it is absent preventive policy for public storage, absent alerting on sensitive API calls, and a visibility gap for direct-to-internet traffic.

Prioritize preventive controls that do not require re-architecting the launch:

Days 1 to 7: Apply an AWS Organizations SCP denying s3:PutBucketAcl and s3:PutBucketPolicy when public access would result, and enable account-level Block Public Access. Verify with AWS Config rules and a controlled test in a sandbox account. Create an EventBridge rule for public ACL or policy changes that pages security.

Days 8 to 14: Add an AWS connector to the CASB for configuration and identity visibility, and extend Umbrella or secure web gateway coverage to all traffic except explicitly approved Microsoft 365 breakouts. Verify by confirming DNS and egress logs for a test user and by reviewing a sample upload.

Days 15 to 21: Deploy an inline DLP or CASB control for uploads above a threshold, starting in monitor mode. Give marketing a sanctioned bucket and a pre-approved sharing workflow so they do not need public ACLs.

Days 22 to 30: Add CloudTrail Lake or SIEM correlation for AssumeRole plus unusual S3 access, and run a tabletop using the 42-endpoint scenario. Measure success by zero public buckets, alert latency under 5 minutes, and coverage of at least 95 percent of egress traffic. Keep exceptions documented and time-bound.