Security rules are wonderful things and nowhere are they more needed than in retail and payment card data. But there is a common criticism of the organization that handles such matters.

Security rules are wonderful things and nowhere are they more needed than in retail and payment card data. But a common criticism of the organization that handles such matters—the PCI Council—is that it delivers security edicts in a vacuum, with minimal regard to how different kinds of merchants function in the so-called real world. Such critics were given three golden examples this month.

The examples, in the areas of cloud guidance, P2PE validations and Windows XP end of life, illustrate the kinds of collisions that are inevitable when committees seek ideal security approaches run into chains with razor-thin margins (or losses), workforce reductions and store closings. Put more bluntly, it’s the age-old battle of the ideal versus the pragmatic.

Let’s take a look at this month’s evidence:

Cloud Guidance

When the PCI Council rolled out its cloud computing guidelines on February 7, one element—dealing with introspection—has been heralded as sound practice while being slammed as unrealistic and impractical. The problem speaks to the very nature of clouds.

In private clouds, retailers can demand unlimited data about their environments; shared cloud providers, meanwhile, simply cannot reveal information about other cloud residents. That very well may mean shared cloud vendors will simply not be able to provide enough information for a retailer to become PCI compliant. Does the council then ban shared clouds—as some have expected—or impose requirements on retailers that they may be unable to fulfill?

Here’s the hot button: the guidelines want to guarantee that retailers will be able to see all of the logs from the cloud to make sure everything is PCI compliant. The problem is that many such logs—in a shared environment—would reveal quite a bit about other cloud residents. Requiring retailers to deliver such data to their QSA doesn’t mean the CSPs will provide it—and simply saying it should be part of contract negotiations doesn’t help much. That said, if PCI demanded it and, therefore, no retailer was able to use a shared cloud unless such compartmentalized access was delivered, then maybe we’d have movement by CSPs as a group to make such radical changes. But anything less is likely to generate little more than frustration, like ordering a young child to lift something heavy that they physically cannot lift.

One retail security executive—working for one of the five largest U.S. chains—said the potential for problems with introspection is not trivial.

“Introspection allows a client VM to see host memory. If my VM and your VM were on the same host, I could read the host’s memory, which contains all the memory on the box, and could read your processes’ memory and scrape card numbers out of your environment. That’s the risk,” she said. “And just to be clear, I can see the host’s memory by exploiting OS or application holes, not by being granted full access.”

The problem is worse than that, though, as such issues can happen accidentally.

“Normally, that’s a technical task and most retailers wouldn’t maliciously try to do that. But are you sure every neighboring VM on your host is that honest? Worse, it could be easy or accidental. If I buy an introspection based tool, it scrapes all the host memory looking for badness. If it searches for common patterns, it could report that it found Visa card #4123456789012345 (because it’s 16 digits that start with a 4). That might be from your VM’s memory, not mine. And now I have a card number from you in my logs.”

P2PE Validation

For the past two years, the Payment Card Industry Security Standards Council (PCI SSC) has been offering merchants offers of a specialized (and simplified) Self-Assessment Questionnaire (SAQ) for those using “validated P2PE (Point-to-Point Encryption)” approaches. At first, the council told merchants to wait while it drew up plans to validate the products. Then—finally—seven months ago, PCI SSC released its standards and told merchants to go right ahead and pick one of these validated options. There’s only one problem: As of February 7th, the council hadn’t validated any.

That’s right. Seven months after the standards were released and nearly two full years from PCI SSC’s initial announcements on the matter, the council has yet to validate a single P2PE vendor that can offer the promised scope reductions and a simplified SAQ to merchants.

Windows XP End-of-Life

PCI DSS has two sunsets coming up. The first is the well-documented end of PA-DSS v1.2 this October. The second, and equally significant, sunset is Windows XP’s end-of-life just a few months later, and this event may have an even more direct impact on retailers.

The demise of Windows XP will challenge retailers with POS or other payment applications running in that environment. These retailers will fall into one of three scenarios, described below. How they choose to address the situation will affect their PCI compliance and, more importantly, their security. There may even be a little fallout for the PCI Security Standards Council (PCI SSC) itself.

On April 8, 2014, about 14 short months from now, Windows XP will reach the end of its life as an operating system. That means that starting on April 9, 2014, Microsoft will no longer market, support or provide regular security patches for that operating system. Retailers with POS or other payment systems running on Windows XP after this date will, therefore, no longer be PCI compliant.

Why does an end-of-life operating system cause a retailer to be noncompliant? After all, the term “end-of-life” appears nowhere in the PCI DSS. A search of the FAQ on the PCI SSC’s Web site also turns up nothing.

Merchants cannot continue to use a payment application based on an end-of-life operating system, because that end-of-life condition runs up against PCI DSS Requirement 6.1. This requirement states merchants must: “Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. Install critical security patches within one month of release.” Once an operating system (or an application) goes past its end-of-life, the vendor does not keep an eye out for new vulnerabilities or release any new security patches.

In addition, and aside from PCI DSS compliance issues, retailers with end-of-life operating systems put themselves squarely in every hacker’s cardholder data breach bulls-eye. The bad guys scan merchants’ networks for weaknesses, and an end-of-life operating system may be an open invitation for them to do their worst—particularly when unpatched vulnerabilities are spotted.

There’s nothing whatsoever wrong with striving for perfection when it comes to issuing standards, especially in security. But tempering it with practicality—and perhaps even a stupendously limited budget—is not a bad thing, either.

Evan Schuman is editor of, a US-based site that tracks retail technology, e-commerce and mobile commerce issues and a Retail Week content partner. He can be reached on