Did Capital One Respond Well to an “Erratic” Data Breach?

On July 19, Capital One Financial Corporation determined it had sustained a data breach of over 106 million user records due to a cyberattack by a user named “Erratic” on Twitter. The company announced the breach to the media July 29, 2019. 

The Breach in Brief

Thanks to faulty configuration in Capitol One’s AWS  network, identity, and/or application access controls, Paige Thompson (a former AWS employee) was able to gain access to the bank’s cloud repository in March of 2019. Thompson collected personally-identifying information (PII) from approximately 100 million U.S. customers’ and 6 million Canadian customers’ applications to receive credit cards. This information was recorded in Capital One’s AWS Simple Storage System (S3) buckets. Thompson then allegedly uploaded information about the breach to a GitHub account around mid-April 2019. Subsequently, Thompson began posting about the hack on the Erractic account. For more complete accounts see:

• FBI complaint and affidavit to the Federal Magistrate: Reasonably readable and detailed account with law enforcement-vetted information.
• KrebsonSecurity Capital One Data Theft Impacts 106M People: More of Brian Krebs’ excellent reporting, including excerpts from the Erratic account on Twitter.
• Hacker News: More technical comments on how the breach occurred.
• NBCNews: U.S. wants trans woman accused in Capital One hack to stay locked up: A bit more detail about this rather colorful attacker.

A Mixed Response

When I recently wrote my “Reputational Risk and Crisis Panel: Shared Assessments Summit” for Security Boulevard, I showcased an example of how NOT to handle a breach, and wanted a counter-example of a well-handled breach. But in the time I had to write the article, I couldn’t find a satisfactory example of a GOOD breach response. 

When news of Capital One’s breach broke I thought “Aha! Perhaps this will be the GOOD EXAMPLE I was looking for.” After letting 6 weeks go by, here is my assessment.

What did the company do wrong?

• Failure to protect security configuration: The company admits “unauthorized access” which appears to have been possible due to a “configuration vulnerability.”
• Failure to detect vulnerability: The undetected vulnerability was exploitable from March 22 through July 19, 2019 and perhaps earlier.
• Failure to Detect and Block Unauthorized Access: Thompson may have used an anonymized Tor network address to access the data. If so, neither AWS nor Capital One systems alerted or prevented the Tor session from getting anywhere near personal financial information. 

What did the company do right?

• Tokenization of the most sensitive data: Although plenty of personally-identifying information (PII) was exposed through the breach, almost all credit card numbers and social security numbers were obfuscated using tokens and inaccessible to attackers.
• Responsible disclosure program: The company received notice (per the figure above) of the breach within 4 months. A rather long “dwell time” for the vulnerability to exist, but it could have been longer.
• Incident response (IR) program: Disclosure first to the authorities and then to the general public was completed within 10 days. Public announcement was synchronized with Thompson’s arrest. This indicates that an IR program involving technical, legal, PR, and executive resources worked through the issues rapidly. 

What issues remain open?

• Will Capital One customers actually experience identity theft? Although the class action lawsuits have already begun, I was not able to find indications that the identities Thompson accessed have actually been abused by fraudsters yet.
• Overly rosy response? The company stated: “Based on our analysis to date, we believe it is unlikely that the information was used for fraud or disseminated by this individual.” Yet Krebs notes that although there is no evidence that Thompson sought to sell the data,”at least some of [it] could have been obtained by others who may have followed her activities on different social media platforms.”

Bottom Line

Getting hit with a breach is like getting splattered with sewage – no one comes out smelling sweet. But some are better at cleaning up than others. Response is part of the cleanup.

Leaving aside any criticism of Capital One’s business practices, vulnerability or configuration management systems, and detection systems the company appears to have an effective IR program. However, the jury will remain out on whether the breach was well-handled until time proves that the company did not make an “overly rosy” assessment of whether its customers will end up experiencing identify theft or fraud. Perhaps it would have been better for the announcement to read: “Based on our analysis to date, we believe it is unlikely there is no evidence yet that the information was used for fraud or disseminated by this individual.” 

Next Steps

Modern (cloud) issues in Detection, Response, and Recovery are near and dear to me just now while I’m writing the Cyber-Resilience chapter of my book, Rational Cybersecurity for the Business. I’m continuing to research the following questions and may post on this again:

• Did Capital One’s use of AWS in the cloud to store customer financial information increase the likelihood of a breach?
• Do issues with the complexity of AWS identity and access management (IAM) and S3 security configuration make such a breach likely for other AWS customers?

If you have questions about the breach and good practices to protect your organization against similar issues please contact me here.