Windows XP End-of-Life and its Implications on the PCI DSS

I’m sure by now that most of you know that the final bell is calling for Windows XP, Microsoft will discontinue support for it on the 8th April 2014. And you may also have seen that there has been some back-peddling from Microsoft on what exactly will and won’t stop on that date mainly because, despite this End-of-Life (EoL) date being around for some years now, people and businesses still seem to have been surprised by it. So, in short, from the 8th April there will be no new security updates, non-security hotfixes, assisted support or online technical content updates. Also Microsoft will stop providing Microsoft Security Essentials (MSE) for download on Windows XP which is a little odd (you could just download it on another OS and copy in across).

So what will be continuing?

Well, Microsoft have announced that MSE for XP will continue to get updates to anti-malware signatures and the engine until 14th July 2015 and that the Malicious Software Removal Tool (MSRT) will continue to be updated and deployed on the infamous ‘Patch Tuesdays’ until the same date. Furthermore, existing security updates for XP will still be available through windows update indefinitely. So is this enough to remain PCI compliant using Windows XP?

In short, no.

I refer to Requirement 11.2.2 (both in V2.0 and V3.0), this requirement is to have one passing ASV scan per quarter, and this leads to the ASV Program Guide which states the following:

“The ASV scan solution must be able to verify that the operating system is patched for known exploits. The ASV scan solution must also be able to determine the version of the operating system and whether it is a version no longer supported by the vendor, in which case it must be marked as an automatic failure by the ASV.”

This means that if the ASV scan shows and unsupported OS it will fail and continue to fail until its changed, meaning it’s not possible to gain compliance.

So what options are there?

Well the first is obvious, upgrade to a newer OS such as Windows Vista, Windows 7 or Windows 8 but this may not be practical in the time frame or may be very expensive for some businesses, so let’s look at alternatives.

The first point is that if the ASV scan can’t reliably detect the OS then the scan will pass, if you can sufficiently harden your systems to prevent the OS from being detected by a scan then it should be just as difficult for an attacker to find the OS. Of course this is not a perfect solution and should probably be combined with some other techniques. One of which could be a partial upgrade, i.e. only upgrade the machines which are controlling and protecting the perimeter of the cardholder data environment (CDE), for many organisations this could significantly reduce the upgrade cost and still provide good protection and the crucial entry point to the CDE.

Another solution is to deploy an anti-malware application that supports ‘whitelisting’, creating a baseline of authorised code that can be executed on the machine, but this does have the drawback of needing to be changed anytime you change the machine. The final option that could be considered is one of the new P2PE solutions that the PCI SSC have approved, as this means the cardholder data is encrypted before it gets to the OS but again this could be expensive for larger deployments.

As ever with these kinds of problems each business is unique and, as such, will require a unique solution, but I think it’s important to note that whichever solution you use if the ASV scan shows an un-supported OS you’ll fail. So you can’t avoid upgrading indefinitely, you’ll have to bite the bullet eventually.