Capital One Financial Corporation disclosed yesterday that approximately 100 million US customers and 6 million Canadian customers have been affected by a breach in which a former AWS employee, Paige Thompson, accessed Capital One's customer data hosted in AWS S3 (Capital One press release, July 29, FBI affidavit in the criminal case). The data taken includes credit-application data from 2005 to early 2019 — names, addresses, phone numbers, email addresses, dates of birth, and self-reported incomes — plus credit scores, credit limits, balances, payment history, and contact information for some applicants. About 140,000 US Social Security numbers and 80,000 linked bank account numbers were also taken. The Canadian-side data includes about 1 million Canadian Social Insurance Numbers.
The technical mechanism is the part of the story that is operationally instructive and will be in customer-engagement briefings for the next year. The attacker, on the FBI affidavit, exploited a Server-Side Request Forgery (SSRF) vulnerability in a misconfigured Capital One web application firewall to make the WAF — which was running on an EC2 instance with an attached IAM role — fetch the AWS instance metadata service (the IMDS at 169.254.169.254). The metadata service returned the IAM role's temporary credentials. The attacker then used those temporary credentials to enumerate and download the contents of S3 buckets that the IAM role had access to. The bucket access included substantial customer-data holdings.
The architectural-lesson breakdown. First, the SSRF vulnerability in the WAF is the proximate cause; SSRF protection in customer-facing web applications and infrastructure is a well-known control category and the failure to implement it is the application-security finding. Second, the AWS instance metadata service v1, which the attack relied upon, has the well-known property of being accessible from any process on the instance without authentication. AWS has been working on metadata service v2 (released this autumn) which requires session tokens for access, mitigating the SSRF-to-metadata-credential-extraction chain. Customer organisations running on AWS should be migrating to IMDSv2 as soon as the migration is operationally feasible. Third, the IAM role permissions on the WAF EC2 instance were broader than necessary — the principle of least privilege would have limited the IAM role's S3 access to only the buckets the WAF actually needed, not the entire customer-data-holdings bucket population. Fourth, the S3 bucket-side controls — bucket policies, S3 access logs, GuardDuty / Macie data-pattern monitoring — would, properly configured, have detected the bulk-download pattern from an unexpected source IAM principal.
For the customer-organisation cloud-deployment work, the action items this week are concrete. Audit IAM roles attached to internet-facing EC2 instances for over-privileged S3 and other-resource access. Enable IMDSv2 on supported instances. Configure bucket-side monitoring for unusual access patterns. Review WAF and other web-facing infrastructure for SSRF protection. The customer-portfolio cloud-deployment posture varies: the manufacturer is on substantial AWS deployment with mature security posture, and the audit work is being done; the financial-services firm is on a more recent AWS deployment that is in good shape; the retailer is on a hybrid AWS/on-prem deployment where the AWS-side audit is being done this week. The vCISO conversations are clear and the implementation work is tractable.
The disclosure handling has been, on the public information, professionally executed. Capital One was notified by an outside party on the 17th of July, completed initial investigation by the 19th, notified the FBI on the 19th-20th, and disclosed publicly on the 29th. The disclosure timeline is within reasonable expectations and the customer-notification language has been clear. The FBI investigation produced an arrest of the alleged attacker on the 29th — the same day as the public disclosure — which is unusual in its speed and is enabled by the attacker's apparent self-disclosure on social media including a public GitHub repository where the attack tooling and the stolen-data references were posted. The attacker's profile (former AWS employee, technically capable, with apparent operational-security mistakes) is not the typical state-grade actor profile and the case is, in operational shape, an insider-knowledge-and-individual-motivation case rather than a national-security case.
The wider strategic point — and this is going to be in the customer briefings for some time — is that cloud-deployment security in 2019 is a discipline distinct from on-premises security, and the customer-organisation programmes that treat them as the same discipline are exposed in ways that the on-premises-only programmes are not. The cloud-side controls (IAM, bucket policies, instance metadata, network segmentation in cloud-native form) are operationally different from their on-premises analogues, and the customer-organisation security teams need cloud-specific expertise to design and operate them. The pen-testing engagement queue has been showing this for over a year; the Capital One case will accelerate the customer-organisation investment in cloud-native security expertise.
For the wider regulatory question, the Capital One disclosure is the largest US-side consumer-data breach in 2019 by a substantial margin. The state-attorneys-general response will be substantial; the regulatory enforcement under the various state-side data-protection regimes will produce class-action and regulatory exposure that will run for years. The CCPA — which comes into effect on January 1, 2020 — would, if it had been in force, produce additional disclosure and consumer-rights obligations that are going to become operational from this autumn forward.