Twelve thousand high findings, four people, and a ninety-day zero target
A media company accumulated 12,400 high-severity posture findings in 21 days across three clouds, with a four-person cloud security team. Top policies: public S3 buckets, 480 findings; security groups open to 0.0.0.0/0 on 22 or 3389, 610; IAM users with administrator policy, 190; unencrypted EBS volumes, 1,300. Data security classification shows 60 of the public buckets hold regulated data, and 12 of those have been internet-reachable for more than 30 days. Attack path analysis shows a reachable path: an internet-facing EC2 instance with an administrator instance profile to a bucket containing customer PII. A product team asks to suppress the public-bucket policy org-wide because all of their buckets are intentionally public CDN origins. The board has asked for zero high findings in 90 days.
1. Respond to the ninety-day zero target. What do you commit to, and how do you measure it?
Read the worked answer
Zero high findings is the wrong target because it is achievable only by suppression, and suppression converts a visible risk into an invisible one. Say that explicitly, then offer a target the board can hold you to.
Commit to reducing risk, measured in resources, not findings:
- 30 days: close the reachable-with-sensitive-data set. The 12 internet-reachable public buckets holding regulated data and the EC2-to-PII attack path first, then the open management ports attached to instances that have public IPs and privileged roles.
- 60 days: bulk-remediate the mechanical classes. Unencrypted EBS and account-level public-access blocks are automatable at scale, which is where the largest count reduction comes from.
- 90 days: every remaining high finding has a named owner and either a remediation date or a documented acceptance. Report the accepted-risk count openly.
Metrics to publish: number of resources exposed to the internet with sensitive data, number of exploitable attack paths, mean age of high findings by owner, percentage auto-remediated, and exception count with expiry. Also report findings per unique resource, since 12,400 findings across a smaller resource base means duplicate evaluation, not 12,400 separate mistakes. Changing the unit of measurement is what makes the number tell the truth.
2. The product team wants the public-bucket policy suppressed for the whole organization. How do you handle that request?
Read the worked answer
Refuse the org-wide suppression and counter with a scoped exception plus a design conversation.
First test the premise. A CDN origin should normally sit behind the CDN with origin access control and bucket-level public access blocked, so the claim that buckets must be public may be a workaround rather than a requirement. Verify a sample: are these buckets served directly, or behind CloudFront? Is direct public access actually needed, or is it habit?
If some genuinely must be public, the acceptable control is an exception, not a suppression:
- Scope it to specific bucket names or to a tag, so it cannot silently cover new buckets.
- Set an expiry (90 days) and require the product owner as approver.
- Keep a companion low-severity policy that still reports public buckets so visibility is retained and the next new public bucket triggers an alert.
- Require that regulated-data buckets are excluded from the exception unconditionally.
The difference matters operationally: a suppression removes future detection with no owner and no review date, while an exception is auditable, expires, and re-alerts on change. Document the decision and the residual risk in the exception record so the choice is attributable if it ever goes wrong.
3. Which of these finding classes would you auto-remediate, and what guardrails make that safe?
Read the worked answer
Split by reversibility and blast radius.
Auto-remediate: enable default encryption on volumes and buckets; enable account-level S3 public-access block; remove a public ACL on a bucket that is not in the CDN exception; close 0.0.0.0/0 ingress on 22 and 3389 where the rule has no justification tag; remove a public snapshot permission. These are reversible, well-understood API calls with no data loss path.
Never auto-remediate: IAM policy or role changes (you can lock out automation or break production), resource deletion including unattached volumes and old snapshots, anything touching DNS, and changes in production during a release freeze.
Guardrails that make the difference between automation and an outage:
- Run in dry-run first and diff intended versus actual changes for two weeks.
- Scope by tag and account, starting with non-production.
- Require a named owner per auto-fix rule and an approval step for production.
- Capture the prior configuration and a snapshot where state is involved, so rollback is a documented click rather than an improvisation.
- Rate-limit changes and suppress them during declared freeze windows.
- Track false-positive remediation rate; if a rule keeps hitting legitimate configurations, the rule needs tuning, not more force.
The test is simple: could this change take down a revenue path at 2 a.m. without a human in the loop? If yes, it is not an auto-fix.