With each new open S3 bucket, a public cloud storage resource available in Amazon Web Services Simple Storage Service, come millions more customer and employee records that have been left open to the world, and potentially breached. But, open S3 bucket policies that enable anyone to access the data stored inside are only one part of the problem. There are other S3 bucket misconfigurations that could make your data and your cloud resources vulnerable to malicious activities.
Addressing these five items can help keep your organization’s data secure now and in the future:
- Fix your bucket list: What kind of information could possibly be gained by letting anyone see the names of your S3 buckets? That’s the question you must consider when deciding how to set the S3 bucket Global List permissions – seems harmless until you realize you have buckets named for each of your customers or buckets with labels like “Resumes 2018,” “Vendor W9,” or “Acquisition Research.” Don’t make it any easier for the bad actors to find your data treasures by allowing them to see the names of all your buckets. It’s like putting a treasure map in front of pirates; of course they’re going to go in search of the prize.
- Here today, gone tomorrow: There are two configurations that allow your S3 bucket to be wiped out by anyone with access. (If you care so little about this information, why store it in the first place?) The first, and worst, is a global delete permission, which allows anyone to delete the entire S3 bucket. Poof! Data’s gone. The second configuration allows the data to be deleted without multi-factor authentication (MFA). That may seem pretty innocuous, until you realize that if a bad actor got access to an entitled user’s account, that person could delete the files in just a couple of clicks. If you’ve gone so far as to enable strong access permissions on your ACL lists, go that extra step and enable MFA for delete, too. Clicking a button on your phone every time you want to delete something may seem like a drag, but it can save you countless headaches down the line.
- Open for the GETting: We’ve discussed global list, view, edit, and delete permissions; now here comes their nasty cousin GET. This is the setting that allows anyone or anything to go into the file and get all the data contained inside. Since the data will still be accessible by you and entitled systems, you may not even realize someone bad has gone in and accessed the data. But, with GET open to anyone, your data could be sitting in someone else’s hands just waiting for the right moment (like when the season of your biggest hit show is about to start) to send you a ransom note. Set rigorous access controls and ensure the GET setting is only usable by those required to have it on a regular basis.
- PUTting things in their proper place: You may not think global PUT permissions would be all that bad, but you’d be wrong. Here’s a scenario: a competitor guessing your namespace loads some of their corporate secrets into your S3 bucket and then notifies authorities, setting you up for an espionage charge. If that sounds too much like a Grisham novel, consider this instead: a hacker guesses at your namespace and drops malware into your bucket with the hope that you will eventually open it up and unleash its viral badness into your cloud environment. Those Global PUT permissions are seemingly harmless, aren’t they? You can fix this issue by clearly defining who and what systems have PUT permissions to S3.
- Not keeping tabs on S3: We hear this all the time: if everything is in order and secure, why do I really need to pay to store logs or old versions of documents? Well, just because everything is in order when you look, doesn’t mean that was always the case. Without logging turned on, how will you know that someone accessed your account, changed settings to allow them access to your S3 bucket, took your data, and then set the permissions back to the original setting? And, without versioning, would you know what the data looked like before a malicious insider went in and changed all your research test results to make you look like a fool later? Turn logging on so you know what happened when you weren’t looking. Turn versioning on for anything important. You’ll be thankful later.
S3 misconfiguration is a big problem. Even when you think you’ve been judicious, check your list again. When AWS accounts are scanned by Prisma Public Cloud, having globally accessible S3 buckets is one of the most common risks found, occurring way more often than any of us should feel comfortable about. The dynamic nature of the cloud means that settings change, buckets come and go, and mistakes will be made. If you operate under those assumptions and use automation to continuously monitor your S3 security settings, you’ll be sure to find – and fix – your vulnerabilities faster than the bad actors can exploit them.
Learn more about protecting AWS deployments here.