On the latest Virtualization and Cloud Security Podcast (11/09/2017), senior technical marketing architect for vSphere Security Mike Foley and I discussed security and compliance, and segregated or independent clusters for each. This has been one of my personal hot topics for a while. The issue is that many folks think, rightly or wrongly, that a separate virtualization cluster is required for separate duties like PCI or DMZ. So, Mike and I discussed the matter, with a quick lightning round at the end about the need. Have a listen to learn the results.
Many folks believe that if something is in a DMZ, all things related to the DMZ must be segregated from all other aspects of their environment. When it comes to virtualization, this often includes the hypervisor and what it connects to. There are several issues with this thought process:
- This does not account for the non-DMZ networks that exist within a hypervisor, such as management, migration, and storage
- This can waste quite a bit of resources
- This implies a lack of trust in hypervisors and their security
The first question you need to ask is “Do you trust cloud providers?” Why? Because they also do not set up separate clusters of resources based on security or compliance roles. You get a set of virtual machines, and that’s it. Where they run is really unimportant, and that is the crux of the argument. With proper segmentation, where they run makes no difference. But how do you achieve proper segmentation?
The easiest way is to create an arbitrary boundary, a boundary that is enforced in some fashion. A virtual private cloud (VPC) is one such boundary, defined more by the virtual network than by anything else. Now, if a DMZ is required, we would set up a VPC for the DMZ, etc. To achieve that, there are many tools that could be involved, but all are security tools providing defense in depth.
The next question to ask is “Do you trust your defense in depth?” If you do, and you have the proper network controls, then network segmentation can be achieved. However, it seems that many IT professionals don’t trust their defense in depth. Is this really a lack of trust, or a lack of knowledge and understanding that causes a lack of trust? Is there adequate defense in depth between workloads and management, workloads and storage, and workloads and migration? How can those be broken? What layers do you need?
I do trust my defense in depth, but also I verify. I monitor, and there are many things that must be verified. To what depth is this required? In many cases, this depends on the segmentation approach taken with security. There are three major forms of microsegmentation approaches for networking and storage:
- Hypervisor I/O filters or drivers
- Virtual security appliances
- In-guest drivers
All three of these mechanisms have their issues. Mike and I both have questions about whether or not hypervisor security is required to be in scope for security audits when I/O filters are employed. As for the other two, we are on the same page: the hypervisor is just not involved. Yet, what is in scope is often defined by the compliance guidelines. I take umbrage at the PCI DSS guideline that categorically states that the hypervisor is in scope regardless of the segmentation approach taken. Once you bring the hypervisor in scope, you bring in scope the entire cluster of hypervisors, the management and automation layers, and any tools used for monitoring and external security. Basically, your entire data center becomes in scope. This is something we tried to avoid.
What this means in the cloud is that your PCI DSS certification is dependent upon the cloud’s certification, and that boils down to trust.
How much do you trust your security—your defense in depth? If you trust it, there is no need for independent clusters.