Fidelis Blog


Preventing a Capital One Cloud Data Breach

On July 29, it was announced that there was a Capital One cloud data breach. A hacker had accessed about 100 million credit card applications, and investigators say thousands of Social Security and bank account numbers were also taken. This comes on the eve of the news that Equifax has reached a $700 million settlement with U.S. regulators over stolen personal information for 147 million records in 2017.

Are compromises like these preventable? Absolutely yes. Let’s first talk about what went wrong with the Capital One cloud data breach. Then I will cover some prevention best practices.

What Went Wrong with Capital One Cloud Data Breach

In the case of the Capital One data breach, it was not a simple bucket misconfiguration but a series of unfortunate events including:

  • WAF misconfiguration
  • Excessive permissions
  • EC2
  • IAM role
  • Metadata service
  • SSRF 
  • S3 bucket

But it all started with the email below that was sent to Capital One which had details on a file hosted on GitHub.



The Principle of Least Privilege

Organizations can avoid similar data leaks by following the principle of least privilege and by configuring access that is as restrictive as possible to their cloud infrastructure objects. Also, only select access should be provided within the trusted networks (east-west traffic) to access resources like buckets. Bucket access can be fine-tuned with a combination of access control lists (ACLs), bucket policies, or both. Permissions for east-west and north-south traffic in the cloud environment should be identified and scrutinized from a security perspective. 

  • East-west traffic is between various services in the cloud infrastructure 
  • North-south traffic is between the cloud infrastructure and outside networks.

In my opinion, security is not just getting one thing (like bucket access) right. It involves:

  • secure processes
  • secure architecture
  • continuous visibility and monitoring
  • secure implementation of documented processes and architecture

Best Practice Templates to Prevent a Capital One Cloud Data Breach

There are several best-practice templates available for IAM, EC2, Lambda, VPC, Route53, CloudFormation, CloudTrail, RDS and other services. A similar capability is available for Azure services like Azure Compute, SQL, Storage, ApplicationGateway, VirtualNetworks, WebApplications, Logging and Monitoring, and others. 

Below are a few examples of best practices from Cloud Passage Halo that provide visibility and security assessment of AWS S3 buckets that could have prevented the Capital One cloud data breach. 

Capital One cloud data breach

Many of these rules are customizable by user who can then configure and validate a tight bucket policy. Here are some other useful posts on leaky S3 buckets and discovering bucket exposures

Security is a Shared Responsibility

To conclude, security is a shared responsibility between you and your public cloud providers. While Cloud hosting providers (AWS/Azure) manage security “of” the cloud, you are responsible for the security of your applications and data “in” the cloud. If you don’t want to be another Capital One cloud data breach, organizations should use automated visibility tools to maintain a strong security posture and continuous compliance by automating best practices for public cloud infrastructure environments.  

I encourage you to sign up for a free CloudPassage security posture assessment to get a handle on the security of your AWS and Azure environments in 30 minutes.

Other resources:







Stay up to date on all things security

Subscribe to the Threat Geek Blog