Do you know how your AWS S3 bucket is configured?
Dow Jones joins the list of those whose Amazon Web Services S3 data buckets have been a bit too prone to slosh over (Dark Reading). Estimates vary, but Dow Jones thinks 2.2 million individuals' information was exposed.
The Verizon data exposure, discovered by UpGuard on June 8th, has been attributed to a third-party vendor, Nice Systems, which misconfigured an AWS S3 bucket holding data collected in the course of customer service calls (Register). Investigators are attributing the cause and duration of the incident to a failure to communicate (which seems Cool-Hand-Luke-ish), exacerbated by happenstance: a Verizon security employee whom researchers contacted was on vacation (DSL Reports). Thus although Verizon was notified on June 13th, the data remained unprotected until June 23rd. UpGuard thinks that's too slow (Channel Partners).
The other major data exposure cases recently have involved the US National Geospatial Agency, and the Republican National Committee, both traced to third-party contractors. Legal observers are drawing lessons concerning third-party due diligence from the incident (Corporate Counsel).
Amazon Web Services on Wednesday sent its customers a reminder that Access Control Lists (ACLs) govern who can see the contents of their S3 buckets, and that they should look at their buckets to insure that public read-access is enabled only where it's supposed to be. Misconfiguration, often by third parties, has hit data held by large organizations hard this summer, but AWS wants customers to remember that protecting information from inadvertent exposure isn't that hard. And, moreover, that securing that information is the customer's responsibility. The cloud, after all, is formed for sharing, and it's up to those who put their data there to ensure sharing is among authorized parties.
It's not clear any of the data exposed have been stolen, but no sensible enterprise is happy rolling the dice.