PlayStation: You’re doing it wrong. While doing it right.

PlayStation: You’re doing it wrong. While doing it right.

Dean OcampoMay 2, 2011, 09:54 am

Security professionals are gossip hounds just as much as everyone else. While we haven’t been chatting about who would be designing Kate Middleton’s dress, we have been chatting about what happened to PlayStation last week. And the conjecture seems to be an APT like attack that used multiple vectors to get into Sony’s systems (although Chris and I duked it out on really what is APT, a topic for another cup of coffee). The crux of the conversation is that Sony was using the Gold Standard in the industry by encrypting their database. To which the rest of us in the security industry replied, “So what.”

Database encryption is only part of the solution. Sure, it’s a great tool, but it’s not foolproof- just ask PlayStation. That’s why I thought I’d discuss a couple approaches that lock down database encryption, and possibly (and I say possibly), might have precluded the PlayStation breach.

Identity Management

So at the end of the day, while the database was encrypted, proper authentication and identity management was probably where this breach could have been stopped. The problem with an APT-style attack is there are so many ways to get in, but having a granular and enforceable authentication schema is one of your best defenses. In terms of the database world, this is one reason why a lot of sophisticated folks choose to do their encryption at the application tier. The problem with a lot of our databases is they were constructed to be fast, and building in authentication and authorization checks wasn’t at the forefront of DBAs mind. So most databases were originally built with things like pooled database connections, etc. that sped things up- which essentially means there is no concept of end user for database requests. This is why application level encryption is so powerful, you can easily tie in application user to encryption activity, and by extension database access. In terms of Sony, one could conjecture that even if an account have been breached, the scope of what they could get to would be severely limited rather than the carte blanche access to 70M records. Until that database tier is properly tied to the user and application tiers, it’s going to be a big phat target.

Expected Usage Violation

Accessing and decrypted 70M user records. Really? Doesn’t that sound a little odd? I have to admit I see very few people really address this and I’m not quite sure why. Even when we have a product that says right in the GUI , “would you like to set a rate-limiting or time-of-day policy for data access?” people still don’t in large numbers. To be fair, most people I know are so overloaded that getting to the cool stuff suffers from plugging the leaks in the ship. But regardless, setting expected usage bounds is huge way to control breaches! One has to wonder if WikiLeaks would have been successful if the government IT controls had enforced a policy that said it is against expected usage to have an Army PFC access 350,000 records. My point is here, had encryption been coupled with expected usage two things could have benefited Sony a) rate limiting would have restricted the total number of records breached and b) an alert could have been easily kicked off to their SIEM and SOC (Security Operations Center) so they could have acted more quickly. Good database encryption let’s you monitor and force this usage.

So maybe Sony’s breach can remind the rest of us that database encryption as a stand-alone tool isn’t perfect but when done right it can set up identity options and expected usage enforcement that can greatly lock it down. -Dean