Cloud infrastructure gets breached not because attackers are sophisticated, but because a setting was left on default, a permission was never cleaned up, or a log was never turned on. Here are the five misconfigurations that appear most often in breach investigations, and exactly what to do about each one.
Gartner put a number on this: through 2025, 99% of cloud security failures were the customer's fault, not the cloud provider's. AWS, GCP, and Azure are secure by design. The misconfiguration is always on the other side of the shared responsibility model, in the settings, policies, and access controls that engineering teams configure and own.
The Shared Responsibility Problem
The provider secures the hardware, network, and hypervisor. Everything above that layer, IAM policies, encryption settings, network access controls, storage permissions, belongs to the customer. That boundary is where all five misconfigurations below live. None of them are failures of the cloud platform. All of them are failures of configuration, usually introduced quickly, under pressure, and never revisited.
An S3 bucket set to public access means every file in it is readable by anyone on the internet. Finding that URL takes less than a minute. Capital One, GoDaddy, and dozens of less-reported breaches trace directly to publicly accessible cloud storage. The exposure is often discovered not by the company but by a security researcher, or an attacker who had been quietly exfiltrating data for months.
Enable S3 Block Public Access at the AWS account level, a single toggle that prevents any bucket from being made public. Run AWS Trusted Advisor or Prowler to audit existing buckets. For genuinely public content, use CloudFront as the delivery layer and keep the origin bucket private.
The Capital One breach of 2019 used an overpermissioned IAM role to enumerate and download data from over 700 S3 buckets, exposing 100 million customer records at a cost of over $190 million. The root cause: a role with AdministratorAccess attached to an internet-facing service. The principle of least privilege exists precisely to prevent this.
Run AWS IAM Access Analyzer across the entire environment. It identifies roles with unused permissions, wildcard resource access, and over-scoped policies. Replace AdministratorAccess with specific resource-scoped policies. Enable IAM Access Analyzer at the organisation level to flag new overpermissive policies automatically.
SK Telecom's 2025 breach, resulting in a £97 million regulatory fine, listed unencrypted storage of USIM authentication keys as the primary compliance failure. 26 million of the most sensitive credentials were stored in plaintext. No encryption. No key management. No protection. RDS databases, S3 buckets, EBS volumes, and internal service connections are all common encryption gaps in cloud environments.
For RDS, enable encryption at creation time (it cannot be added to an existing instance without migration). For S3, apply a bucket policy that denies any PutObject without server-side encryption. Enforce TLS 1.2 minimum at the load balancer. AWS Certificate Manager provides free TLS certificates for all public endpoints.
A rule allowing inbound traffic from 0.0.0.0/0 on any port is an open invitation to the entire internet. An RDS instance with port 3306 open to the world will be found by port scanners within hours. This misconfiguration appears in environments of every scale and is flagged in virtually every cloud security assessment.
Enable AWS Security Hub with the Foundational Security Best Practices standard, it automatically flags security groups with unrestricted inbound access. Replace all 0.0.0.0/0 source rules with specific IP ranges or VPC CIDR blocks. For SSH access, use AWS Systems Manager Session Manager, fully audited shell access with no inbound ports required.
The median time to identify a breach in 2024 was 194 days. In most cases, the logs that would have revealed the intrusion either were not being collected, were not retained long enough, or were not being monitored. Logging is the one control that cannot be fixed retroactively, if CloudTrail was not enabled in two AWS regions, those 12 months of API activity are gone forever.
Enable AWS CloudTrail in all regions with log file validation. Store logs in a dedicated S3 bucket with object lock enabled. Enable VPC Flow Logs on every production VPC with 12-month retention. Create five CloudWatch alarms: root account usage, console login without MFA, CloudTrail configuration changes, security group modifications, and unusual data transfer volumes.
SOC 2 & Framework Mapping
| Misconfiguration | SOC 2 Control | ISO 27001 | DPDP Act |
|---|---|---|---|
| Public S3 Buckets | CC6.6 | A.9.4 | Section 8 |
| Overpermissive IAM | CC6.1, CC6.3 | A.9.2 | Section 8 |
| Missing Encryption | CC6.7 | A.10.1 | Section 8 |
| Open Security Groups | CC6.6 | A.13.1 | Section 8 |
| Disabled Logging | CC4.1, CC7.1 | A.12.4 | Section 9 |
Frequently Asked Questions
Customer misconfiguration, not provider vulnerabilities. Gartner found that through 2025, 99% of cloud security failures were caused by the customer, not AWS, GCP, or Azure. Public S3 buckets, overpermissive IAM roles, and missing logging are the top culprits.
Within hours of creation. Automated scanners and dedicated search engines continuously probe the internet for exposed cloud storage. The Capital One breach is a real-world example of what happens when an S3 bucket and an overpermissive IAM role are left unchecked.
Not directly. AWS does not allow enabling encryption on an existing unencrypted RDS instance. You must create an encrypted snapshot of the database and restore a new instance from it. This is why encryption should be enabled at creation time.
Each of the five maps directly to SOC 2 Common Criteria controls. Public storage buckets fail CC6.6, overpermissive IAM fails CC6.1 and CC6.3, missing encryption fails CC6.7, open security groups fail CC6.6, and disabled logging fails CC4.1 and CC7.1.
No. Cloud environments change constantly, a bucket that was private last week may be public today. Manual audits capture a point in time. Without continuous posture monitoring, misconfigurations accumulate between reviews and often go undetected until a breach or audit reveals them.