This was not your grandfather’s bank data hack. Well, not that your grandfather would know what a bank data hack is, but if he did, he wouldn’t have recognized the one that hit Capital One last month.
By now, you’ve seen the main details: Capital One revealed that 100 million customer records had been compromised, and much of the data stolen, by a former Amazon Web Services employee named Paige Thompson.
Thompson, who tricked a misconfigured server into providing her with access credentials, subsequently dumped the information on GitHub and boasted about it on social media. Capital One discovered and revealed the breach three months after it occurred, and Thompson was arrested 12 days later.
So many little things about this breach are anomalous, it’s hard to pick just one to focus on. From the lack of an identifiable motive on the part of the hacker to the swiftness with which the mystery came into focus, this has none of the hallmarks of a 21st century data breach.
Let’s take a quick look at the two buckets into which the unusual aspects of the case can be dumped:
First, there’s the response loop, which yielded the amazingly unusual perception that while there were clearly mistakes made in its data handling, Capital One did pretty much everything it could in response.
Not only did it act quickly once it became aware of the breach, it found out about the theft through a tip sent to its vulnerability disclosure email, the mere presence of which sets Capital One apart from more than 90 percent of large companies. The email pointed to a huge trove of data that had been sitting on GitHub and looked suspiciously like it belonged to Capital One. The company then immediately looped in law enforcement, which led to Thompson’s quick incarceration.
That leads us to the story behind Thompson, which bears no resemblance to any breach mastermind profile in memory. Her persona just does not align with the motivations behind past large-scale data thefts.
Thompson, it turned out, appears to be a white-hat hacker with a checkered employment history who either got in over her head and panicked or wanted to get caught. There was no connection to the dark web, no ties to foreign actors or online terrorism and no seeming desire for financial gain (despite the clear success hackers have had selling similar data). Just a somewhat kooky woman who didn’t really seem to know exactly why she was doing what she was doing.
Unusual aspects aside, the fallout from the breach looks a lot more familiar.
For instance, there’s the inevitable class-action suits, of which there will no doubt be a handful, including one filed by the law firm Tycko & Zavareeri that takes things a step further than expected by naming GitHub as a defendant, claiming that the software development platform “actively encourages (at least) friendly hacking,” and that it didn’t act to remove the data.
If the suit manages to successfully argue that GitHub is culpable, thus setting a precedent for breach responsibility being shared by content hosts, look out.
There are also the clear cloud security implications. Somehow, Amazon has steered pretty clear of this incident despite the fact that the data was stored on an S3 instance, but the case, perhaps more than others before it, serves as a stark reminder that when a company offloads sensitive data to a cloud provider, it’s entrusting one of its most valuable assets to a third party. There is no getting around the risk inherent in that reality.
But what really looks most familiar, and what probably needs to change more than any other controllable aspect of these high-profile breach cases, is the politics that takes over during the aftermath. Legal teams get involved, companies clam up beyond issuing canned statements and details get shrouded in secrecy out of fear of further damage to the victim organization’s reputation. And, as longtime security observer Brian Krebs argued in a recent post, it’s time to dispense with this wrong-headed thinking.
“As long as the public and private response to data breaches remains orchestrated primarily by attorneys (which is certainly the case now at most major corporations), everyone else will continue to lack the benefit of being able to learn from and avoid those same mistakes,” Krebs wrote.
Even when things change, they still have a habit of staying the same. Here’s hoping the organizations that protect valuable pools of data are ready for something different.
*** This is a Security Bloggers Network syndicated blog from RSA Conference Blog authored by Tony Kontzer. Read the original post at: http://www.rsaconference.com/blogs/lessons-of-all-types-abound-in-aftermath-of-massive-capital-one-breach