Thursday, April 28, 2011

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!

Wednesday, April 27, 2011

Peculiar Bit on Compliance vs Risk (Again)

So, yes, seatbelts. One of my favorite compliance metaphors lately, which I have considered infallible (and used everywhere). After all, everybody knows that seatbelts save lives and there is plenty of reliable evidence of that, coming from DoT / NHTSA studies (this one, BTW, is worth a skim for the infosec crowd, for sure), etc. So, we all know that….

image

However, the other day I was in Russia, traveling to Lake Baikal in particular (long story, but it has to do with my wife’s love of exotic locations, both tropical and permafrost-bound)

image

Given that it was still winter and given that roads in Russia are …mmm…. not, most locals simply drive on the ice of a lake – it is way smoother, shorter and faster than “doing the road thing.” Besides, that is the only way to reach some lake islands in winter (bonus question for advanced readers: how do the locals get to those islands when the lake is already frozen [no boats], but the ice is too thin for cars or already broken down [no cars]? Answer)

In any case, we got into a car and I started to fasten the seatbelt. At that very moment, the driver looked at me funny and said something along the lines of “Wow, having suicidal thoughts lately, aren’t you?”

Baikal 015

And at that moment, risk collided with compliance in my head. Boom! I was one of one of those rare environments where your risk model is completely different (from the one regulators imply when building the regulations) and traditional compliance rules just don’t apply. By the way, even traffic police there will never fine you for “driving on the lake with seatbelts off.”

Well, all others must go do PCI compliance Smile

Friday, April 22, 2011

SANS 7th Log Management Survey 2011 is [Almost] OUT

SANS is almost ready with their 7th Annual Log Management Survey, which would be unveiled at two SANS webcasts on April 25 and April 26 (both at 1PM EST / 10AM PST). The SANS log management survey is a useful measure of what organizations do with logs and how it changes year over year. SANS states that “organizations still want better access to their log data and better integration with third party security software and their SIEM systems and their Windows logs.”

I am allowed to share a few (very few!) bits from a report, but expect full analysis from me when it officially comes out. So:

  • Collection has dropped way down among the most challenging tasks related to logs – now categorization, reporting, analysis and other higher level tasks show up as top challenges (good news!)
  • Alerting / detection again trumps search / investigations as far as basic log use cases are concerned (it is definitely very interesting since post-incident search requires much less tuning than alerting)
  • PCI DSS still rules the roost of “logging for compliance”… which mandate is #2? Well, wait for the survey to come out Smile
  • Windows logs still spell “t-r-o-u-b-l-e”, even after Windows Vista and new XML logging (only 10% are happy with it…): “analysis is the top problem that organizations have with Windows log management.” And Snare agent still rules.

Enjoy the webcasts and the report next week!

Possibly related posts:

Tuesday, April 19, 2011

Verizon DBIR 2011 is OUT!

OMG, today is The Breach Day, an official security holiday. Verizon Business has just released their super-famous “2011 Data Breach Investigations Report
Here are my notes, thoughts, jokes and highlights (are images and quotes are from VzDBIR 2011).

First, we all know that science has been looking for a scientific proof of stupidity for years, and finally it is here, delivered through the power of a Pie Chart below:
vz-IMG_0020
In other words, most of the damaging, expensive breaches has cheap countermeasures that people just don’t do. Niiiice!

On a more serious note, not only many of the breached organizations were ignorant, there were not even close to being PCI DSS compliant (more on this below).
vz_IMG_0006
Doesn’t it make you think that we are going backwards in security, “APT” notwithstanding?
So, who ARE these people? Well, we now know:
vz-IMG_0007

Key industries are those know for limited infosec resource and lots of juicy payment card numbers, often combined with other useful information such as mailing addresses.

That is likely why we have less records stolen overall (no known mega-breaches), but A LOT of smaller “losses”, largely attributes to industrial “hacking machine” of cybercrime hitting smaller business head-on.
And how exactly they are getting owned – surely with an ancient Chinese secret APT hacking tools? Well, yeah – on the “ancient” part”: it is password guessing mostly that harks back from the 1970s:
vz-IMG_0012

So, Verizon says: please go and change that password that still says "password" - you will help your security posture a lot!

What specific computing assets are bearing the brunt of attacks? This easy diagram shows:
vz-IMG_0013
So, merchants, do you still have that POS server in the back of the store with PANs of all the cards you ever accepted? Congrats, your donation to  cybercrime fund has been accepted…

To make things even sadder, people are not detecting shit:
vz-IMG_0014
The above shows that the most typical time between the incident  and its detection is “weeks.” Still want to field that real-time monitoring system? Save some money and buy a cheaper log management system + establish a solid log review process (example).

