SonyPictures Site Compromised

Published: 2011-06-03
Last Updated: 2011-06-03 19:51:37 UTC
by Guy Bruneau (Version: 1)
13 comment(s)

We have written diaries on Sony’s security woes over the past few months, first one was a DDoS against its infrastructure [1] followed by the hacking of the Sony PlayStation network that took their network offline for several weeks, affecting all its PlayStation customers [2]. This week, SonyPictures was compromised by a group of individuals calling themselves LulzSec who took over 1,000,000 unencrypted plaintext customer password. Last week, another attack took place, this time against Sony Music Entertainment Greece website [3] who took usernames, passwords, email addresses and phone numbers.

One question comes to mind. With all of this data lost, if a PCI compliant corporation can be this easily targeted and compromised, is PCI a good standard to measure security posture?

[1] http://isc.sans.org/diary.html?storyid=10654
[2] http://isc.sans.org/diary.html?storyid=10768
[3] http://mashable.com/2011/05/24/sony-hacker-attack

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

Keywords: Incidents
13 comment(s)

Comments

Back in the days of the Sony BMG CD rootkit, we learned that Sony had a fundamental problem with the concepts of information security and privacy. It looks like they didn't improve much.

My take is if they were found to be PCI-compliant at one time, it was only for the components reviewed, and only at that time. Who knows what they might have done the day after.

As long as organizations use compliance to try to achieve security we will have this problem. They need to have security achieve compliance. It doesn't seem to work any other way.
While I am not very knowledgeable of PCI I do believe I read somewhere that this standard demanded everything stored encrypted, even databases. How could Sony be compliant if they were storing passwords as unhashed plaintext?

Seems Shane is right that they are worried more about meeting the compliance inspection than actually following the standard thoroughly.
Check-the-box security a.k.a "rubber-stamp security", and so it goes...
And there's the rub....were they PCI compliant?
compliance != security
PCI is also only concerned with the security of the scope of payment-handling systems and processes. Most of their breaches aren't mentioned as exposing card data, so the user names and passwords may simply not fall under PCI controls because they're out of scope.
Good point, the user data may have been out of scope for PCI compliance. That only re-inforces the comments of several others, PCI compliance does not mean you have any real security...
I don't believe that's necessarily true. PCI compliance means that you have a specific set of security controls on your Card Holder Environment, and if that was an honest self-assessment or competent external audit, then I would think that you *do* have some real security. Whether or not its adequate against any particular attack will depend on that attack, but it's a good baseline anyway and probably more than what a lot of companies are doing. Like other people have mentioned, this is only the CHE, and if this system was outside that scope, it would not have been audited via PCI (it does appear that this fell through the cracks of Best Practices though.)
From what I've read, the Sony PlayStation network was not PCI compliant at the time of the breach. PCI rules require firewalls to be in place and security updates to be maintained on devices where credit card information is stored *and* on the company's other devices that have network access to devices where credit card information is stored. Several articles have indicated that firewalls were not in place and that security patches were not up-to-date on the servers involved in the breach. Sony may have had a ruber stamp from a corrupt or incompetant PCI auditor to indicate that they were compliant, but the credit card companies can still try to hold them responsible for lack of compliance.
"and that security patches were not up-to-date"

There is an important caveat to that comment. From the PCI FAQs:
---------------------
Would older operating systems that are no longer supported by the vendor be deemed non-compliant with the PCI DSS?

Systems that use operating systems that are no longer supported with new security patches by the vendor, OEM, or developer are not necessarily out of compliance. Compensating controls could address risks posed by using older operating systems. Exploit of legacy code is the main risk posed by an older operating system. Since well-known exploits are typically included as signatures to anti-virus, IDS/IPS and firewall filtering, a compensating control to consider is performing an exhaustive search to ensure that all known exploits for that operating system are identified, and that anti-virus, IDS/IPS and firewall rules are all updated to address those exploits. Other compensating controls could include monitoring IDS/IPS and firewall logs more frequently than required (for example, the requirement is for daily log reviews, so more frequently may be continuously and automated), or isolating and segmenting their POS systems via firewalls from the Internet and other systems in the cardholder data environment. The eventual solution is to upgrade to a new and supported operating system, and the entity should have an active plan for doing so. For more help with compensating controls, and for questions about whether a specific implementation is consistent with the standard or is 'compliant', please contact a Qualified Security Assessor.
-----------------------------
So as long as you're running end-of-life systems but have applied all of their patches, you could be found compliant. There is a caveat in the external vulnerability scan that says an out of date operating system is an automatic fail, but I've never seen that diagnosis made reliably by an automated tool from the Internet.

Diary Archives