The PCI Security Standards Council released a Cloud Guidance (PDF) paper yesterday. Network World calls this Security standards council cuts through PCI cloud confusion. In some ways that’s true, but in several important areas it does the opposite. Here are a couple examples:
SecaaS solutions not directly involved in storing, processing, or transmitting CHD may still be an integral part of the security of the CDE …the SecaaS functionality will need to be reviewed to verify that it is meeting the applicable requirements.
… and …
Segmentation on a cloud-computing infrastructure must provide an equivalent level of isolation as that achievable through physical network separation. Mechanisms to ensure appropriate isolation may be required at the network, operating system, and application layers;
Which are both problematic because public cloud and SecaaS vendors won’t provide that level of access, and because the construction of the infrastructure cannot be audited in the same way in-house virtualization and private clouds can be. More to the point, under Logging and Audit Trails:
CSPs should be able to segregate log data applicable for each client and provide it to each respective client for analysis without exposing log data from other clients. Additionally, the ability to maintain an accurate and complete audit trail may require logs from all levels of the infrastructure, requiring involvement from both the CSP and the client.
And from the Hypervisor Access and Introspection section:
introspection can provide the CSP with a level of real-time auditing of VM activity that may otherwise be unattainable. This can help the CSP to monitor for and detect suspicious activity within and between VMs. Additionally, introspection may facilitate cloud-efficient implementations of traditional security controls–for example, hypervisor-managed security functions such as malware protection, access controls, firewalling and intrusion detection between VMs.
Good theory, but unfortunately with little basis in reality. Cloud providers, especially SaaS providers, don’t provide any such thing. They often can’t – log files in multi-tenant clouds aren’t normally segregated between client environments. Providing the log files to a client would leak information on other tenants. In many cases the cloud providers don’t provide customers any details about the underlying hypervisor – much less access. And there is no freakin’ way they would ever let an external auditor monitor hypervisor traffic through introspection.
Have you ever tried negotiating with a vending machine? It’s like that. Put in your dollar, get a soda. You can talk to the vending machine all you want – ask for a ham sandwich if you like, but you will just be disappointed. It’s not going to talk back. It’s not going to negotiate. It’s self service to the mass market. In the vast majority of cases you simply cannot get this level of access from a public cloud provider. You can’t even negotiate for it.
My guess is that the document was drafted by a committee, and some of the members of that committee don’t actually have any exposure to cloud computing it does not offer real-world advice. It appears to be guidance for private cloud or fully virtualized om-premise computing. Granted, this is not unique to the PCI Council – early versions of the Cloud Security Alliance recommendations had similar flaws as well. But this is a serious problem because the people who most need PCI guidance are least capable of distinguishing great ideas from total BS.
And lest you think I regard the document as all bad, it’s not. The section on Data Encryption and Cryptographic Key Management is dead on-target. The issue will be ensuring that you have full control over both the encryption keys and the key management facility. And the guidance does a good job of advising people on getting clear and specific documentation on how data is handled, SLAs, and Incident Response. This is a really good guide for private cloud and on-premise virtualization. But I’m skeptical that you could ever use this guidance for public cloud infrastructure. If you must, look for providers who have certified themselves as PCI compliant – they take some of the burden off you.
Reader interactions
4 Replies to “PCI Guidance on Cloud Computing”
Hi Adrian, Chris,
Great comments and discussion.
I want to toss in two cents worth on what I liked about the Cloud SIG’s guidance, but from the very limited perspective of a QSA. You captured it at the end of your post, Adrian: “This is a really good guide for private cloud and on-premise virtualization. But I’m skeptical that you could ever use this guidance for public cloud infrastructure. If you must, look for providers who have certified themselves as PCI compliant – they take some of the burden off you.”
From one QSA’s perspective, you got it. That seems to be the intent of the SIG, and I think they did a pretty good job of clarifying things and providing a merchant-centric focus.
There also were some real pearls in the report (and maybe even a hidden, secret message or two), for example:
— Get hold of the Executive Summary of the CSP’s ROC. Yes, part of it is proprietary, so a redacted copy of the relevant parts is fine. As far as I can tell, this is the first time any PCI SSC guidance has gone beyond telling merchants to ask for the AOC, which in this case is next to useless. Was I the only one to see this? I wish the statement had been on page 1.
— A CSP’s PCI compliance does not transfer directly to the client. Strike one blow for (a necessary) repeating of the obvious to counter the sales spiel. Once again, the SIG has reinforced the notion that while you can catch the flu, you can’t catch PCI compliance. What a shame it is still necessary.
— Monitoring the CSP’s compliance and security is ongoing. You don’t get to set it once and forget it.
— The Appendices, especially Appendix C, is worth the price of reading the first 50+ pages. Merchants are told not just to assign responsibility for each PCI requirement, but actually to document how the client and CSP will actually meet their responsibilities. This is good stuff.
You are right that the SIG focused on private cloud solutions, but that is because these will be the easiest to make PCI compliant (and secure). Using my PCI/QSA lens to read the document, that perspective/advice is pretty much what I expected to hear. That the SIG spent time exploring best practices for other cloud delivery models is a bonus.
Walt Conway
Hey Adrian,
Part of the problem with any standard is that it needs to be able to apply to a wide range of environments and situations. For example, it would have been much easier to say “Only do business with PCI certified CSPs and these are the PCI control points they _must_ be able to provide an attestation for”. Of course the problem with “one size fits all” is one size never fits all. 😉
So instead the guidance recommends that you work with a PCI certified provider. If you do, the points under their control are a done deal and you only have to worry about your area of control. If however you choose to work with a CSP that is not PCI certified, well, that’s when you get into having to do through all the PCI control points including the ones that cover the CSPs infrastructure and facilities. So it is not impossible to achieve compliance with a non-certified provider, but it is painful and your QSA effectively ends up certifying them on your dime. 😉
I completely agree with your concerns regarding introspection. I have some info I posted here:
http://www.sans.org/cloud/2012/07/12/introspection-problems-in-public-cloud
and here:
https://cloudsecurityalliance.org/education/white-papers-and-educational-material/courseware/
if you are interested. This is why that section of the guidance is so specific about the provider needing to be able to produce audit logs for introspection API calls. Since introspection leaves no forensic trail on the VM itself, it’s the only way to ensure you have any kind of visibility into this potential attack vector.
No worries on the final comment. All’s good mate! Thanks for keeping us honest. 🙂
Chris
@Chris – all good points.
I would have come out and said “But then again not every environment can achieve attestation” right up front. It’s ‘between the lines’ in every section but I think that needs to be stated as merchants will waste a lot of time walking down that path only to find they’ve reached a dead-end.
I do have a tough time with the section on introspection regardless of it being IaaS, PaaS or SaaS. Shenanigans going on at the hypervisor layer are indicative of a very major breach, or of a very skilled rogue employee, and seem outside the capability of all but a select group of specialists. Better to advise service providers to include something in their SLA or common criteria cert. External audits for this seems folly.
I’ll retract my comment on cloud experience. That, in hindsight, is unfair.
Thanks again for the comment,
Adrian
Hi Adrian,
I participated in the PCI SIG that generated these guidelines, so hopefully I can help clarify some points for you.
Comments on SecaaS and segmentation – Skip down to section 5 and many of the points you raised are noted here as well. Last sentence in this section states “The recommended practice for clients with PCI DSS considerations is to work with CSPs whose services have been independently validated as being PCI DSS compliant.” So while the client may not have visibility into the provider’s network, if the provider has met the required level of PCI compliance, and has an attestation saying as much from an independent QSA, you should be all set. You don’t actually need insight into the CSPs operations.
Your comment “Good theory, but little basis in reality. Cloud providers, especially SaaS providers, don’t provide any such thing.” Introspection is more a IaaS issue since it bridges the line between CSP and client responsibility zones. Not really an issue in PaaS or SaaS, as the CSP has responsibilities far higher up the stack.
Your comment “They often can’t – log files in multi-tenant clouds don’t (typically) segregate data between client environments.”. Yes and no. I’ll agree that if a SaaS provider is using a backend database, OS and even database functions are not client specific, and as such would not be shared. However these entries will also be covered under the CSPs attestation. Log entries related to the access of each client’s stored information however (successful authentication, failed authentication, data changes, etc.) should be available for each client to review as required. Does every SaaS provider do this? Probably not. But then again not every environment can achieve attestation. 😉
Your comment “My guess is that the document was drafted by committee, and some of the members of that committee don’t actually have any exposure to cloud computing.”. I myself work for a cloud security company (CloudPassage) and teach cloud security for SANS. Another one of the most active members was Phil Cox, who runs security at Rightscale and has written some awesome papers on achieving compliance in public cloud. There were quite a few other group members with decent street cred as well. If you feel that certain insight is missing from the document, I would encourage you to get involved and participate the next time around.
Thanks,
Chris