As enterprises prepare for a potential security catastrophe after next month's Windows XP end-of-life date, retailers and payment-processing firms face an additional risk: being unable to comply with the Payment Card Industry Data Security Standard.
Technically the SSC can say there's wiggle room with XP, but if someone finds it, the organization will fail.
security engineer, Trustwave
On April 8th, Microsoft will end support for its legacy Windows XP operating system. Customers using XP, which was released in 2001 and is based on kernel technology that dates back even further, will no longer receive technical support or security software updates from Microsoft.
The software giant cites a variety of reasons for ushering customers off of XP and onto its newer operating systems, including "dramatically enhanced security." XP has faced an ongoing series of zero-day attacks and has generally been an attackers' delight in recent years, in part because the OS doesn't natively support Microsoft's more recent security technologies, such as Data Execution Prevention and Address Space Layout Randomization.
To increase awareness among organizations that comply with PCI DSS, the PCI Security Standards Council (SSC) late last week released a new infographic (see below) that highlights the increased security risk associated with running the XP OS, which, according to February 2014 data from NetMarketShare, still resides on nearly 30% of desktop computers.
Potential security issues aside, XP will pose a PCI DSS compliance risk once security patches end next month. PCI DSS Requirement 6.2 states that system components within the cardholder data environment (CDE) must be protected from known vulnerabilities by having the latest vendor-supplied security patches installed.
So once XP security patches end next month, will that mean a merchant would fail a PCI DSS assessment if it has any XP-based systems in its CDE? Though the SSC acknowledges the overall security risk XP poses, a source close to the council admitted it is in a "tough spot" because it is difficult to provide "yes or no" assessment guidance on XP.
"Whether a company running XP is going to remain compliant with PCI DSS or not is a call, like all compliance-related ones, that is going to be made by an organization's QSA [Qualified Security Assessor] during the assessment process," said Ella Nevill, a vice president with the PCI SSC. "The council's aim is to raise awareness of the upcoming changes with Microsoft XP and to get people to start this conversation with their assessors and acquiring banks now if they haven't already done so."
Greg Rosenberg, a security engineer and PCI Qualified Security Assessor with Chicago-based security and compliance vendor Trustwave, said that despite the SSC's reticence, once the end-of-life date passes, virtually any instance of XP in a CDE will result in an instant assessment failure because there will be no reliable mechanism to patch critical security issues.
While QSAs may debate the extent to which Requirement 6.2 applies to an unsupported OS, Rosenberg said it's actually the vulnerability-scanning guidelines in Requirement 11.2 that make XP untenable. He said that when conducting a vulnerability assessment on a system, an assessor uses his or her findings to assign it a score based on a common methodology, typically the Common Vulnerability Scoring System. The threat posed by an unpatchable XP system would immediately result in a failing score.
"Technically the SSC can say there's wiggle room with XP," Rosenberg said, "but if someone finds it, the organization will fail."
Windows XP prevalent on POS systems
This reality poses a serious problem for merchants given the prevalence of Windows XP in cardholder data environments. Among more than 100,000 point-of-sale systems running Trustwave's TrustKeeper Agent POS endpoint security product, Rosenberg said that tens of thousands of those systems use Windows XP. An exact figure wasn't available, but he said Trustwave believes that the percentage of Windows XP POS systems in the field today is significantly higher than 30%.
Rosenberg indicated that the percentage of integrated POS systems -- those combining a card-swipe device, terminal and connected workstation to process card-present transactions -- running XP is even higher. Despite XP's prevalence, though, many merchants have no idea what platform their POS systems run because they fail to recognize why it matters, their payment system providers don't make it clear, and there's often no obvious Windows logo on the devices or during the boot process.
Worse still, Rosenberg noted, is that some payment system providers still sell new Windows XP POS systems today, even though by the time they are installed, they'll already be vulnerable.
"It's not because their intent is to be malicious; it's more just general ignorance," Rosenberg said. "As this momentum builds toward the end-of-life date, we'll get more awareness, but in some ways that'll be too late."
Windows XP: Replacement or use compensating controls?
The options for dealing with the Windows XP PCI compliance problem generally fall into two categories: upgrade or replace existing Windows XP systems, or attempt to implement compensating controls. Getting rid of XP on servers and traditional endpoints is difficult enough, but finding the way forward with XP-based POS systems is a particularly vexing challenge.
The easier path would be to implement compensating controls, which are defined by the SSC as alternative security controls implemented when a legitimate business or technical constraint prevents an organization from meeting a PCI DSS requirement.
Not surprisingly, vendors are promoting various products as being able to offer compensating controls for XP-based POS systems. A recent McAfee white paper promotes application whitelisting as a compensating control, while Bit9 recommends advanced endpoint security hardening.
Our sister site WhatIs.com has compiled TechTarget's best resources on the Windows XP end of life and the transition to Windows 7 and Windows 8.
For its part, the SSC says compensating controls may be used temporarily to address the risk posed by unsupported operating systems, but only if an organization can demonstrate that the alternative effectively guards against the exploit of vulnerabilities in the unsupported OS code.
Rosenberg said compensating controls most likely to be employed will include a combination of whitelisting, heuristic host-based intrusion prevention systems and extended patch support from a third-party vendor. However, he has yet to see an effective set of compensating controls to protect POS systems running XP that would enable a merchant to pass a PCI assessment after the end-of-life date.
The alternative, upgrading or replacing XP-based POS systems, is a time-consuming, expensive process that even for the smallest merchants can cost tens of thousands of dollars. Rosenberg also noted that software-compatibility issues often significantly add to the time and expense.
The most palatable migration path, according to Rosenberg, is to move XP POS systems to Windows Embedded, a stripped-down OS that resembles XP but removes various dynamic link libraries and other system components. Windows Embedded's Jan. 12, 2016, end-of-life date gives merchants more time to develop a long-term plan for their POS platforms, but Rosenberg noted that an XP-to-Embedded migration can take months and be costly depending on how many POS application tweaks are involved.
For now, merchants running XP POS systems may have no obvious path to PCI compliance, but Rosenberg said he hopes awareness of the XP end-of-life date increases among merchants, particularly smaller ones that are the most ill-equipped to deal with it from a compliance perspective.
"From a risk perspective, XP is not being talked about enough," Rosenberg said. "Bad guys are going to use this to pilfer account activity from merchants, and the fees from that type of event can get into the tens of thousands or hundreds of thousands of dollars."