The Bucket, the Log Gap, and the Board's Question
Yewstack is a 500-person SaaS company running 42 AWS accounts under an organization formed by two acquisitions. CloudTrail is enabled in 30 accounts; GuardDuty in 12; S3 Block Public Access is enforced at the root but two acquired accounts were never enrolled. On Monday a security researcher reports a bucket containing 180,000 customer support attachments readable without authentication; it had been public for an estimated 11 weeks. CloudTrail data events for S3 are off. VPC flow logs ship to a SIEM, but ingestion licence caps mean roughly 40% is sampled or dropped during business hours. The detection library holds 1,100 rules; 800 have never fired. Two cloud security engineers, a 90-day remediation mandate from the CTO, and a board question about whether the company would even know if customer data left.
1. What can you actually determine about the 11 weeks of exposure, and what would you enable or query today to answer the board's question honestly?
Read the worked answer
Honest answer: probably very little from the bucket's own logs, and that gap is itself the finding.
Check immediately:
- S3 server access logs, if logging was ever enabled on that bucket. Frequently it was not.
- CloudTrail data events for S3 are off, so GetObject history likely does not exist. Management events still show PutBucketPolicy and public-access-block changes, which dates the misconfiguration and names the principal.
- Bucket policy and ACLs, plus organizational enrolment - the two acquired accounts sat outside the root SCP, which explains the exposure.
- VPC flow logs, DNS logs, GuardDuty findings, and NAT or egress data for large transfers to unfamiliar destinations.
- Content classification: 180,000 support attachments plausibly include identity documents and payment data, which changes the notification analysis regardless of access evidence.
Enable today, before cleanup: organization-wide CloudTrail with S3 data events into a locked log-archive account, Block Public Access enforced by SCP in every account including future ones, and access logging on the bucket.
To the board: 'we can say the bucket was public for about 11 weeks and who could have read it; we cannot yet prove whether anyone did. The telemetry that answers that question is now on, and here is the notification timeline we are working to.' That is more defensible than a confident denial that later collapses.
2. Rank the 90-day remediation backlog and justify the order using risk logic rather than tool preference.
Read the worked answer
Order by which failure makes every other control irrelevant:
- Exposure and identity surface: enforce Block Public Access org-wide by SCP, remove the public policy, rotate any credentials found in or near the bucket, and close the acquired-account gap. A public bucket is an active leak; nothing competes with it.
- Detection completeness: organization-wide CloudTrail to an immutable cross-account log archive with object lock, covering all 42 accounts and all regions including unused ones. Without this, every later control is unverifiable after the fact.
- Threat detection coverage: GuardDuty delegated administration across the organization, plus Config or Security Hub rules for the baseline. This catches credential abuse and crypto-mining that raw logs will not surface.
- SIEM pipeline integrity: fix the 40% drop before adding rules. Sampling under load means existing alerts are unreliable, so filter to security-relevant fields, tier hot and cold storage, and alarm on ingestion gaps themselves.
- Detection lifecycle: ATT&CK coverage mapping, rule ownership, and quarterly adversary-emulation validation.
The two engineers should not be authoring new detections in week one. Log truth and exposure closure come first; an elegant rule set over missing logs is a false sense of assurance, and the board's question is precisely about assurance.
3. Is 1,100 rules with 800 silent a staffing problem or a governance problem? What would you measure and report monthly?
Read the worked answer
Governance, mostly. Eight hundred silent rules means nobody owns the detection library, nobody retires anything, and nobody notices when a rule stops working because a log source changed. Adding analysts to an unmanaged library just produces more unread alerts - staffing treats a symptom.
Monthly measures:
- Coverage against a technique framework, not rule count. Rules per ATT&CK technique, and which techniques have no detection at all.
- Rule health: last fired, last tuned, named owner, false-positive rate. Anything unfired for 90 days is retired or explicitly justified as a known-good control rather than left as clutter.
- Detection efficacy from scheduled adversary emulation: time to detect per scenario, which is the number that actually answers 'would we know?'
- Log source completeness and ingestion gaps, by source and by account.
- Mean time to detect and acknowledge, and the alert-to-incident conversion rate.
Then attach accountability: a named detection engineering owner, a monthly review, and a change process for rule edits. Report to the CTO as techniques covered, scenarios detected, and gaps formally accepted with an owner and a date - not as '1,100 rules, 800 quiet', which reads as activity rather than assurance and invites exactly the board question Yewstack is now facing.