[attrition] Sony had HOW many breaches?

[security curmudgeon]

---------- Forwarded message ----------
From: Jake Kouns <jkouns at opensecurityfoundation.org>

http://datalossdb.org/incident_highlights/53-sony-had-how-many-breaches

2011-06-05 by Dissent

We thought keeping track of entities involved in the Epsilon breach was 
tough, but the recent spate of attacks on Sony networks has us working 
overtime trying to update the database. Thankfully, Jericho provided 
yeoman service and compiled a hyperlinked chronology of recent 
developments.

The Sony breaches have generated a lot of discussion. Some of it has 
centered on Sony's shocking failure to encrypt passwords and it being 
all-too-vulnerable to SQLi compromises (if those posting the data publicly 
are accurate as to how they compromised certain databases). Sony 
undoubtedly has a lot of explaining to do if it hopes to have future 
assertions of industry-standard security taken seriously.

To date, the two largest incidents affected over 100 million records. But 
were the PSN and Sony Online Entertainment (SOE) attacks two separate 
incidents or were they really one breach? Should DataLossDB.org have 
recorded one breach with over 100 million affected, or two incidents 
involving 77 million and 24.6 million, respectively? Or should we just 
treat the last 45 days' incidents as one #EPIC #FAIL and one big incident? 
In light of our mission to track unique breaches, the question is not 
trivial.

When news of the second incident broke, the first thought was to update 
the PSN entry and add another 24.6 million to that counter. But as more 
details emerged, it seemed clear that we should treat it as a separate 
incident. The attack had occurred on different days than the the PSN 
attack, the data compromised were on different networks, it seems quite 
likely the different networks had different security measures involved 
(Sony later testified that databases with credit card data were treated 
with higher security), we did not know if the same individuals were 
involved in both attacks, and the company itself was reporting it as a 
second incident previously unknown to them and not as an update to the 
other breach. Our impression that these were two unique incidents was 
subsequently supported by the reports made to the New Hampshire Attorney 
General's Office for each incident (here and here).

Despite what we thought was an accurate way to track these breaches, one 
commenter to DataLossDB.org questioned our decision to treat the reports 
as two unique incidents. A researcher with Javelin Strategy commented that 
treating this as two incidents instead of one benefited Sony: they would 
not appear ranked 2nd in our list of all-time largest breaches on our home 
page. Since these incidents had the same parent corporation, he suggested, 
they should be treated as one aggregated incident.

While those points may appear reasonable to some, we find them 
unpersuasive. First, we do not make decisions based on whether an entity 
benefits or suffers from a particular decision. We make decisions based on 
whether the available information supports aggregating the data for a 
particular incident or not. In this case, although it is the same parent 
corporation, the available information does not support aggregation. In 
other cases, such as a Wellpoint breach that was initially entered as 
distinct incidents, when my research revealed that there was only one 
incident and that what appeared to be a second incident was really due to 
Wellpoint's vendor not fully securing the web sites after the first 
report, I recommended that those incidents be combined, and they will be. 
But other than a common target - Sony - where is there any evidence that 
this was just one incident? There is none.

We recognize that not everyone will agree with our decision, and that's 
fine. Should new information become available that suggests that a 
one-incident approach is more appropriate for these incidents, we will 
edit our entries.

As always, we welcome constructive thoughts about how to make the database 
more useful to stakeholders, but we do not expect all of our decisions to 
please everyone.