News emerged earlier in the summer that data relating to some six million Verizon® users had leaked online. Around the same time, data on some three million WWE® fans was found to be accessible to anyone who cared to look for it.
If you think those data numbers are big, try getting your head around this next one: 198 million records. That’s the figure that was “leaked,” when the personal information of every registered U.S. voter going back a decade or more was recently left open on the web.
What all three of these disclosures have in common was the data storage location: Amazon® S3™ buckets. Leaky Amazon S3 buckets, or storage servers to be more technically correct, were firmly in the media crosshairs.
So, what precisely was going on then? Multiple enterprises all discovering that information stored on Amazon S3 was being leaked to the public was never going to be good news for Amazon. In the cut-throat world of the cloud, even at the biggest end of the provider spectrum, this could be a reputational disaster. Assuming, that is, the Amazon buckets really were leaky.
Let's look at the Verizon case. Researchers from UpGuard™ concluded that the now closed security vulnerability was actually down to a company to which Verizon had outsourced customer service call facilitation. That company had collected the data and stored it in an incorrectly configured Amazon S3 server. Security for this bucket was set to public instead of private, so anyone with that public URL could access to all the data.
Misconfigured S3 bucket permissions were also behind the WWE and Deep Root Analytics voter data disclosures. Blaming Amazon might be the knee-jerk reaction, but it's the wrong one: Amazon secures these buckets as private by default. All three of these incidents were a case of user error. Someone, for whatever reason, had changed the security settings. So what lessons should you take away from this, and does Amazon escape scot-free as far as the direction in which the finger of blame is pointing?
Amazon isn't to blame but cannot escape some responsibility. The three recent cases I have highlighted are just the tip of the iceberg, and poorly configured S3 buckets are not exactly rare beasts. That cannot be coincidence when they are locked down out of the box, as it were. Indeed not, Amazon S3 configuration is something of a dark art for many it seems. If otherwise experienced administrators are getting confused by the configuration options, something is clearly wrong. Amazon itself must make the configuration process and documentation more intuitive; especially for the less technical-minded admins out there, of which there are many.
I have heard of admins making the assumption—and assumptions are always something to avoid when we are talking data security—that an 'Authorized User' will be from the organization itself. Yet authenticated users, as far as the AWS® S3 built-in group is concerned, includes any user with an AWS account. It doesn't take a ratified security consultant to grasp the insecurity in that. Of course, actually looking at the documentation would have avoided most of these leaky S3 problems. Admins trying to share data often think that making the bucket public is the solution, rather than using the appropriate permission controls. Familiarity does not breed security contempt, quite the opposite in fact.
So what lessons should be learned? Amazon needs to be reviewing its S3 buckets security policy, paying particular attention to the access controls. That means looking at Identity and Access Management (IAM) policy, and ensuring that bucket access is restricted to the fewest possible accounts. In the case of the private/public permissions conundrum—the only two options available to the bucket creator initially—the answer for data sharing is defining an IAM policy and creating an IAM user to share with. That user can then have fine-grained access permissions applied.
As I've already stated earlier in this article, all S3 buckets come configured as private by default. If this is changed to public, or shared, there should be a very good reason, and the potential privacy (as well as ongoing regulatory and compliance) implications should be understood.
Davey has been writing about IT security for more than two decades, and is a three-time winner of the BT Information Security Journalist of the Year title. An ex-hacker turned security consultant and journalist, Davey was given the prestigious 'Enigma' award for his 'lifetime contribution' to information security journalism in 2011. You can follow Davey on Twitter® at @happygeek
© 2017 SolarWinds MSP UK Ltd. All Rights Reserved.
Get the latest MSP tips, tricks, and ideas sent to your inbox each week.