Modern organizations are increasingly looking to cloud platforms to drive innovation and growth off the back of enhanced IT efficiency, agility, and cost savings. There’s just one problem: they’re doing so in a way which threatens to expose the company to major leaks and breaches of sensitive data.
A new report out this week hints at part of the problem: companies lack a way of effectively auditing their cloud infrastructure for configuration mistakes.
A shared responsibility
Cloud is the engine of modern business growth. It provides cheap computing power on-demand for organizations to test and host the applications that are the gateway to innovative new services for customers.
Even better, cloud infrastructure (IaaS) enables developers to quickly change, update and add new functionality to apps in response to ever-changing customer demands, via DevOps processes. This kind of agility ensures they’re able to stay ahead of the competition in the insatiable race for new functionality and customer-facing services.
However, securing the cloud is a shared responsibility. While the platform provider will protect the underlying infrastructure, businesses themselves must protect the operating systems and applications they run on top. This includes data stored in Amazon Web Services (AWS) S3 and similar platforms.
What’s the problem?
Unfortunately, these data stores are only as strong as their weakest link, which invariably is a human administrator. When an S3 “bucket” is configured to be open to the public, anyone with an internet connection can access that data as long as they can locate the link – no fancy malware or hacking techniques required.
If you happen to be running hundreds of these buckets in AWS, and many more across other providers like Microsoft Azure and Google Cloud, the odds rise of misconfiguration leading to serious leaks.
According to one security vendor, 7% of all S3 buckets are being left completely open to possible online intruders, and 35% are unencrypted. Sometimes buckets are also left open to any “authenticated AWS user”: which means any hacker could register an AWS account to freely access the data.
A roll call of data leak disasters
The past few years have seen a sharp increase in the number of organizations exposing themselves and their customers via such simple mistakes. Even big names that should know better have been caught out, including the US Department of Defense (DoD), tech giant Verizon, and Accenture. Often it is the fault of a third-party service provider or contractor.
Here are just a few examples:
- Over half a billion (540m) records belonging to Facebook users were exposed via publicly accessible Amazon S3 buckets used by two third-party apps
- DoD contractor Booz Allen Hamilton leaked 60,000 files including passwords which could have enabled users to view Top Secret documents
- California-based data analytics firm Alteryx leaked personal identity data on 123m Americans, including US Census and Experian credit reporting data
- Sensitive data on 198m US voters was left exposed by a firm working on behalf of the Republican National Committee
From leaks to breaches
Most of the incidents publicized thus far have been of security researchers highlighting configuration mistakes which have then been addressed with no apparent impact on the firm in question. But it’s only a matter of time before cyber-criminals use the same techniques to gain easy access to sensitive customer data and potentially even corporate IP and trade secrets.
Hackers could sell the data to the highest bidder on the cybercrime underground, or even delete the stolen info and extort a ransom from the victim organization. The latter tactic has already been used by some crime groups.
How to get better
According to that new McAfee research, only 26% of IaaS-using organizations worldwide said they could audit configuration settings, like open access to storage buckets. So how can firms overcome these security challenges to keep sensitive data under lock and key?
The good news is that it’s easier than you might think. Here are some suggestions:
- Don’t touch anything: Amazon S3 buckets should be configured as private by default
- Draw up new security policies to restrict who can access and change cloud infrastructure settings
- Strictly enforce these policies
- Take advantage of enhancements AWS introduced in November 2018 to reduce the chance of misconfigurations
- Use a Cloud Access Security Broker (CASB) to locate sensitive data and audit configuration settings
- Apply the same policies and procedures to third-party suppliers