Monthly Archives: June, 2011

Sony had HOW many breaches?

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 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 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 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.

/ Dissent