On Sony PSN Breach and Commenting

Here is why I am rejecting many requests to “comment on the Sony PSN breach”: because most of such post-breach comments by outsiders are pure drivel, that rarely even RAISES to the level of FUD.

So:

Q: What got stolen in the now infamous Sony PlayStation Network (PSN) breach, the #4 largest ever at DatalossDB?

A: Definitively, for all PSN users: “name, address (city, state, zip), country, email address, birthdate, PlayStation Network/Qriocity password and login, and handle/PSN online ID” (source: Sony letter, obtained via dataloss-discuss@datalossdb.org)

Possibly: “profile data, including purchase history and billing address (city, state, zip), and your PlayStation Network/Qriocity password security answers” (source: same Sony letter)

Total record count stands at 77 millions.

Q: Were all the credit cards stolen?

A: I don’t know and Sony says THEY DON’T KNOW either.

 

Q: What does it mean, “they don’t know”?

A: To me, it means they sucked at security monitoring and sucked REALLY hard at logging, and likely didn’t have database logging/auditing. Allowing the breach to happen can happen to anybody, but not knowing AFTER the breach whether REGULATED data was stolen point to gross incompetence.

 

Q: Were they PCI compliant?

A: I don’t l know. Most likely, they were validated as PCI DSS compliant at some point (I’d assume they are Level 2 or maybe Level 1). Was there a QSA involved? I don’t know, but I’d guess they are comprised of multiple  Level 2 (and below) merchants, not one Sony-wide Level 1. Thus they self-assessed via SAQ.

 

Q: But were they REALLY PCI compliant?

A: I don’t know. Don’t bug me about this one  Smile

Q: Were they PCI compliant at the presumed time of the breach?

A: I don’t know. Personally, I seriously doubt it since maintaining PCI compliance at all times is extremely hard (example) and access to regulated data should be logged and monitored.

 

Enjoy!

Comments

Post a Comment

Popular posts from this blog

Monthly Blog Round-Up – August 2018

Here is my next monthly "Security Warrior" blog round-up of top 5 popular posts based on last month’s visitor data  (excluding other monthly or annual round-ups): “New SIEM Whitepaper on Use Cases In-Depth OUT!” (dated 2010 – much ancient!) presents a whitepaper on select SIEM use cases described in depth with rules and reports [using now-defunct SIEM product]; also see this SIEM use case in depth and this for a more current list of popular SIEM use cases. Finally, see our research on developing security monitoring use cases here – and that we updated for 2018 . A lot more SIEM use case discussion is coming, here is a new post for 2018 SIEM use cases. “ Simple Log Review Checklist Released! ” is often at the top of this list – this rapidly aging checklist is still a useful tool for many people. “ On Free Log Management Tools ” (also aged quite a bit by now) is a companion to the checklist ( updated version ) “ Why No Open Source SIEM, EVER? ” contains some...
Read more

Got A Pile of Logs from an Incident: What to Do?

Image
As I am going through my backlog of topics I wanted to blog about (but didn’t have time for the last 4-6 months), this is the one I really wanted to explore. Here is the scenario: Something blows up, hits the fan, starts to smell bad, <insert your favorite incident metaphor> … either in your IT environment or at one of your clients’ Logs (mostly) and other evidence is taken from all the components of the affected system and packaged for offline analysis You get a nice 10MB-10GB pile of juicy log data – and they wants “ answers ” What do you do FIRST? With what tools? Let’s explore this situation. I know most of you would say “ just pile’em into splunk ”  and, of course, I will do that. However, that is not a full story. As I point out in this 2007 blog post (“ Do You Enjoy Searching? ”), to succeed with search you need to know what to search for. At this point of our incident investigation, we actually don’t! Meanwhile, the volume of log data beyond a few megabytes makes “tri...
Read more

How to Replace a SIEM?

Image
Note : this has been written for “Cisco MARS blog” as a guest post and is reposted here for posterity. Ouch! That “Venus” SIEM   appliance that we got with routers has finally croaked. That piece of PHP brilliance that pre-pre-previous security engineer wrote has been buried under the thick pile of XML. That managed SIEM provider has annoyed us one last time. What do the above situations have in common? The unfortunate time to replace your SIEM has come. What to expect, apart from copious amounts of pain? This post will shed some light on this conundrum, based on author’s experiences. First, it goes without saying that it is better to choose the right SIEM the first time (e.g. see “ On Choosing SIEM ” and other posts mentioned below) than to migrate from a SIEM that has been collecting logs (and dust) for a few years. However, you might not have any say in the matter – you might have inherited it, your “evil boss” might have procured the previous SIEM without asking you or ...
Read more