The Verizon team does give the same advice I often give my clients today: "Change your approach to event monitoring and log analysis: Based on the data we collect in the Time of Breach events, we believe that organizations would be better served to focus less on the “real-time” methods of detection, and more on the “this week” methods. If we can shift Compromise to Discovery time frame from Weeks and Months to Days, it will significantly reduce the damage done to your organization"

Let’s REALLY crank up the sadness – even after WEEKS or MONTHS, who is actually doing detecting? Not the security team, mind you. Yup, The Third Party wins again!
vz-IMG_0015
Your own log review detects breaches LESS OFTEN then “happenstance discovery by unrelated 3rd party” [why? because you ain’t doing that log review!]  So, random people stumbling on your weeks-old breach evidence is more "effective" than your log analysis. This is how bad things really are… The above graph made me cry in pain, BTW.

Specifically, the report states "If there is one positive note that we can squeeze out of these statistics around active measures, it’s that discovery through log analysis and review has dwindled down to 0%. So the good news is that things are only looking up from here. Yeah, that’s squeezing pretty hard, but what else can we do? Figure 41 continues to show that good evidence of the breach usually exists in the victim’s log files waiting to be used. "

Finally, does PCI compliance helps? Well, we’d know only if the organizations were in compliance, and most aren’t (not even at ASSESSMENT TIME, much less at BREACH TIME):
vz-IMG_0018
End of the story, really.

Overall, this was the saddest VzDBIRs I ever read … Wade and Alex, you made me and my puppy weep Smile My highlights might be fun, but PLEASE do take time to read the entire report [PDF]!!
Possibly related posts:

Monday, April 04, 2011

Monthly Blog Round-Up – March 2011

Blogs are "stateless" and people often pay attention only to what they see today. Thus a lot of useful security reading material gets lost.  These monthly round-ups is my way of reminding people about interesting and useful blog content. If you are “too busy to read the blogs,” at least read these.

So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts/topics this month.

  1. My PCI DSS log review procedures that I created for a consulting client and posted on the blog (sanitized, of course!)  took THE top spot again: the first post “Complete PCI DSS Log Review Procedures, Part 1” and the whole series “PCI_Log_Review” would be useful to most large organizations  under PCI DSS (as well as other regulated organization that are looking to create a structure log review policies, procedures and process)
  2. SIEM Resourcing or How Much the Friggin’ Thing Would REALLY Cost Me?” is a new post about figuring out the costs of your SIEM/SIM/SEM implementation – it became an instant favorite and took the next top5 spot in March.
  3. The next is “Log Forensics and “Original” Events” that covers the issue of ‘raw’, ‘original’ or ‘native’ log records and their use for forensics.
  4. UPDATED Free Log Management Tools” is next; it is a repost of my free log tools list to the blog. I repost it every time after an update.
  5. Finally, my RSA 2011 notes (“RSA 2011 Conference Notes”) also are in the top list.
  6. Simple Log Review Checklist Released!” is still one of the most popular posts on my blog. Grab the log review checklist here, if you have not done so already. It is perfect to hand out to junior sysadmins who are just starting up with logs.

Also, as a tradition, I am thanking my top 3 referrers this month (those who are people, not organizations). So, thanks a lot to the following people whose blogs sent the most visitors to my blog:

  1. Anonymous “PCI Guru”
  2. Walt Conway
  3. D. Orlov (please let me know what “D” stands for – your blog is not exactly clear about it Smile) Also, thanks for translating my PCI DSS log review procedures into Russian….

Also see my past annual “Top Posts” - 2007, 20082009, 2010). Next, see you in April for the next monthly top list.

Possibly related posts / past monthly popular blog round-ups:

Sunday, April 03, 2011

Source Boston 2011–See You There!

Just a quick post about my upcoming presentation at Source Boston 2011 – one of the most fun security conferences around!

The details are quoted from the conference site:

So You Got That SIEM. Now What Do You Do?
Anton Chuvakin, Principal, Security Warrior Consulting (@anton_chuvakin)

Many organization that acquired Security Information and Event Management (SIEM) tools and even simpler log management tools have realized that they are not ready to use many of the advanced correlation features, despite promises that "they are easy to use" and "totally intuitive."
So, what should you do to achieve success with SIEM? What logs should you collect? Correlate? Review? How do you use log management as a step before SIEM? What process absolutely must be built before SIEM purchase becomes successful?

At this presentation, you will learn from the experience of those who did not have the benefit of learning from other's mistakes. Also, learn a few tips on how to "operationalize" that SIEM purchase you've made. And laugh at some hilarious stories of "SIEM FAIL" of course! As a bonus track, how to revive a FAILED SIEM deployment you inherited at your new job will be discussed.

Dr. Anton Chuvakin is a recognized security expert in the field of log management, SIEM and PCI DSS compliance. He is an author of books "Security Warrior" and "PCI Compliance." Currently he runs his consulting practice focused on SIEM, log management as well as compliance.

So, if you are around Boston on April 20-22 – see you there!

Dr Anton Chuvakin