And the data leak trend continues … TechCrunch broke the news this week that PocketiNet, an internet provider based in Washington State, left an Amazon S3 bucket open for at least six months! “Worse, it took the company a week to shut off the leak, despite several phone calls and emails warning of the exposure.”
Very popular on the west coast, PoketiNet provides high-speed internet access to thousands of homes, local multi-national corporations, and hospitals across Washington state. Nonetheless, it’s time to add this company to the list of S3 bucket leaks that have exposed sensitive, personal information for hundreds of millions of people from around the world this year.
- Fed Ex
- National Credit Federation
- Australian Broadcasting Corporation
- Dow Jones
- Deep Root Analytics
According to MotherBoard:
PockiNet left 73 gigabytes of essential operational data publicly exposed in a misconfigured Amazon S3 storage bucket for six months.
Said bucket, named “pinapp2,” contained the “keys to the kingdom,” according to the security firm UpGuard, including internal network diagramming, network hardware configuration photos, details and inventory lists—as well as lists of plain text passwords and AWS secret keys for Pocket iNet employees.
How did these S3 Buckets get exposed?
We don’t know for sure, but often times the S3 Bucket configuration is incorrect. The created container permissions may have been too broad which allows anyone to access the data (as may be the case with PocketiNet). Again, their S3 Buckets may have been serviced by people who aren’t familiar with security, thus the developer who created the container was unaware of how to properly secure it, or it was something as simple as an oversight. For example, in PocketiNet’s case, they may have had a developer who was troubleshooting an issue that was causing an application to fail and suspected the S3 Bucket access was to blame. The developer may have tweaked the S3 configuration leaving it open to the public, and as the application began working again, moved on to another project. Now they have an exposed S3 Bucket. It may not have even been the developer’s fault as someone else may have altered the bucket’s configurations at a later date for any number of reasons. The point is, so many organizations are made vulnerable because a lot of them don’t have processes that prevent insecure software deployments.
How do organizations avoid S3 bucket leaks?
For starters, PocketiNet could have done nothing. Amazon S3 buckets are private by default and can only be accessed by users that have been explicitly given access. Again, by default, the account owner and the resource creator are the only ones who have access to an S3 bucket and key, so someone has to actively misconfigure an S3 to expose the data.
Amazon has been actively working to help companies avoid breaches caused by misconfiguration. In November 2017 AWS added number of new Amazon S3 features to augment data protection and simplify compliance. For example, they made it easier to ensure encryption of all new objects and monitor and report on their encryption status. They have also provided guidance on approaches to combat this issue, like the use of AWS Config to monitor for and respond to S3 buckets allowing public access.
As a most basic first step to avoiding S3 bucket leaks, take advantage of the native AWS capabilities. Ensure that you are always purposefully using AWS S3 access policies to define who can access the objects stored within. Ensure your team is well trained to never open access to the public, unless absolutely necessary, as doing so can result in the exposure of PII and other sensitive data. And help prevent unauthorized access to your data by taking advantage of capabilities like AWS Config.
The challenge is that many organizations struggle to adopt and enforce best practices consistently, and only 100% consistency can ensure protection against a breach. This is why an investment in cloud operations is a vital additional step.
Invest in Cloud Operations:
Cloud operations, or CloudOps, is the combination of people, processes, and tools that allow for organizations to consistently manage and govern cloud services at scale. Key to this is hiring and developing the right people, identifying processes that address the unique operational challenges of cloud services, and the automation of these processes with the right tools. One vital tool in your CloudOps toolkit should be software like DivvyCloud, that monitors and remediates cloud misconfigurations allowing you to achieve continuous security and compliance at scale.
In about 15 minutes, you can install DivvyCloud, connect your cloud (AWS, Azure, and GCP) accounts, quickly see S3 buckets that are misconfigured, and then turn on real-time continuous automated remediation of misconfigured buckets.
For example, using DivvyCloud, an organization will be able to leverage automation to remove the public permissions from the access control list where necessary. Users can also leverage bucket policies in place of access control lists for the finer-grained access control. This automation prevents data breaches by finding, alerting, and remediating misconfigured storage containers way before vulnerabilities are exposed.
It’s important to highlight that DivvyCloud not only flags the problem in real-time but gives the user an exact pointer to where the problem is. If somebody were to tell you “there is an open S3 bucket” but didn’t narrow down to a granular level, where would you start? This is why DivvyCloud alerts that there is an open S3 Bucket, then takes action and informs the user to exactly which bucket in which account.
In the end, the way to avoid exposing data in S3 buckets is really common sense: Don’t ever configure the S3 buckets to be exposed to the public. Organizations need to learn about security configurations while evaluating their public cloud options or pay someone else to do it for them. Otherwise, it’s only a matter of time before they join the 14 aforementioned organizations in the growing list of those who have to explain to their customers that their information has been compromised.
DivvyCloud mitigates security and compliance risk by providing virtual guardrails for security, compliance, and governance to customers embracing the dynamic, self-service nature of public cloud, and container infrastructure. Customers like General Electric, Discovery Communications, and Fannie Mae run DivvyCloud’s software to achieve continuous security governance in cloud and container environments (AWS, Azure, GCP, Alibaba, and Kubernetes). First, our software performs real-time, continuous discovery of infrastructure resources allowing customers to identify risks and threats. Second, customers can implement out-of-the-box or custom cloud-native policy guardrails that identify and alert on violations. Third, we automate the enforcement and remediation of these policies.