BreachExchange mailing list archives

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


From: Jake Kouns <jkouns () opensecurityfoundation org>
Date: Wed, 26 Dec 2012 15:16:33 -0500

http://www.datalossdb.org/incident_highlights/56-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
_______________________________________________
Dataloss-discuss Mailing List (dataloss-discuss () datalossdb org)
Archived at http://seclists.org/dataloss/
Unsubscribe at http://datalossdb.org/mailing_list

Supporters:

Risk Based Security (http://www.riskbasedsecurity.com/)
Risk Based Security equips organizations with security intelligence, risk
management services and on-demand security solutions to establish
customized risk-based programs to address information security and
compliance challenges. 

Tenable Network Security (http://www.tenable.com/)
Tenable Network Security provides a suite of solutions which unify real-time
vulnerability, event and compliance monitoring into a single, role-based, interface
for administrators, auditors and risk managers to evaluate, communicate and
report needed information for effective decision making and systems management.


Current thread: