| Another day, another valuable dataset found unprotected on Amazon Web Services. How many of these stories have I seen in the last year? I would like to bring attention to a very revealing post from Dark Reading: https://www.darkreading.com/cloud/amazon-s3-bucket-leaks-expose-classified-us-veteran-data-/d/d-id/1329802? What is with this? |
|
When a company contracts with a public source code service, they are trusting corporate intellectual property with that service. If their programmers create a new repository, they might expect acces would be limited to that company. I did - and I was wrong.
White hats (legitimate penetration testers), gray hats (freelancers looking for a reward for helping companies close holes), and you can bet black hats are scouring all sorts of cloud data stores. They are looking for problems - and they are finding them, over and over and over again. Ten major problems this year?
Why does it seem that cloud providers make it so easy for their paying customers to post their data where anyone can see? Is this a default setting? Do they make it too difficult to say "I only want to share this data with this organization"? Do they allow unrestricted use of "sharing" URLs to access data? Do they have too predictable a scheme of URLs?
I would certainly admit that companies like Time Warner, TalentPen, and their partners have substantial responsibility in these disclosures. But there are very reasonable expectations that most of us programming and IT professionals have when we have contracted a service to hold our data.
Services like Google Drive, DropBox, Amazon, and others simply cannot treat their customers' storage as if they are just another public-facing web site that anyone can spider and scour and read at will. Authorization is not new, and it's not rocket science. These are what we should be able to rely on:
- Every new folder, bucket, repository created on a company account must, at the very least, be inaccessible to those who do not have subsidiary accounts for that company.
- Any URLs identifying those locations must be completely meaningless to anyone outside the company if disclosed - even if the disclosure is intentional.
- There must be no "common root" or common syntax of server hosts or paths in the cloud service to allow spelunking across buckets and across companies.
- Directory listing should be disabled by default in all cases
- When a customer shares a folder or file outside the company, that object's URL should have a unique path for each party with which it is shared, and it must have a substantially different path (and ideally a different host) from what it has within the originating company.
- Every session making use of a cloud resource must be strongly identified and analyzed, including not only the session user's identity, but also traceroutes and transport rates, to assess what is involved with each access.
None of this is to minimize the importance of protecting from insider cybercrime, nor the importance of careful administration. But the whole premise of these cloud services is to reduce administration and allow end-users to have access to resources without needless obstacles or inconvenience. The threat of an insider, moreover, is exfiltration and disclosure outside the company. It is crucial that cloud service providers pull on their boots and step up to the essential step of implementing the real isolation of corporate data that their services have always promised to their paying customers.