You’re One Cloud Misconfiguration Away from a Data Breach

You’re One Cloud Misconfiguration Away from a Data Breach

Don’t assume that cyberattacks are all you have to worry about. Misconfigurations are also a top cause of concern.

Not all instances of data exposure in the cloud are the product of malicious intentions from either internal or external actors. In its 2019 Data Breach Investigations Report (DBIR), for instance, Verizon Enterprise showed that errors constituted one of the top threat actions in the data breaches it examined. Verizon’s researchers attributed 21% of those incidents to misconfigurations, which are now one of the most common ways by which digital criminals can “land” and gain a foothold into your Infrastructure-as-a-Service (IaaS) environment.

This blog post will examine what a misconfiguration looks like in the cloud. I’ll then examine why misconfigurations pose such a security risk and several cloud-based security incidents that involved a misconfiguration. I’ll then end by discussing how you can minimize cloud-related misconfigurations in your environments.

What Is a Cloud Misconfiguration?

A cloud misconfiguration occurs when you have not configured a cloud-related resource, asset, or tool properly. This improper setup may in turn jeopardize the security of your cloud-based data depending on the affected resource, asset, or tool.

Here’s a list of such misconfigurations affecting Amazon Web Services (AWS), drawn in part from McAfee’s “Cloud Native: The Infrastructure-as-a-Service (IaaS) Adoption and Risk Report”:

  • EBS data encryption is not turned on
  • There’s unrestricted outbound access
  • Access to resources is not provisioned using Identity and Access Management (IAM) roles
  • Elevated IAM privileges assigned to users or cloud resources
  • AWS Security Groups inbound access is misconfigured
  • Unencrypted Amazon Machine Image (AMI) is discovered
  • Publicly accessible Cloud resources
  • VPC Flow logs are disabled
  • Multifactor authentication is not enabled for IAM users
  • S3 bucket encryption is not turned on

As you can see, misconfigurations are the product of human error. This means that you can remediate misconfigurations by setting the configurations of your systems and tools to a more stable and secure state.

Unfortunately, this is easier said than done. This is especially the case if you don’t think you’re responsible for fixing misconfigurations in your cloud environments. As I noted in an earlier blog post, you might be inclined to think that your cloud service providers automatically cover all of your security needs. In reality, you are responsible for securing your customer data in the public cloud, securing your applications, and protecting your operating systems.

As a result, it’s not surprising that 99% of misconfigurations flew under the radar of McAfee’s survey respondents using IaaS. They were aware of about 37 incidents involving misconfigurations per month. But because they weren’t looking for these issues or they didn’t have tools capable of auditing configurations, they didn’t realize that they were actually experiencing closer to 3,500 incidents each month.

Such lack of awareness translated into an inadequate response. Indeed, nearly a quarter of McAfee’s survey participants said that it took them longer than a day to correct an IaaS misconfiguration. This gave adversaries plenty of time to abuse the misconfiguration for malicious purposes.

Why It’s Important for You to Fix a Misconfiguration

All of this brings us to an important question: Why is it important for you to fix a misconfiguration? What exactly can a malicious actor do with a misconfiguration?

Misconfigurations themselves are one of the most common ways by which digital criminals gain a foothold in your IaaS environment. They often do this by leveraging compromised or weak credentials as a legitimate user. Other times, they exploit a vulnerability in software that’s deployed in your environment.

From there, digital criminals expand their reach beyond the landing node to target other parts of your environment. For instance, they leverage privileges within the compromised node to access other nodes remotely, probe for improperly secured apps and databases, or simply abuse weak network controls. They can then exfiltrate your data while remaining under the radar by copying data to an anonymous node on the Web or creating a storage gateway to access data from a remote location.

Here are a few examples that illustrate how malicious actors capitalized on organizations’ cloud misconfigurations to steal their sensitive information:

  • Capital One: Paige Thompson, a 33-year-old Seattle resident and former AWS software engineer, exploited a misconfigured web application firewall to access a server owned and operated by Capital One. That server had elevated privilege, which gave the attacker access to Storage Buckets, which contained 140,000 Social Security numbers, one million Canadian Social Insurance numbers, 80,000 bank account numbers and an undisclosed number of customers’ personal information. Thompson then attempted to share access to the information with others online, per CNN.
  • Imperva: According to Threatpost, Imperva created an internal compute instance that was misconfigured and publicly accessible. That instance contained an AWS API key, a resource that enabled attackers to access a database snapshot and exfiltrate the information of some of its customers.
  • CenturyLink: Security researchers found a third-party MongoDB database that was left unprotected on the web, reported SCMagazine. Upon taking a closer look, the researchers found that the database contained 2.8 million CenturyLink data records belonging to several hundred thousand of the tech company’s customers.

Minimizing the Occurrence of Misconfigurations in the Cloud

Per McAfee’s survey, you can minimize the occurrence of misconfigurations in the cloud by training your security teams to understand cloud infrastructure at the same level as their DevOps counterparts. It also helps to build IaaS configuration auditing into your CI/CD process, preferably at the code check-in phase.

Lastly, invest in cloud-native security tools, such as Lastline Defender. This tool allows you to monitor your networks for suspicious activity such as a malicious actor abusing a set of compromised credentials, moving laterally across the cloud environment, or attempting to exfiltrate information. Lastline uses Artificial Intelligence (AI) in tandem with network traffic analysis and file analysis for you to gain the necessary visibility of your environments, all without bogging you down with false positives.

Here’s more information on how Lastline can help you tackle misconfigurations in your cloud environments.


This blog is part 4 in an 8-part series of blog posts about security the public cloud, as initially described in our white paper. The prior blogs in this series are:

Part 1: You Need to Do SOMETHING to Prevent Your Clouds from Getting Hacked
Part 2: Why Monitoring East-West Traffic is Crucial for Cloud Security
Part 3: The Challenge of Obtaining Visibility into Cloud Security


This article originally appeared in Dark Reading.

Suresh Kasinathan

Suresh Kasinathan

Suresh Kasinathan has more than 20 years of experience in design, development, integration and deployment of cutting-edge products in the areas of public cloud, storage, virtualization and networking products.In his current role as a Principal Cloud Security Architect/Product Manager at Lastline, Suresh drives the strategy, roadmap and feature definitions for Lastline’s Network Detection and Response solution for public cloud.Before joining Lastline, Suresh was a Principal Cloud Security Architect at Cavirin where he architected and implemented a public cloud cyberposture intelligence and continuous closed-loop security solution. Prior to Cavirin, Suresh was a Principal Cloud Security Architect at BlackRock Inc, a financial services company, where he hardened its AWS Security posture. Before BlackRock, Suresh was a Principal Cloud Solution Architect at Microsoft where he helped big enterprises migrate their workloads to Azure. Suresh has also held engineering roles at Netgear, Cisco Systems and Netscape/AOL.He holds a Master’s degree in Computer Science from Arizona State University.
Suresh Kasinathan