Fool us once, shame on you. Fool us twice, we implement policies!

2012-12-26 by Dissent

It had all the makings of a sexy data breach story. An individual with the Twitter nick of @TibitXimer claimed to have exploited a vulnerability on Verizon’s server and dumped about 300,000 records out of an estimated 3,000,000 customer records allegedly acquired.

ZDNet trumpeted the headline, “Exclusive: Hacker nabs 3m Verizon customer records.” They reported:

"A hacker has posted around 300,000 database entries of Verizon customers to the Web, after exploiting a vulnerability in the cellular giant's network.

The hacker, going by the name @TibitXimer on Twitter, told ZDNet earlier this evening that the hack was carried out earlier this year on July 12, which allowed him to gain root access to the server holding the customer data. Tibit gained access to a server with little difficulty after working with another hacker to identify the security flaw."

The problem is that although none of it was true, @TibitXimer’s claims and ZDNet’s repetition of the claims were repeated all over the Internet.

One day later, @TibitXimer was gone from Twitter and a more accurate version of the story started to emerge. In statements to other media outlets such as DataBreaches.net, The Next Web, and Forbes, Verizon spokesperson Alberto Canal explained that Verizon’s systems had not been breached at all, there was no vulnerability exploited, no root access gained, and that the data dumped were old data from an incident a few months ago.

To add insult to the reputation harm that Verizon could have suffered, the incident wasn't even Verizon’s incident. It turned out that a third party marketing firm that Canal did not name had accidentally leaked a sales lead list and the list had simply been copied and posted at the beginning of August. Most of the names on the list were not even Verizon customers, according to Canal. The same data were re-posted this week and claimed as a new “hack.”

Not such a sexy story anymore, right? And ZDNet is certainly not the only media source to believe a hacker’s claims that were subsequently determined to be totally untrue. We've been fooled, too, at times, as has Lee Johnstone, who recently had to correct a report on Cyber War News that a hacker named “Hannibal” had leaked 1,000,000 Facebook account details in retaliation for #OpIsrael.

Over the past year, the problem of false claims has reached almost epidemic proportions, which is why, over the past few months, DataLossDB.org started implementing policies requiring us to obtain – or at least make a good faith effort to obtain when possible – a statement from an allegedly breached entity either confirming, denying, or clarifying and correcting a hacker’s claims of a breach - *before* we decide whether to add a report to the database.

Sometimes, as in this case, it is relatively easy to reach a media contact and get a response. In other cases, particularly with small entities involved in claimed hacks overseas, it is not so easy, and we may send several e-mails that go unanswered before we try to decide whether to include a claimed breach or not. If you login and read individual entries, you may even see a Curator’s Note in the Comments section indicating that we tried and failed to reach anyone by e-mail to confirm the report.

Deciding whether to include a report when we cannot reach anyone is headache-inducing, to say the least, as we realize that with this less than perfect system, entities might suffer reputation harm through no fault of their own. We have therefore also implemented the ability to fully delete entries from the database should we later learn that a claim was totally false.

Another policy we recently implemented involves putting (DISPUTED) in the summary line for an incident if there is a real dispute as to whether a breach occurred or not. There may be times when an entity insists they have not been breached but we find the evidence in a data dump to be compelling and decide to include the report. This was the case, for example, in the reported hack of MilitarySingles.com, where they denied it to DataBreaches.net and others, but analysis of the data dump and information still available on their site led us to the decision to include the report. At other times, a reported breach may be part of litigation and where the defendant denies the claims, we may decide to include the report but note it as DISPUTED.

Trying to confirm the numerous claimed hacks that appear on Pastebin or other sites on a daily basis is a time-consuming process that slows us down in providing timely reports and has put even more pressure on our resources that are already constrained. However, we believe that it needs to be done to ensure data quality. And so, as 2012 draws to a close, we have already added over 1,400 incidents (and that number does not include the Fringe incidents) for the year, but there are hundreds more still to process. Whatever number you see on the Stats page for December 31st will likely be significantly under our real total for the year until we can catch up.

On that note, I wish you all a Happy and Healthy 2013. And let’s hope that next year, things slow down for us!

/Dissent