Capital One’s data breach was bad. It could’ve been worse
In an era of data breach fatigue, the one announced by Capital One on Monday was enough to force many consumers to take notice — 106 million credit card applicants had their data compromised, including everything from names and addresses to credit scores and payment histories.
But Capital One's breach was also unusual in a number of ways. It was caught relatively quickly, likely preventing the compromised data from being used to steal customer identities. The alleged perpetrator has also already been identified and brought to court and the software flaw that was exploited in the breach was discovered through a responsible disclosure program run by the bank.
Still, Capital One's breach shared something in common with other notable hacks — it was a preventable security lapse, and its mistakes may be ones other institutions are in danger of repeating. Asked if Capital One's vulnerability stemmed from an egregious error, security blogger Brian Krebs responded, "If it is, a lot of other companies likely made the same mistake."
Where Capital One fell short
The hacker gained access to Capital One customer data through an insecure web application firewall. The bank refers to this as a “misconfigured” firewall, but it isn't clear whether it was the result of a security patch that wasn’t applied or some other vulnerability. Richard D. Fairbank, the firm's chairman and CEO, has said only the vulnerability has been patched. The bank declined a request for further comment.
Although Capital One had encrypted the data, the hacker was able to obtain legitimate credentials to a server, enabling her to break the encryption.
According to Jeff Bardin, chief intelligence officer of Treadstone 71 and a former member of the United States Air Force intelligence community, if Capital One was using the web application firewall that’s part of Amazon CloudFront, that comes with managed rules capability that automatically pushes security patches. But companies don’t have to accept the automated patches.
“At a lot of places, they have to go through an internal change management procedure to approve patches, so they don't break the applications on the front end,” Bardin said. “That's pretty standard in financial services to have structured configuration change as part of their audit and risk assessment activities.”
Bardin surmises the firewall vulnerability was most likely caused by human error.
“Folks at Capital One and others out there are involved in agile development methodologies, so they're constantly trying to put new features and functionality out in a steady stream,” he said. “This is not necessarily conducive to information security getting a handle on exactly what they're doing.”
Capital One also failed to detect the hacker after she broke in. The actual hack occurred on March 22-23 of this year, and Capital One bank didn't notice it until an ethical hacker brought it to the bank's attention four months later.
Capital One’s logs showed several attempts to connect to Capital One’s server from TOR exit nodes. Security software should have picked this up. It also should have detected the iPredator virtual private network the hacker used.
Gartner analyst Avivah Litan argues that Capital One, which has been an advocate of cloud computing, runs a pretty tight ship when it comes to cloud security. The bank uses a cloud security management tool called Cloud Custodian.
“They obviously put a lot of money into cloud security with that system and other systems and accidents happen,” she said.
Some observers have blamed the security incident on the fact that the data was in Amazon’s cloud. But the firewall glitch could have affected any server, whether in a cloud or on premise.
“When you have a lot of moving parts, it’s pretty easy to make a mistake in one spot,” Litan said.
What Capital One did right
Still, observers agreed the breach could have been worse. Capital One caught the error because of a responsible vulnerability disclosure program, where white hat hackers (also known as security researchers) are invited and even encouraged to find glitches in computer code, and given an email address to which they can send tips.
JPMorgan Chase, Citibank, American Express and ING are among the financial institutions that have such a program. The evolutionary step beyond this is a bug bounty program, in which ethical hackers are paid for useful information about vulnerabilities.
An ethical security researcher emailed Capital One through its vulnerability disclosure program on July 17.
“Hello there, there appears to be some leaked s3 data of yours in someone’s github / gist: …Let me know if you need help tracking them down,” the email said.
Capital One then began its own investigation. Two days later, it discovered the break-in and began working with the FBI.
In the government’s complaint against the alleged hacker, FBI special agent and former computer forensic examiner Joel Martini described some of his investigative work. He noted that the GitHub page the ethical hacker found included information about how to access to a server containing Capital One data at Amazon Web Services. A firewall misconfiguration permitted commands to reach and be executed by that server. The GitHub page was posted under an address that included the full name of the alleged hacker, Paige A. Thompson.
Martini says he knew, based on open source research, of a Meetup group Paige A. Thompson ran, using the name “erratic.” She used the same name “erratic” on her Twitter feed, where she boasted about her hacking work. Thompson also posted a veterinary bill on GitHub that contained her physical address; this matched the address on a resume she had posted online. Such breadcrumbs enabled the FBI to find Thompson and bring her to court.
Another positive for Capital One is it acted quickly — less than two weeks passed from the time the bank discovered the breach until its public disclosure.
Compare this to the Equifax breach two years ago, which the company discovered in July and announced in September.
Capital One says it caught the break-in so quickly that nothing was done with the stolen data.
“Based on our analysis to date, we believe it is unlikely that the information was used for fraud or disseminated by this individual,” the bank said in its statement.