Comments
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.
In the case of the Capital One data breach, it was not a simple bucket misconfiguration but a series of unfortunate events including:
But it all started with the email below that was sent to Capital One which had details on a file hosted on GitHub.
.
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.
In my opinion, security is not just getting one thing (like bucket access) right. It involves:
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.
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.
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:
