2017 was the worst year in terms of number of breaches and data compromises. By one estimate, there were 5,207 breaches in total, a 20% increase from the previous high in 2015. Cloud security incidents dominated headlines during the year, with Amazon Web Services (AWS) data exposures becoming a recurring theme.
Amongst the organizations impacted were Accenture, Dow Jones, Verizon, Republican National Committee (via their analytics partner, Deep Root Analytics), and Experian, just to name a few. In each case, the organization misconfigured their AWS S3 buckets containing highly sensitive or regulated data and left them publicly readable. Even more alarming was the fact that none of those breaches were perpetrated by outside bad actors but were instead rooted in avoidable mistakes that the organizations were making in the way they were using AWS.
And while we thought that our discovery of Ghostwriter would be a wake-up call for the industry to better secure their Infrastructure-as-a-Service (IaaS) platforms, this week FedEx became the latest self-inflicted victim of misconfigured AWS S3 bucket when thousands of FedEx customer data was exposed after the company stored scanned passports, drivers’ licenses, and other documentation on a publicly accessible Amazon S3 server. In total, 119,000 passports and photo ID’s were left unprotected.
The buckets belonged to Bongo International LLC, a company that aided with shipping calculations and currency conversations, and which was purchased by FedEx in 2014.
Understanding the AWS Shared Responsibility Model
Companies like FedEx need to be aware of the differing responsibilities required by an organization when using cloud services, per the shared responsibility model. With IaaS systems like AWS, the customer is responsible for securing the configuration and usage of the IaaS environment. They are also responsible for ensuring that S3 buckets are encrypted and not publicly accessible.
(You can read our blog post for a more detailed understanding of AWS shared responsibility model for security)
Ultimately, sensitive data stored in cloud services like AWS S3 buckets are as secure as their security configuration settings. Companies may have hundreds of S3 buckets and it’s their responsibility to persistently audit and correct misconfigurations. However, this process introduces the element of human error which is what happened with FedEx. Our own research shows that 7% of all S3 buckets have unrestricted public access, and 35% are unencrypted.
Why AWS S3 Data Continues to Be Exposed
Data leaks continue to occur due to the customer changing the default permissions before starting to use these buckets. S3 buckets can be created either manually or programmatically and misconfigurations are either an oversight on the part of admins or the relevant scripts granting excessive permissions. Default permissions on S3 buckets, once changed for temporary use, may never get reverted, thus leaving the door open for hackers to get access to sensitive data.
What adds to the problem is the lack of security controls enterprises have over third-party vendor-owned buckets. Employees from within the enterprise access these vulnerable S3 buckets, freely downloading and/or uploading information. This type of misconfiguration serves as an easy mechanism for hackers to tamper S3 buckets with malicious content, thus exposing the corporate network to potential ransomware or malware attacks.
An enterprise’s risk becomes a function of its vendor’s risk, stressed by the fact that some of the recent high-profile breaches such as FedEx were a result of misconfigurations of resources owned by the partner or acquired company and not the enterprise. Since the data is owned by the enterprise, in the minds of end-users, the enterprise will be held accountable for any data exposure.
Securing S3 Buckets and More with a CASB
McAfee Skyhigh Security Cloud is the only cloud access security broker (CASB) who can provide visibility into third party risk through our Shadow IT capability, and identify exposed S3 buckets. We also provide visibility into enterprise-owned S3 buckets that allow world read/write permissions and audit the entire AWS infrastructure.
A CASB is a dedicated security solution that can automate IaaS security audits across multiple instances and IaaS applications. Here are two steps companies can take to prevent these types of AWS data exposures:
- Understand where your sensitive data is stored at: Companies leverage McAfee Skyhigh Security Cloud to perform DLP across their IaaS services. Customers build DLP policies based on data identifiers, keywords, and structured/unstructured fingerprints to identify where their sensitive data is, so they can apply appropriate security controls. With this knowledge, you can pinpoint any S3 bucket that contains sensitive data and ensure it is adequately protected. DLP can also be used to monitor S3 buckets that are intentionally configured as public and unencrypted so that if sensitive data is uploaded to the buckets at a later date, the data can be blocked, and IT Security can be notified.
- Audit your security settings in AWS: AWS security settings are extensive, and each AWS service has its own unique security configuration options. Companies use McAfee’s CASB to monitor over 70 AWS security configuration settings across all AWS instances and flag those that are non-compliant with an enterprise’s ISMS controls and the risk profile of the IaaS deployment. In addition, McAfee Skyhigh Security Cloud provides recommendations and in-product remediation platform (based on industry best practices and Center for Internet Security (CIS) benchmarks) so customers can correct non-compliant configurations. Identifying and eliminating publicly accessible and unencrypted S3 buckets is low hanging fruit for IT Security that may help keep your company name out of the headlines down the road.
If you’d like an audit of the security configurations of your S3 buckets as well of the security configurations of your vendors’ S3 buckets, you can register for our free AWS Audit here.