Sony: Compliance Lessons Learned

The Now "Infamous" Sony Hack

It was reported late last month that attackers had penetrated Sony's PSN (PlayStation Network) platform. It has been rumored that reverse engineering the PlayStation firmware, coupled with vulnerabilities in Linux servers and unencrypted data traversing the network, led to the exposure of over 77 million users’ information being leaked, possibly including 2.2 million credit card numbers.

News outlets have also reported that Sony knew about the breach a full six days before notifying subscribers. Other reports state that that while credit card numbers were being stored encrypted, three-digit pin numbers were not being stored at all. In addition, personal information such as email addresses, names, mailing addresses and answers to security questions were also stored unencrypted. Passwords were in fact being stored hashed. Yes, you read correctly, the passwords to each person's account were hashed, but the security question, answer to the security question and their email address were all left in the clear. Encryption can be a great thing to protect information, but only when used correctly.

PCI Compliance?

Discussing PCI compliance surrounding a breach is always a hot topic. Whether they were compliant or not, it’s clear that there are some things that we can learn from Sony:

Being compliant only occurs at a point in time, and it’s not just about vulnerabilities. Compliance covers storage of data, which data you are storing, how you are storing it, and how long you are storing it. It was reported that credit cards were on file with Sony from as early as 2007. While many cards were not active (although I imagine many credit card numbers remain the same, the expiration dates change, although they are likely not too difficult to predict) at the time of the breach, the question that needs to be answered is “how do you know what you are storing?” I have to admit, I always thought about identifying PII as something you do to protect both your own organization and your customers. However, there is nothing stopping you from looking for any PII, such as credit card numbers, on your network to help maintain compliance, security, or even your own data standards.

For a detailed look at how to use Tenable's software to assist with PCI DSS compliance, check out the paper "Real-Time Compliance Monitoring" by Ron Gula. This paper walks you through each item in the PCI DSS and how each of our tools can help maintain compliance on an ongoing basis.

Detecting Outdated Software

An unofficial report, specifically a Pastebin link with a chat log, was published and disclosed that Sony was running outdated Linux software (Sony has since denied these claims):

• Apache 2.2.15
• Linux kernel 2.6.9-2.6.24

It’s always easy to look back after a compromise and identify where things had gone wrong. Managing production systems is not easy, and neither is applying updates to systems supporting 77 million users. However, that is no excuse for running outdated software.

Another interesting note about the alleged attackers’ chat logs is the identification of backported software. The attackers knew that banners may not reflect the actual software versions. In fact, if you search on Google for backports using “Apache 2.2.15”, the results are specific to Debian and Ubuntu, which could have been the versions in use at Sony. Nessus will identify the backported software, and more on this topic is covered in the article "Advantages Of Running Both Network & Authenticated Nessus Scans".

At some point in your compliance strategy, the rubber needs to meet the road and you have to take action. Tenable has a defined and repeatable process for checking that systems are running the latest software. Some examples include the methods described in the paper "Performing PCI DSS and OWASP Web Application Audits with Nessus" and "The Value Of Credentialed Vulnerability Scanning".

Conclusion

Being compliant to any particular standard is only one step towards security. If you do not have some process for implementing and maintaining compliance to either an external standard (such as the PCI DSS) or your own internally developed standards, you haven't taken the first step (some may argue you haven't installed the staircase yet). Sony has hired a CSO, and hopefully develop their practices from their own lessons learned.

On a lighter note, see this post for a list of the top ten things Sony can do to make up for the breach, with #1 being "Flowers on your birthday, sent by Sony and by the hacker who now knows when it is."

References

• Sony Shares More Details On PlayStation Network Breach
• Passwords and security questions (Unofficial reference)
• Server was running old Apache and Linux (Unofficial reference)

Resources

• PCI-DSS Plugins For Nessus