This past summer, we witnessed yet another massive data breach due to a misconfigured AWS cloud instance, and hundreds of thousands of Capital One’s customers’ Social Security and bank account numbers were exposed as a result.
Smaller-scale data breaches like this occur frequently, and unfortunately, we’re bound to see more of these breaches in the future even though they’re easy to avoid. So why can’t we seem to prevent them? It comes down to intent and access.
When Backup Becomes Kryptonite
Let’s say you’ve just set up an Amazon S3 bucket. It’s got some customer data in it, but you’re not concerned because it’s just a backup. You also set permissions so that you’re able to access this backup from anywhere in the world, and over time, you continue to add more and more data to it. At a certain point, quite a bit of time has passed, and you’ve added so much to it, that you’ve stopped inspecting it. Its original permissions haven’t been verified since initial set-up, and you haven’t thought about what would happen if any of the data got leaked to the public.
Most of the time, the backup data that gets placed into an Amazon S3 bucket is harmless, but other times, it’s not. For example, suppose it contained your entire company’s Salesforce data: if that data were to be exposed, not only would your customer records now be out in the open, but perhaps your sales team also made a not-so-nice note about a particularly difficult prospect. Suddenly a bad situation is made even worse.
The “Any Authenticated User” Permission
Another reason we continue to witness data breaches as a result of public cloud instances has to do with permissions - specifically, Amazon’s definition of “any authenticated user.” Initially, you might think this means any user in your organization, but unfortunately, it actually means any user with an AWS account. Let’s face it, that’s just about everyone, including those who might have malicious intent when looking for public cloud instances to hack.
The good news is that Amazon has taken steps to mitigate this confusion, and it now features a disclaimer when setting up a public S3 bucket to ensure you truly understand the meaning of “any authenticated user”. However, it offers a good lesson to double-check the authentication permissions you’re putting in place before moving forward.
Three Steps to Solving the Problem
Now that we know the two main reasons why cloud instances get breached – not inspecting your backups and not double-checking user permissions – let’s talk about solving the problem.
First, you need to understand what you’re trying to do with the cloud instance in the first place. That may sound like a very basic principle, but as we explained earlier, what was initially meant as a backup can very quickly become a data dump for just about anything and everything.
Once you understand its purpose, then it’s time to think about rules and policies. Specifically, make sure you’re clear on who has access. If it’s just for backup, does it really need to be public in the first place? Maybe it’s best that only certain users have access to begin with.
Lastly, make sure to implement some type of monitoring that will continuously test the assumptions you’ve made around permissions and policies. The tools you put in place should alert you when something gets stored in a cloud instance that shouldn’t be, and if access levels change.
Similarly, in addition to automatic monitoring, it’s also important to implement a tool like a VA scanner. Vulnerabilities happen so quickly, and unless you’re planning to hit refresh on a vulnerability database every day, a VA scanner will ensure you’re always up-to-date.
There’s Some Good News Though
Cloud adoption will only continue to increase, but at the same time, so will awareness of the primary security issues. As a result, not only have more and more cloud security tools entered the market that are better and faster, but security teams are also now required to move at the speed of DevOps -- all leading to a vast improvement in how we set up and configure our cloud instances.