PCI’s New Cloud Guidance: Great Ideas, Short On Realism

Written by Evan Schuman
February 11th, 2013

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?

(Related story: “PCI Cloud Guidance: Private Cloud Is The Preferred Way To Go”)

The guidelines—which are not edicts from the council (yet) but, indeed, are solely guidelines—fairly describe the various types of cloud offerings, from the private cloud to the various shared options: community cloud; public cloud; and hybrid cloud. Although acknowledging that retailers may have limited control of the environment and the information in a cloud model, the council still places demands on the information gathered for PCI compliance.

“If payment card data is stored, processed or transmitted in a cloud environment, PCI DSS will apply to that environment, and will typically involve validation of both the [cloud service provider’s] infrastructure and the client’s usage of that environment,” the guidelines say. “The allocation of responsibility between client and provider for managing security controls does not exempt a client from the responsibly of ensuring that their cardholder data is properly secured according to applicable PCI DSS requirements.”

Retailers have that responsibility? Yes. But do they have the authority to make good on those responsibilities? Not necessarily.

Here’s the hot button section: 6.5.4 Hypervisor Access and Introspection. And the phrasing: Cloud service providers (CSPs) “using introspection should be able to provide their clients with all applicable introspection logs for that client’s environment including, but not limited to, authentication details, disk and memory access requests, and API calls. All introspection activity should be mapped to the individual user account performing the activity, and logs should be reviewed on a continual basis to ensure the integrity and confidentiality of client data has been maintained.”

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.

“I do not see how any CSP in a multi-tenant cloud could or would meet this guidance. The whole idea is that any logging would contain information for all tenants, and I doubt many would allow either a client or their QSA access to the logs,” said StorefrontBacktalk PCI Columnist and QSA extraordinaire Walter Conway. “Providing logs may not be a big deal in a private cloud, but it ain’t gonna happen in a generic, multi-tenant cloud. That’s one of the reasons (there are many others) the only way to be PCI compliant in the cloud is with a private/virtual private cloud.”

Asked about a comment from someone on the PCI Cloud SIG that this guideline might make some retailers “no longer compliant,” Conway said: “If they are in a multi-tenant cloud, what in the world ever made them think they were compliant in the first place?”

Chris Brenton, who is a member of the PCI Cloud SIG involved in writing these guidelines and the director of security for CloudPassage, described the introspection recommendation as being especially significant. “That one is probably the most disruptive,” Brenton said. In some environments, he said, “some merchants may actually lose [PCI] compliance. If they are using introspection and they can’t produce a full audit, then a decent QSA is going at it and say, ‘No, this doesn’t fly.'”

Brenton said that, to his knowledge, no CSPs today offer the newly requested level of audit information to retail tenants.


One Comment | Read PCI’s New Cloud Guidance: Great Ideas, Short On Realism

  1. Richard Rees Says:

    Having an ill-behaved or malicious neighbor is actually far less of a risk than believed. MIT did an excellent research paper on this very topic, and found it was HARDER in a public cloud environment than in a private environment. One corollary – the FEWER neighbors you have the LESS protected you are, not the reverse. If you have 50 tenants on the same host, finding a specific tenant’s information is going to be far more difficult than if there are 3 tenants on the same host.


StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.