In this article, we cover the most common misconfigurations that lead to cloud security data breaches in AWS, a sample data breach scenario to help demonstrate how this could affect your organization, as well as best practices to detect, prevent, and remediate misconfigurations in your cloud environment at scale.
Cloud security data breaches have dominated news headlines over the last several years, but what’s surprising is that almost every one of these breaches was due to a simple cloud misconfiguration. Research from McAfee’s Cloud Adoption and Risk Report shows that on average, enterprises using IaaS/PaaS have 14 misconfigured services running at any given time, resulting in an average of 2,269 misconfiguration incidents per month!
Certainly, it can be overwhelming to ensure all the policies, roles, and interconnections between various objects—which are managed by different teams and across different cloud environments—are all configured correctly. However, the risk that businesses face by not addressing misconfigurations is too high. It’s time we step back to assess the vulnerabilities we’re dealing with and rethink our approach to ensure a strong cloud security posture.
In this article, we’ll cover the most common misconfigurations that can lead to cloud security data breaches in AWS, a sample data breach scenario to help demonstrate how this could affect your organization, as well as best practices to detect, prevent, and remediate misconfigurations in your environment at scale.
Common misconfigurations that can lead to cloud security data breaches in AWS
Many businesses choose to operate in the cloud for how quickly resources can be deployed, but unfortunately, this also affects how quickly misconfigured resources are deployed. Especially in organizations with thousands of workloads and distributed operations, it can seem nearly impossible to monitor and detect all the misconfiguration possibilities with complete success.
The first step to avoiding and remediating misconfigurations is to know what to look for. Here are some of the most common misconfigured settings in AWS that can lead to cloud security data breaches:
- S3 bucket is publicly accessible or unrestricted
- S3 bucket access control lists (ACLs) are misconfigured
- IAM policies are not configured or are misconfigured
- Unrestricted access to non-http/https ports
- Resources are publicly accessible with no restrictions
From just this list, you can see the large number of scenarios and combinations that can lead to data breaches in your AWS environment.
Example scenario of a data breach in AWS
Now that we’ve covered some of the most common misconfigurations to avoid, we’ll dive deep into one scenario to demonstrate how simple errors in configuration can lead to dangerous outcomes.
Let’s assume we have ABC Company, which has a large AWS footprint and uses popular AWS services such as EC2, Lambda, S3, RDS, EKS, and more. They are also using AWS Identity and Access Management (IAM) with integrations back to their on-premises Active Directory to manage the authorization of resources.
ABC created an e-commerce app and stored a significant amount of user data from this app on S3. The company also had several EC2 instances configured with READ access to S3, allowing administrators to access and manage the S3 buckets as needed. They ensured that only specific IP address port ranges could SSH into the machine, but they misconfigured the firewall by allowing IP port range for port 22 SSH access.
Configuration issues in this scenario:
- IP address range was misconfigured, allowing non-company IP addresses to SSH in
- SSH access was turned on for port 22, which should not be allowed, with the exception of a known entity (singular trusted EC2 instance)
- The EC2 instance had an S3 read role (AWS policy AmazonS3ReadOnlyAccess), which is not a recommended configuration since it allows anyone with access to the machine to access S3
- CLI loaded on the machine
- S3 didn’t have proper ACLs configured (none)
- S3 didn’t have a policy restricting access to only authorized users/roles (blank policy)
- S3 wasn’t encrypted (this wouldn’t have mattered in this situation but it’s a good best practice)
At some future time, a hacker could:
- Access the EC2 instance on port 22 (from a non-company IP address that was in the IP address range)
- Utilize http: //169.254.169.254/latest/meta-data/ on the EC2 instance to get role and credentials information that is available to the EC2 instance
- Use the credentials to scan S3 buckets from the EC2 instance
- Exfiltrate data from the open S3 buckets from a local machine. (Because the role had read access and no other policies/ACLs were configured, even an encrypted S3 bucket wouldn’t have helped because the data would be decrypted for “authorized access”)
As a result, ABC Company would have lost a significant amount of data containing customer records, leading to a range of other possibilities, including damaged company reputation, customer distrust and churn, decreased market value, legal and contractual liabilities, financial expenses, and more.
How to detect and prevent cloud security data breaches in AWS
There are a number of steps you can take to prevent cloud security data breaches in AWS. We recommend you start with these best practices:
- Restrict access by using the principle of least privilege
- Disable cloud regions where your organization doesn’t host workloads
- Disable cloud resources your teams don’t need
- Encrypt all data at rest and in-transit
- Block inadvertent uploads or cross-region copies
- Prevent access to privileged accounts by enabling multi-factor authentication
- Ensure encryption keys are rotated and stored safely
- Enforce data security governance policies
In addition to these best practices, the Cloud Security Alliance states that due to the highly complex and dynamic nature of the cloud, “companies should embrace automation and employ technologies that scan continuously for misconfigured resources and remediate problems in real-time.”
Our customers use CloudHealth Secure State, a platform that applies continuous verification best practices to resources in development and once they’re deployed (in case of configuration drift). CloudHealth Secure State not only flags misconfigured resources, but prioritizes them in order of severity, and provides context-rich security insights so developers and system administrators can see what impact the recommended fixes will have on other resources.
In the example scenario we described with ABC Company, CloudHealth Secure State would have detected and alerted that the EC2 instance has port 22 open for public access. As you can see in the diagram below, it shows the precise issue against the instance, and the interconnected objects, such as subnets, route tables, etc.
To learn more about how CloudHealth Secure State can help you prevent data breaches and improve your cloud security posture, see our solution brief here, or feel free to reach out for a free demo here.
And if you’re looking for how to effectively integrate these tips into your broader cloud security and compliance practice, see our in-depth guide: Building a Successful Cloud Infrastructure and Security Practice
