Monthly Archives: December, 2012

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

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, 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, 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, where they denied it to 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!


Is A Data Breach A Life Or Death Situation?

Most people would agree that security is important; however, many would have a hard time saying that a data breach could be a life or death situation. Sadly, in the past few weeks there have been two cases that may qualify for that characterization in the news.

The first case is the data breach at King Edward VII Hospital on December 4, 2012. Two Australian radio show hosts prank called the hospital in a joking attempt to get information on the condition of the Duchess of Cambridge. To their surprise the nurse, who answered the phone, fell for the hoax and provided them with information on the Duchess’s condition and care. Last Friday, Jacintha Saldanha, the 46 year old nurse who provided the information, committed suicide just two days after news of the breach was released.

The second case involves a data breach that occurred September 28, 2012 at the University of Georgia. A former student gained unauthorized access to a server containing 8,500 former and current employees’ names, Social Security numbers, and other sensitive information. Still in the midst of investigation, police announced on Tuesday that Charles Stapler Stell, the 26 year old behind the data breach, passed away with no indication of foul play and most likely the result of suicide.

In these two cases, the data breaches and their consequences appeared to have pushed these individuals into a life or death decision. As the importance of privacy and security breaches increases, we have now seen there are potential ramifications to the people involved, more than just notification and credit monitoring.

As breaches unfortunately become more commonplace, organizations impacted should ensure that they not only have a response plan for dealing with the incident, but also how to constructively handle any employees at fault. While discipline from HR may be on the agenda, organizations need to ensure the wellbeing of their employees as they process their actions.


Written by eabsetz