This tip is a part of the SearchCloudSecurity.com learning guide, PCI and cloud computing: Cloud computing compliance guide.
The recent guidance on virtualization issued by the PCI Security Standards Council comes as a bit of a mixed blessing for many organizations. On the one hand, most of the industry has been waiting with baited breath for PCI virtualization guidance since the Data Security Standard was first published. Questions like, “What does ‘one function per server’ mean for virtual environments?” have stymied end users and auditors alike, with little to go on in the form of official guidance. So on the positive side, the guidance answers many of those questions and adds much-needed detail to what was always a murky topic.
This clarity comes at a cost though. The downside of the PCI virtualization guidance is it’s likely that some of the decisions and assumptions organizations have made in the past about these topics will turn out to be wrong. Some organizations, for example, may have made the assumption that a “guest VM” slice could be in scope without the hypervisor also being in scope, which we now know is incorrect. Organizations that were mistaken in this way will likely require additional spending or effort to get into compliance.
Cloud is one area where these issues are particularly pronounced. While the guidance has made it clear that compliance in the cloud is feasible (not something universally accepted previously), the council has also made it clear that PCI in the cloud is no pushover from a technical standpoint. Getting to compliance in the cloud involves the active participation of both the organization itself, as well as the cloud provider, and unfortunately, not every provider is willing to play ball.
PCI compliance in the cloud: A shared responsibility
One of the issues the PCI virtualization guidance clarifies is that PCI compliance in the cloud is a shared effort between customer and provider. According to the guidance:
“Additionally, as with any managed service, it is crucial that the hosted entity and provider clearly define and document the responsibilities assigned to each party for maintaining PCI DSS requirements and any other controls that could impact the security of cardholder data.”
This means that while organizations ultimately shoulder the burden for compliance, the cloud provider’s implementation is a key part of overall compliance. Both the provider and the hosted organization need to take action. Hosted entities need to document their processes and controls and make sure all of the controls are thoroughly addressed, either by themselves or the provider. Providers, on the other hand, may need to provide documentation (for example in the form of an explanation on how they meet controls), initiate auditing efforts to provide evidence of implementation, or modify their environment to make sure they meet controls.
This is where cloud providers feel the pinch most. Because the PCI virtualization guidance does categorically link together scope for the hypervisor and the guest image, whole environments may need to be changed en masse if the goal is to get them PCI compliant. Specifically, if you have a hypervisor supporting multiple tenants, and one or more of those guest OSes are in scope for PCI, so is the hypervisor.. Because the hypervisor is in scope, anything not segregated from it is in scope as well. In many situations, this can mean the entire environment.
Some cloud providers, like those that specifically target the merchant community, are already planning how to assist customers in this regard. But it bears saying that this is by far not a guarantee: Not every provider will have this on their roadmap, and not every provider that does will do so for every environment. Some environments may be built around sets of security controls that -- let’s face it -- are just flat-out inappropriate for use in the cardholder data environment (CDE).
Options if the cloud provider won’t support PCI compliance
So the question arises about how firms should react in the event that their cloud provider can’t (or won’t) support PCI compliance, either because the provider’s controls are unacceptable and the provider is unwilling to change them, or because the audit/documentation effort is something the provider is unwilling to undertake. In other words, what do firms do if they find out their cloud environments can’t achieve compliance?
Obviously, the ideal situation is to find and use an environment certified to PCI, for example, one that has gone through an audit process and had controls validated to meet the standard. Ideally, your cloud provider already supports this or can rapidly accomplish it within an acceptable timeframe; but if not, it may be time to evaluate the marketplace to find one that is willing/able to support you. In fact, even the threat of taking your business elsewhere can provide pressure for a vendor to certify; one large customer might cause them to rethink their position on this point, as might a “critical mass” of smaller customers.. Of course, security controls and audits aren’t free, particularly those required by PCI. An environment that has appropriate controls and that has been through the audit process is likely to cost more than one that has not. If you need to make a change and you haven’t budgeted for it, the hit here can be painful.
Another option is to catalogue the controls required by the PCI DSS in light of the virtualization guidance and compare that list with your environment. For any control that is both missing and the responsibility of your cloud provider, assess if you can meet the control without your vendor’s participation. DIY is not going to be possible with certain kinds of controls that are highly dependent on location (for example, physical security controls), but there could be some flexibility with respect to controls that have wide latitude for different implementations. For example, if your vendor doesn’t provide adequate logging at the platform level, you might choose to implement it yourself at the application level to meet the requirement without needing to rely on the provider.
If you change providers or implement controls yourself but still require vendor participation to close gaps, you have a few options such as removing cardholder data from the environment through technologies like tokenization or encryption. Tokenization limits scope by replacing the PAN with an inert value while encryption (provided your cloud provider does not have access to the keys) can limit scope as well, per guidance issued by the council.
Of course, any option takes time to implement. So consider in the short term what compensating controls you might be able to implement if your audit validation cycle is currently in progress. As you carve out your strategy for moving forward, implement those short-term compensating controls and have them at the ready. And remember: It’s much easier if you start this planning on your own rather than waiting for the issue to get flagged in your audit cycle; planning ahead and recognizing where you may have issues is time well spent.
About the author:
Ed Moyle is a senior security strategist with Savvis as well as a founding partner of Security Curve.