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.
After analyzing the github file and logs from the Capital One cloud data breach compromise, Capital One concluded that the hacker first obtained credentials for an account *****-WAF-Role that in turn enabled access to certain AWS S3 buckets. This was done from an external TOR IP address 46.246.35.99. Later another external TOR IP address (46.246.35.103) executed the AWS ‘List Buckets’ and ‘Sync’ command to list and copy data. A detailed description of the Capital One data breach as per papers filed by the U.S. District Court can be found here.
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 our Cloud Secure product that provides 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.
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:
The post Preventing a Capital One Cloud Data Breach appeared first on Cybersecurity Insiders.
August 22, 2019 at 09:08AM
0 comments:
Post a Comment