Cloud Can’t Protect You Against Yourself

Cloud security. The term itself is actually meaningless without qualification. Do you mean the security of the underlying infrastructure that makes up “cloud”? Or perhaps of command and control APIs that let you provision and manage compute, storage, and services in the “cloud”?

Because I know you weren’t thinking of its ability to magically protect you against your own missteps. You know, the ones where you purposefully change the default security policies on Amazon S3 buckets to allow anyone with the IP address to access the data it stores.

If you’re thinking that’s a ludicrous notion, you’d be right. But you’d be wrong to think that means organizations with decent security chops haven’t done just that.

Case in point: it was recently revealed that a certain systems integrator had left all sorts of juicy data open and available in Amazon S3. You know, stuff like credentials and private keys and all that. The ‘error’ was quickly remedied, we are told, but the fact remains that in order to arrive at a state in S3 that it is open to anyone requires action on the part of an operator.

You must consciously unlock the door. Amazon S3 by default is provisioned with strict security controls with respect to access. From Amazon’s documentation:

By default, all Amazon S3 resources are private, which means that only the resource owner can access the resource.

-- Setting Bucket and Object Access Permissions

So to get it into a state where anyone with the right IP address can browse a bucket’s contents takes conscious action on the part of a human being.

The SI in question isn’t the first to fall victim to their own un-securing of Amazon S3. Back in February 2017, researcher Troy Hunt detailed a fascinating serious of bungled cloud security events related to an IoT toy, Cloud Pets. This included “an Amazon S3 bucket with no specific authorisation required.” Back in July we learned that one of the big three service providers exposed subscriber records via misconfigured Amazon S3.

To illustrate just how pervasive this problem is, Rhino Security Labs offered a fascinating view of its testing of Amazon S3 across the Alexa Top 10000 sites. It found “107 buckets (1.07%) were found with list permissions belonging to 68 unique domains. Of these 107 buckets, 61 (57%) had open download permissions to anyone who viewed them. 13 (12%) had open upload permissions, and 8% had all three.”

Open download is bad enough, as it exposes data to theft. But open upload, too? That’s like encouraging employees to click on phishing e-mail.

Cloud cannot protect you against yourself. Whether it’s a lack of security gates, checks, or oversight, you can’t simply open up permissions on cloud storage and hope that no one will find it. That’s like installing a CCTV and leaving telnet access open to the outside world.

Oops, eh?

Here’s the thing. Apps and data are only as secure as the policies and procedures you use to protect them. There are legitimate reasons for cloud storage like S3 to enable “open” access. But just like ports on your corporate firewall, you shouldn’t set them to wide open unless there is a darn good reason. 

If you haven’t instituted some sort of policy that requires a review of “cloud security” before you turn that app on or share that URL, you need to. Right now. Like, stop reading and go get working on that.

Don’t be your own worst enemy. Check your policies and procedures, and make sure that they align security with the importance and designated use of data you’re storing in the cloud.

Only you can prevent S3 misconfigurations from becoming headlines.

If you need help locking down Amazon S3 buckets, Amazon thoughtfully provides not only documentation but tools to help.