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

Tools

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