Capital One: What’s in YOUR Breach Announcement?
Another day, another breach of sensitive personal information.
This time, it’s over 100 Million customers of Capital One who’ve had their data stolen. As usual, the fact that there’s a data breach isn’t surprising or newsworthy, although the scale of this one is above average. But looking closely at the details of the incident can tell us a lot about the state of things for the company that suffered the breach – and potentially offer important lessons for the rest of us.
The Incident
Details about the incident are somewhat confused, with different sources giving different details around the causes and timelines of the incident. I’m going to list some basic details here, all confirmed from multiple news sources and court filings, but some details are likely incorrect.
Earlier in the year, an attacker exploited a misconfiguration in a web application firewall. This vulnerability granted them access to documents related to over 100 million individual accounts, including legal names and identifying information, some limited number of US Social Security and Canadian social insurance numbers, and bank account information. Some of this information was protected by encryption, but the nature of the attacker’s access bypassed much of the protection.
On July 17, someone notified Capital One of the vulnerability through a public and easily-found disclosure program. By July 19, Capital One had confirmed and patched the vulnerability.
On July 29, as the attacker was facing charges in a Seattle courtroom, Capital One publicly announced the breach and began formal notification to those affected.
The Good Points
First, let’s talk about all the things Capital One did right.
- Capital One has an apparently well-organized and functioning vulnerability management program. Not only is there an easily-identified disclosure system in place, but the report they received was processed, acted upon, and the solution implemented in production in less than 48 hours.
Many organizations would struggle to implement routine patches in 48 hours, much less a previously undisclosed system vulnerability reported by a third party. - Rather than working to minimize the negative publicity, they disclosed the issue publicly and openly, delaying less than two weeks and making their announcement at the same time as charges were filed against the attacker.
- We don’t know the details of the attack, but it appears the end result was the attacker gaining access to IAM Role credentials in an instance on Amazon’s AWS.
Now, what’s good about that is, this is a relatively uncommon compromise method for AWS hosted services, which indicates that the more common issues – S3 storage credentials, uncontrolled developer instances, poor overall access controls – were probably not present in this case. Securing everything is very close to impossible; by looking at how hard an attacker had to work to gain access, we can tell a lot about the maturity of a defending organization’s security infrastructure. In this case, that’s really quite good.
The Bad Points
There are some obvious issues here, too. I’m going to stress that on the whole, I think Capital One has done a fine job; but there’s always room for improvement, and some of those areas are quite clear even from outside the organization.
- The attack involved accessing and downloading large amounts of personal information from production systems. Without knowing more detail we can’t say precisely how the data was exfiltrated, but we do know that it was – the data was hosted on the attacker’s systems for quite a while. Which means there was no monitoring or alerting to unusual system activity that would cover someone downloading huge amounts of customer data to a non-Capital One system, and there should be.
- Similarly, while the access controls on Capital One’s production systems appear to be better than the average, they should still be improved. No system should be able to download data from Capital One backend systems unless they’re whitelisted – not just “only systems in the Capital One network”, but “only these specific IPs can access this data”. That requires careful architecture planning and design review, but frankly, this is a large bank with a huge amount of sensitive information – that shouldn’t be out of reach.
- The announcement itself was terrible. I had issues with it when I first read it, but after having time to reflect and reconsider, I’ve downgraded my opinion on it. This type of announcement has three jobs; inform the media and the customers to the situation, clearly communicate impact and responsibilities, and calm fears and uncertainties. I don’t think it managed any of those completely, and it totally failed on the fear and uncertainty count (admittedly, the toughest job of the three.)
The Lessons
There are plenty of lessons here for organizations, even those who aren’t large banks.
First, even in a mature security environment, details matter. The purpose of security controls is to make it harder for malicious actors to get at sensitive information, but often times it’s like trying to protect a house with a hundred ground floor doors and windows. If you’re not sure all of them are locked and bolted, there’s not a lot of point in working to secure the upper floors.
Second, the actual vulnerabilities were of a nature that can’t be solved through code and system engineering. Misconfigured production systems that work, but don’t provide adequate protection, will only be spotted through careful design review, configuration testing, and change management. Spend time and energy on building out processes, especially in complex environments, and think about how to make them more effective.
Finally, the communications strategy as a whole for Capital One is good. Excellent timing, they get a lot of points for moving as fast and accurately as they did. But… in this situation, the authenticity of the communication matters a great deal, and on that front, Capital One did themselves a big disservice.
“Like all too many responses to crises of many kinds, Fairbanks’ comment on the breach reads as overly formal and inauthentic,” Ariel Robinson, a cybersecurity consultant and Senior Policy Strategist at Smooth Sailing Solutions, said. “‘Deeply sorry’ from a CEO post-breach—and make no mistake, this was a data breach, not just an ‘incident’—is the equivalent of politicians’ ‘thoughts and prayers.’”
Capital One Is the One to Blame for Exposing Your Data, 2019-07-30
It’s hardly unusual for a company to fail at this type of communication. Authenticity is hard, especially when you’re talking about a failure – most especially when you don’t think of the failure as really being your fault. But it’s absolutely critical, because this is the part that people see and remember.
As of this writing, Capital One’s stock price is down just under 6% from the price immediately before the breach announcement. Now, long term, that isn’t going to last; the fundamental issues on this incident are clear and in the bank’s favor, I think it’s highly unlikely there will be any kind of long-term repercussions or lasting damage.
But how much of that 6% could have been avoided with a better announcement? One that wasn’t quite so stilted, one that did a better job of celebrating the positives and laying uncertainties to rest? How would you do, given the same set of circumstances?