This is page 2 of:

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

February 11th, 2013

That said, Brenton added, there’s no reason CSPs couldn’t release this data, with a little extra effort.

“Some API calls may be hypervisor specific or impact all VMs running on it. Log entries of this sort may need some sanitation prior to release to clients. However, many API calls will be things like ‘search storage on this specific VM looking for this specific pattern,'” Brenton said. “This is the type of info that the client absolutely must have to ensure that pattern is something good—such as searching for a known malware signature as part of an AV solution—or something bad—like pattern-matching for credit-card info. I think the litmus test is going to be ‘Can the client get that info through some other means?’ For example, an IaaS (infrastructure as a service) CSP probably would not have to hand over firewall logs, because the client is free to run a host-based firewall and log all activity. What’s different about introspection is that it leaves no forensic trail on the server itself, so the CSP is now the only source of that information.”

And it’s precisely that lack of a forensic trail that makes introspection so attractive to cyberthieves. No need to clean up the fingerprints after the crime: This crime-scene comes pre-police-proof.

Brenton directly disagreed with Conway on the big-picture argument that shared clouds are simply not acceptable for PCI compliance, especially for the largest chains. “That’s an incorrect statement and specifically why we created the guidance. Compliance in public space is possible, provided the proper controls are in play. For example, this introspection issue we are discussing. Two ways to get around it are to generate all the log info specified in the guidance” and “do not deploy introspection and implement compensating controls through other means.”

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.”

There are ways, the retail security exec added, to limit that risk. “If introspection is allowed, it would have to be limited to tools that are PCI compliant (recording only “4123********2345″ instead of the whole number, for example.) Another option is that a compliant environment operator could run the tools and just notify you when you’re failing.”

She added that there are other ways this can be made to work in a shared cloud, assuming all players are willing to compromise a little and trust a lot. “What I can see happening is the hosting providers being able to offer DLP services via introspection, while forbidding their clients access to the APIs or from running them directly. It seems logical that a PCI DSS certified provider could be trusted to do that,” she said. “You could call it security as a service, if you really wanted to annoy people.”

The only problem: Compromise and trust are two things in impressively short supply with the PCI Council, QSAs and retail security people.

The rules about shared clouds skirt the core issue, which is that the very nature of a shared cloud raises the distinct possibility of secure access by hostile cloud neighbors. CSPs are not known for doing rigorous checks on who they sell cloud space to nor on initiating aggressive monitoring of what they’re doing.

To be fair, CSPs are generally fine at being reactive, meaning they’ll monitor and quickly shut down neighbors shown to be acting poorly. That’s after the fact, though. How would your cloud security protocols look if you made the assumption that at least one of your cloud neighbors was a professional cyberthief? How much data would you want them to be able to demand about your shared cloud? What if they are solely there for the purpose of breaking into your systems?

And what if it isn’t a traditional cyberthief looking to steal payment-card data or manipulate your payroll system or even an identify thief looking to pretend to be one of your customers? What if it’s a chain just like yours, but one that has decided to use the security of the cloud to do some cyber-snooping and competitive intelligence? The attack methods may be similar, but the profile of the attacker—the seemingly innocuous little old lady from Pasadena who moved in next door—may look comforting. In other words, even self-selected neighbors can be trouble.

The council’s cloud guidance does appear to be generally well thought-out. But it seems to focus on too much of a theoretical nirvana reality instead of the one where we all have to work.


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.