researchHQ’s Key Takeaways:
- Organisations utilising IaaS/PaaS have an average of 14 misconfigured services at any time, causing vulnerabilities and breaches.
- Misconfigurations stem from poor management of the policies, roles and interconnections between various objects.
- For organisation utilising AWS, poorly configured access controls are a common cause of data breaches.
- Best practices for detecting and preventing cloud breaches include implementing least privilege access control and effective encryption.
- Automation and continuous monitoring will help organisations identify and resolve misconfigurations in real-time.
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.
