Thursday, July 29, 2010

Au Contraire - Latest Gotcha from PCI SSC

Several month back many forums and blogs were discussing the (at that time) up and coming July 2010 sunset of Windows 2000. Many of these discussions included other already sunsetted operating systems. There were some heated debates over whether or not proper lock-down and compensating controls could keep a merchant compliant. Most of these discussions were settled by a posting in the PCI SCC 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.

Fast forward to today. Now, for many merchants and vendors, comes the first Windows 2000 post sunset scan from a prominent ASV - FAIL. Reason given: One or more scanned servers determined to be running Windows 2000. Upon referring this prominent ASV to the above FAQ on the PCI DSS site, they refer to the Technical and Operational Requirements for Approved Scanning Vendors (ASVs) on the same PCI DSS site:
Technical and Operational Requirements for ASVs

Obsolete environment

The ASV must report and determine as non-compliant any identified obsolete software (for example, application software or operating systems (OSs) no longer supported by the respective manufacturers. Obsolete software may expose the infrastructure to a security-related vulnerability.

The FAQ that many merchants and vendors use takes a risk assessment perspective whereas the Operating Requirements for ASVs takes a MUCH harsher authoritarian perspective -- "FAILED!" It's no wonder there is still so much confusion about PCI even after years educating the masses about PCI; people are still just as confused and pulling their hair out. I sure hope PCI SSC irons this one out quick.

An interesting side note is the wording of the Operating Requirements for ASVs: "Obsolete software may expose the infrastructure to a security-related vulnerability," yet PCI has deemed it non-compliant -- so is it vulnerable or not? If not, why is it not compliant? But this is straining at gnats -- the bigger issue is assuring people that obsolete O/Ss are not necessarily out-of-compliance while telling ASVs that obsolete O/Ss must be deemed out-of-compliance.

If you read any of my previous posts, I always harp on lowering your risk profile by eliminating card holder data from your environment. This emphasizes my belief that if you suffer a breach of card holder data, you will be found out-of-compliance no matter how compliant you thought you were. Using this as an example, if you were using Windows 2000 (post sunset) in your payment environment and your PCI assessment was based on the PCI SSC FAQ, the ASV document would deem you out-of-compliance.