On Tuesday, June 14, 2011, the PCI SSC released an Information Supplement regarding Virtualization Guidelines. Not only does this Information Supplement cover virtualization from a VMware and Hyper-V perspective, but also goes into cloud computing.
The supplement is broken into six sections:
- Introduction
- Virtualization Overview
- Risks for Virtualized Environments
- Recommendations
- Conclusion
- Virtualization Considerations for PCI DSS
The Introduction and Overview sections are good foundations. But if you have a good knowledge of the concepts of virtualization, I would not waste time reading these sections. The Risks section is a very good discussion of the risks presented by virtualization. However a lot of readers of this supplement are likely going to be disappointed as there is little new material covered in this section that has not been discussed before in other information sources or even my blog entries. In my opinion, the Recommendations section presents what would be expected.
The real gem in this supplement is the Appendix that provides the Virtualization Considerations for PCI DSS. This supplement takes the relevant PCI DSS requirements and provides a lot of guidance regarding what QSAs should consider when assessing virtual environments. In a number of these, there are also some additional best practices and recommendations made by the writers of the supplement. In reading these best practices and recommendations, one would think these would be common sense, but I guess you just cannot assume that any more.
Page 23 has the other great gem in a diagram that graphically represents the responsibilities of cloud customers and cloud providers regarding who is responsible for data, software, user applications, operating systems, databases, virtual infrastructure, physical infrastructure and the data center where everything resides across the three types of cloud services; IaaS, PaaS and SaaS. If you are explaining cloud computing to non-technical people, this is probably one of the best diagrams I have seen to explain responsibilities.
If I had to take the PCI SSC to task on anything, I would argue that cloud computing does not necessarily have anything to do with virtualization. Yes, a lot of cloud computing solution providers are using virtualized systems to provide their services, but not every cloud provider uses virtualization. And even if the cloud provider does use virtualization, why is that the customer’s concern? In my opinion, cloud computing should be an entirely separate document.
I have included below links to all of my prior posts on virtualization for reference.
PCI Guru 
Still seems onerous and murky when you start talking about hosting CDE virtual machines on the same host as other non-CDE scoped machines. YOu start talking VM-to-VM communication plus all the shared stuff and it really gets crazy. Can’t say I’m happy about that, but that’s actually not so much a security problem as it is a problem for people coming up with these complex new technologies…
The problem is the same as when you have cardholder data environment (CDE) and non-CDE systems in the same DMZ. If any of the non-CDE systems are compromised, it may result in the compromise of the any of the CDE systems. The same is true with CDE and non-CDE VMs that run on the same hypervisor or cluster. If you compromise a non-CDE VM, a CDE VM may also be able to be compromised as a result. So the rule of thumb is to isolate sensitive VMs in their own hypervisor away from non-sensitive VMs.
Yeah, but that’s still pretty heavy. For instance, my environment runs about 100 web applications, many of which share a common database backend. In order to be PCI compliant, we had to either validate every single web application (and thus server) in our DMZ, or isolate our CDE stuff to separate networks. That’s great and all, but my CDE environment ends up consisting of a physical database server plus 4 extremely low-use web servers all running the same extremely small web app to broker tokens. To stand up a dedicated host for them doesn’t make anyone happy.
(Personally, I’d prefer it all up to snuff with PCI levels, but that’s neither here nor there!)
Don’t blame or be upset with the PCI SSC, card brands, QSAs, etc. Blame the people that seem to have nothing better to do than to mess with your computers. They are the ones causing the problem. And don’t buy into their excuse of “I do it to show people how to be more secure.” That is just pure BS. The people mounting these attacks are breaking the law and are criminals whether they belong to an “official” criminal organization or not.
However, that is not an excuse for an organization to be lax on security and not take it into consideration. For too long, IT professionals have relied on “security by obscurity” to protect their networks, computers and applications. With essentially everything regarding networks, computers and applications published on the Internet, obscurity no longer exists.
Oh, and I’d also say I’d be back to a single point of failure with a single big CDE host, which means I’d need two, or question why I’d make things highly-available anyway. Fun. 🙂
A colleague also asked me if that would mean PCI wants to go even further and talk about shared storage for various hosts.
As a side note, how many QSAs understand all this stuff enough to be useful? 😉
PCI compliance does not preclude hot failover and similar recovery strategies. However, it can complicate them.
At the moment, SAN storage shared between the CDE and non-CDE are only at risk depending on the connectivity used. Traditional connectivity through fibre channel is very secure but the connection of the SAN through the various Ethernet solutions can be problematic from a security perspective depending on how these Ethernet solutions are implemented.
Most QSAs have technical staff that actually evaluate the more sophisticated technologies. While I have been a CCNA, CNE, MSCE, etc. I am no longer current on these technologies, so I rely on others for their evaluation. A good QSA should have a team of technical and operational personnel behind them to handle all of the varieties of configurations that one can encounter.
When the Council releases new guidance like this, what is the obligation of a QSA working on an assessment or someone still completing an SAQ? The guidance specifically says “The intent of this document is to provide supplemental information. Information provided here does not replace or supersede requirements in the PCI Data Security Standard.”
So what’s the point? They Council can write whatever they want about cloud computing or anything else in these things but it doesn’t change anything in the DSS.
The information supplements are meant to provide QSAs, ISAs, merchants, service providers, etc. with additional information that should be considered during an assessment. The information does not supersede what is in the PCI DSS, PA-DSS, SAQs, etc. But the information is meant to clarify and further define the information provided in those documents. In the past, this information was provided in the QSA Certification and Re-Certification training and to no one else and not always covered consistently. As a result, the PCI SSC decided to issue them as information supplements. Without these information supplements, we would be on our own to interpret the standards as we see fit. In order to keep everyone as consistent as possible, the PCI SSC issues the information supplements so that we all interpret the standards as we can.