The data breach of Capital One was big news, but it was also a familiar story: a major financial company with the budget and means to secure its data didn’t bother to do so, and the personal information of over a hundred million of its customers and applicants was exposed. The discovery, announcement, and subsequent arrest of the alleged perpetrator all happened within a week of the FTC’s settlement with Equifax for its own 2017 mega-breach. Like Equifax, Capital One can most likely expect some negative publicity, a minor wrist slap of a fine, and then it will be back to business as usual. Never mind the victims, who will be looking over their shoulders for signs of identity-related crime for the rest of their lives.
While it’s easy to dismiss the Capital One breach as a sort of ho-hum cataclysmic event, two follow-up news stories grabbed my attention. Neither were boring. In fact, it seemed like finally there might be a permanent mark left by a serious breach.
The first news story was about the decision in Congress to investigate Amazon Web Services as part of their probe into the Capital One breach, and the second story was that software repository GitHub had been targeted with a class-action lawsuit for its tangential involvement in the breach.
Both stories may portend a sea change when it comes to the assignment of blame for data breaches–one that could improve things overall by spreading responsibility across supply chains, but that could just as easily put a cramp in the entire industry.
Cloudy with a Chance of Client Error
The exposed Capital One data resided on an Amazon cloud server. Paige Thompson, the hacker accused of being responsible for the breach, is a former systems engineer for Amazon Web Services. While it may seem easy to connect the dots to an inherent vulnerability in the company’s cloud services, reports suggest that it may be more likely Thompson used her knowledge to identify an error in Capital One’s configuration, and not that Amazon’s system was insecure.
“Dude so many people are doing it wrong,” Thompson wrote on June 27 in reference to the misconfiguration. The bottom line: those who were doing it “right” on Amazon Web Services weren’t vulnerable to the exploit she allegedly used. Plain English: Knowing to look for a key under the doormat says nothing about the quality of the lock thus opened.
In the press release announcing the breach, even Capital One stated that the vulnerability Thompson exploited was “not specific to the cloud.” And yet, Amazon is in the crosshairs of the House Oversight and Reform Committee and finding its proposed $10 billion contract with the Department of Defense at risk due to the fallout from the breach.
Given its practices and utter dominance in the cloud and e-commerce markets, it’s hard to paint Amazon as a victim, and that’s not the point here. The lesson is that a company in Capital One’s supply chain–in this case, AWS–now faces congressional scrutiny and presumably a loss of revenue because it did business with a hacked company that made a mistake.
Then There’s GitHub
GitHub is a Microsoft-owned online open source service that allows developers to store and collaborate on code for websites and applications. It’s where Thompson allegedly shared details and data about her hack (at least in part) and where the data was found and reported to Capital One after being publicly available for roughly three months.
The lawsuit claims, “GitHub had an obligation, under California law, to keep off (or to remove from) its site Social Security numbers and other Personal Information.” GitHub itself maintains that the information posted to its site contained none of this information. It did, however, promptly comply with a request to remove the compromised data when Capital One became aware of the breach.
What’s unusual here is that GitHub’s problem does not stem from sloppy cybersecurity, vendor malfeasance, lack of employee training or contractor vetting, or any of the other more familiar factors in data breaches. It has a problem because of something someone else did.
GitHub may arguably be at fault for lacking better oversight of what its 37 million users post, but that sort of misuse of a platform could easily be extended to an incredibly wide array of online businesses. File-sharing platforms such as DropBox or Google Drive, office communication apps like Slack, or really any website that allows for any kind of publicly accessible comments could all be liable given similar standards. Next stop: content shared by people (and state-sponsored troll farms) on Facebook and other social media sites.
The suit against GitHub may drag on, it may be quickly thrown out, or it may establish a difficult precedent for any business that hosts or displays data online. Regardless, this is something new in breach that could increase the cost of breach for enterprise. Lawsuits are expensive and time-consuming, and while Microsoft and Amazon obviously have deep enough pockets to weather them, most businesses do not.
The Takeaway
As the notion of who is liable for a data breach expands, it’s becoming more of a necessity to get cyber insurance coverage. In a world where–right or wrong–hosting hacked data, or the misuse of a technological platform is grounds for a lawsuit or a government fine, the potential consequences of doing business online could be severe, even with ironclad cybersecurity policies and defenses.
It may be time to re-think how services are provided online and batten the hatches because it could well be we’re in for a whole new kind of storm (or, in keeping with Shark Week: We need a bigger boat).
