On June 1, 2017, a routine settings update on an Amazon S3 bucket owned by data firm Deep Root Analytics flipped its access control from private to public. For thirteen days, anyone with the bucket's URL could download 1.1 terabytes of data covering roughly 198 million American voters — names, dates of birth, home addresses, and modeled ethnicity and religion scores built for a Republican National Committee-contracted analytics project. Security researcher Chris Vickery of UpGuard found it on June 12 and the bucket wasn't secured until June 14. Weeks later, a second S3 bucket — this one managed by call-center vendor Nice Systems on behalf of Verizon — turned up world-readable, exposing account details and customer PINs for a reported 6 to 14 million subscribers, again found by UpGuard, again not locked down for over a week after discovery. Both incidents trace back to the same root cause: a storage bucket set to allow public read and list access, sitting outside the primary organization's own security review. Nearly a decade on, that exact misconfiguration pattern is still the leading cause of large-scale cloud data leaks. This post walks through what actually happened in both cases and the hardening checklist that would have stopped either one.
Why do misconfigured S3 buckets keep causing headline breaches?
Because the default failure mode of object storage is silent and reversible only by someone who's looking for it. An S3 bucket's access control list and bucket policy are configuration, not code — nothing breaks when a bucket goes public, no alert fires by default, and no deploy pipeline blocks it. A bucket can sit exposed for days or years with zero symptoms until an external researcher or an attacker stumbles onto its name. Both the Deep Root Analytics and Verizon/Nice Systems incidents were found by the same outside security firm, UpGuard, actively scanning for open buckets — not by internal monitoring at either company. That pattern, an external party discovering the exposure before the data owner does, recurred across a wave of similar S3 leaks throughout 2017. The underlying tooling gap is what makes this a repeat failure rather than a one-off: teams provision storage constantly, permissions drift as projects change hands, and without continuous, automated checking of public-access settings and bucket policy, a single wrong flag on a single bucket is indistinguishable from a working one until someone downloads the data.
What actually happened in the Deep Root Analytics leak?
A permissions change made on June 1, 2017 set the "dra-dw" S3 bucket, belonging to Republican data contractor Deep Root Analytics, to allow public access. The bucket held 1.1TB of files containing voter-modeling data on an estimated 198 million US voters, compiled from a mix of voter rolls and third-party data to build ethnicity, religion, and issue-preference scores used for political targeting. Chris Vickery at UpGuard discovered the exposed bucket on June 12 and reported it; Deep Root Analytics secured the bucket on June 14, meaning the data was downloadable by anyone for roughly thirteen days. No credentials or hacking were required — the files were retrievable with a standard HTTP request to the bucket's public URL. The scale made it, at the time, one of the largest exposures of US voter data on record, and it illustrated a specific risk of the political-data supply chain: a single subcontractor's storage misconfiguration exposed data aggregated from dozens of upstream sources at once, none of which had direct visibility into how their contributed data was being stored.
What made the Verizon/Nice Systems leak different — and worse?
The Verizon leak, disclosed in July 2017, involved a bucket that belonged not to Verizon but to Nice Systems, a third-party vendor Verizon used for call-center operations. UpGuard found the world-readable bucket on June 8, 2017, containing customer names, addresses, account details, and — notably — the account PINs used to authenticate callers to Verizon support, covering a reported 14 million customer records (Verizon disputed the figure, putting it closer to 6 million). What makes this case a sharper lesson than Deep Root is the remediation timeline: even after UpGuard notified Nice Systems and Verizon of the exposure, the bucket wasn't secured until June 22 — a nine-day gap between disclosure and fix. That gap points to a second, distinct failure mode beyond the initial misconfiguration: an incident-response process that couldn't move quickly on a vendor-owned asset, because the affected company didn't have direct operational control over the storage it was ultimately accountable for.
Why do third-party and vendor-managed buckets slip through security review?
Vendor-managed storage sits in a visibility gap by design: it exists in the vendor's cloud account, under the vendor's IAM policies, provisioned on the vendor's schedule — and the customer whose data lives there typically has no inventory entry for it at all. Verizon didn't misconfigure the bucket that leaked its customers' PINs; Nice Systems did, and Verizon had no automated way to know the bucket existed, let alone that it was public. This is the same blind spot security teams now call a "shadow store" — a data store present in a cloud account (or, in the vendor case, in someone else's cloud account holding your data) but absent from the organization's managed inventory. Contractual data-handling clauses don't solve this on their own, because they don't tell you the current state of a bucket's ACL at 2am on a Tuesday. Only continuous, automated discovery — enumerating buckets and checking public-access settings on a recurring basis, not at contract-signing time — closes the gap that let both the Deep Root and Nice Systems buckets stay exposed as long as they did.
What does a hardening checklist that actually prevents repeats look like?
Five controls, applied continuously rather than once, would have prevented both incidents: (1) block public access at the account level by default, using S3 Block Public Access or equivalent, so a bucket-level ACL mistake can't override org policy; (2) require encryption at rest on every bucket holding customer or voter-scale PII, so a public-access failure doesn't also mean plaintext exposure; (3) run continuous discovery against every cloud account you have credentials for — including accounts owned by data-processing vendors where contractually possible — because a bucket you don't know about can't be checked; (4) alert on public-access and bucket-policy changes in near-real time rather than relying on periodic audits, since both leaks existed for well over a week before discovery; and (5) define a remediation SLA for exposure findings measured in hours, not the nine days Nice Systems took after Verizon was notified. None of these five require exotic tooling — they require treating storage configuration as a continuously monitored control surface instead of a one-time provisioning decision.
How Safeguard Helps
Safeguard's Data Security Posture Management (DSPM) connects directly to live S3 buckets and RDS instances and records exactly the posture data that would have caught both incidents early: encryption status and public exposure, covering access controls, public-access settings, and bucket policy. DSPM's discovery step specifically flags shadow stores — a store present in a cloud account but absent from your managed inventory — which is the same blind spot that let a vendor-owned bucket expose Verizon customer PINs for weeks. Exposure findings fire automatically when a classified store is public, unencrypted, over-shared, or reachable across a tenant or account boundary, and because these findings reveal where sensitive data sits and who can reach it, they're held under elevated access control with every read audited. Paired with a defined remediation SLA, that turns "a researcher found our exposed bucket" back into "our own pipeline found it first."