When it comes to cloud services, the name AWS is nearly synonymous with the public cloud. Although Amazon’s grip on the cloud might be loosening (however slowly), there’s no question that AWS with its estimated 47% market share is a cloud behemoth. This means that for many businesses, cloud security starts with AWS security. Within AWS, one very common cause of data insecurity is S3 bucket misconfigurations. Generally, this is the result of bucket permissions mistakenly being set too low, allowing for accidental exposure of a bucket’s contents to unauthorized parties or to the entire internet in a worst case scenario.
How common are bucket exposures? Exact numbers are fairly difficult to come by, although there is some literature about the issue. Back in 2018 researchers presenting at the Annual Computer Security Applications Conference found that of the 240,461 S3 buckets they discovered, about 14% (34,154) listed their contents publically. 80% of the 34,154 buckets listing contents contained readable files.
Changes to S3 access management options in late 2018 have likely significantly reduced the prevalence of S3 bucket exposure, though S3 leaks and breaches still dominate the headlines. In our Trends in Cloud Security newsletters this month and last month, we shared stories involving leaky S3 buckets.
The good news is that with a solid grasp of best practices for managing data within AWS and other cloud services, companies can continue to reduce the likelihood of data exposure within systems like S3.
Best practices for securing your S3 buckets
In order to stay on top of S3 security, companies and practitioners need to develop a holistic mindset that incorporates evaluating not just their S3 bucket permissions but their data policies and other practices. You should consider the following:
Maintain consistent bucket permissions
By default when you set up an S3 bucket today, it is private and permissions must be created to explicitly allow access to the bucket. As a best practice, your bucket should stay this way unless your goal is to create a public-facing bucket. Even assuming you limit public permissions to be read-only, you’re putting your organization’s data at more risk than necessary. If you need to provide access to your bucket, use your access control lists to grant groups or individual users (via their ID) permissions at the bucket or object level. By doing this you’re ensuring that you’re following the principle of least privilege and reducing the chance for security errors or abuse of your data.
Misconfigurations aren’t the only risks to securing S3 buckets, as we’ve noted. But while S3 security doesn’t end with permissions management, it is undoubtedly an important starting point.
Construct comprehensive data policies to help mitigate security incidents
When using cloud services, it’s a good idea for your organization to have policies that inform how teams configure and use cloud platforms. What your policies look like will ultimately depend on what cloud services you’re using and what business objectives and regulatory obligations your company has. For instance, to comply with the CCPA, you may decide to only store PII in S3 buckets that do not contain public objects to reduce the likelihood of accidental exposure. Your data policies will play a role in determining the behaviors that are and are not acceptable for employees managing buckets with PII — like moving data to a public-facing bucket or turning an object with PII into a public object.
Keep an eye on your data and automate policy enforcement
Having policies is only half the battle, as you’ll need to enforce them in your cloud environments. Because it’s unrealistic to expect security teams to be able to see and address every single violation of your organization’s data policies, you’ll need tools that can aid you in doing so. That’s where data loss prevention solutions, like Nightfall, come into play. Nightfall specifically provides real-time active scanning of S3 for PII, PHI, and other types of common sensitive data found within files stored in S3 buckets. Nightfall can also connect with systems like Amazon CloudWatch to notify teams of changes to files so that you can tell what’s happening within these environments. Automation isn’t meant to encourage security teams to take a hands-off approach to information security, but to allow them to focus their attention on the incidents and threats that really matter. Tools like Nightfall make this possible through automated data discovery and classification.
Manage your AWS credentials
You’ll want to secure not just your AWS environment, but any other environments where you pass or store AWS credentials. For example, if your engineers use a code repository like GitHub and store AWS tokens or hardcode AWS keys, it’s possible to commit these into a repo that is public or that can be breached. This is exactly what happened to Uber back in 2016, resulting in a breach that ultimately cost the company $148 million in fines. Uber by no means is an isolated case, either. We shared two stories in our February cloud security newsletter, one of which involved an AWS engineer at Amazon committing secrets potentially linked to internal systems. According to literature on the subject, as well as our own research, credential leaks of this nature are extremely common and likely happen daily. To minimize the chances of this happening, your organizations should scan your repositories before commits. Tools like our platform, Radar, can aid in doing this.
Commit to securing your cloud infrastructure
Ultimately, securing cloud services and infrastructure is something that requires a commitment from organizations. This is advice that we’ve stated before but is worth repeating. Part of this commitment involves adapting what we call a “security-first, cloud native” mindset. Cloud systems aren’t like on-prem systems and face an entirely different set of threats. As such, companies are likely going to continue to find that they’ll need to commit to securing cloud systems and infrastructure before investing in them. This means making sure that data policies exist ahead of cloud adoption, as well as looking for security tools designed specifically for the cloud to maintain data visibility and data policy remediation within these environments.
Nightfall is the industry’s first cloud-native DLP platform that discovers, classifies, and protects data via machine learning. Nightfall is designed to work with popular SaaS applications like Slack & GitHub as well as IaaS platforms like AWS. You can schedule a demo with us below to see the Nightfall platform in action.
“This article is originally posted on Nightfall.io”