Can Your Point of Sale Be Compliant after the End of Microsoft XP?

Windows XP has had a good run.

It first came out in 2001, and in April of 2014, Microsoft will retire the operating system.

This means that software patches and support will no longer be available for the operating system.

From a PCI compliance standpoint, merchants using Windows XP will have problems maintaining compliance because they cannot keep their operating systems patched to protect themselves from the latest vulnerabilities.

On the flip side, there are many Point of Sale (POS) software packages that have only been validated using Windows XP, and if another operating system is used instead, it will violate the official implementation guide (and thus fall out of compliance).

Our customers have been asking us for guidance, so we did a little research.

To begin with, we had a few discussions with some QSA’s about the questions surrounding Windows XP End of Life (EOL) and validation of software using only a certain OS. We wanted to get their opinions on how they saw the upcoming EOL of the product and the need to patch.

All 3 of them told us that they would reject a system that was using XP after Microsoft stopped supporting the operating system (even if that was the only OS for which the POS software was validated).

Here is the crux of each of their arguments:

1. The 1st QSA explained that even though the OS has been patched with the latest vulnerabilities addressed new vulnerabilities come out all the time. The dll’s in Widows XP are still in common with later operating systems.

   If a vulnerability is addressed in one of them, there is an excellent chance that the vulnerability will exist in XP. Therefore, the system will be vulnerable with limited ways to protect it (since Microsoft will not be publishing a patch for XP anymore).

2. The 2nd QSA basically stated that a compensating control would not be sufficient unless the company using the control actually had the source code for Windows XP and the ability to update the code as necessary.

   Since Microsoft is not giving up the code to XP anytime soon, this is not a possibility. He would, therefore, fail the system.

3. The 3rd QSA stated that he did not know of a compensating control that would be sufficient in that it needs to provide greater security than the standard envisioned to be an acceptable compensating control according to PCI.

Furthermore, 403 LABS has a QSA named Walt Conway who published an opinion piece on this topic: Windows XP End of Live Could Cripple PCI Compliance He gives numerous reasons why using XP will not be PCI compliant.

With all that said, all hope is not lost.

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.

After listening to all the arguments, we think we have come up with something that would pass an evaluation. We are therefore suggesting the following as a compensating control that might be possible (but it might not be practical).

You would have to have a business agree to the heavy restrictions and an independent QSA agree that it is sufficient:

(The argument as to why the compensating control is necessary):

1. PA-DSS software is only validated to XP / Newer OS does not support all functions necessary for business / Newer OS did not pass testing with POS software / …other reasons I’m sure exist as well Points of the control: 1. The POS system that uses XP must be in their own port in a firewall, or the local software firewall must be implemented (if they must share a switch due to port density).

2. Each POS system must be restricted from other systems on the POS network to only the machine they need to work (stations to server and not each other, even on the same physical network).

3. Only the IP ports used by the POS application should be allowed via firewall policy for station to server communication. If a software firewall is implemented, then the restriction must be made on each machine in its software firewall.

4. Other communication to in the CDE should only be to update software patches and anti-virus (locked down to IP and port).

5. Server should only have access to transmit data to CC processor (locked down by IP and port)

6. No other Internet access (outbound or inbound at all). This includes no access via a VPN (2 factor or not), no remote support, and no Web browsing (among other things).

7. Any other communication will need to be in a segmented network on a machine with no access to the CDE.

1. No external access into the network which will thwart external exploits because communication is more limited than what is allowed by PCI.

2. Limiting outbound access to the Internet so severely reduces the chance of an application exploit from a rogue or compromised Internet site utilizing a flaw in the OS or other software

3. Internal exploits will be likely to fail since network communication is so limited in scope beyond what PCI allows.

In the end, upgrading to a more modern OS going to be required eventually. If you can make the compensating control I list above work in an environment, you might be able to delay the inevitable.

To be clear, every source we contacted and all of our research concluded that limiting the risk associated with EOL operating systems was more crucial than the Implementation Guide of the software manufacture. Software companies will need to work on validating their POS software using a more modern operating system, but the immediate concern is the OS that will be shortly be vulnerable after it is no longer supported.