Oooh, ahhh, that’s how it always starts. Then later there’s running and screaming.

Today I want to get back to the matter at hand, how to deal with PCI if you have a virtual environment. Because PCI DSS is one of the first glimpses Canadian organizations have into the need to secure their virtual environments, the learning curve for both auditors and IT teams is staggering. There is a lot of grey space at the moment where interpretation of the requirements can have a significant impact on the end result, and often it is a result of auditors walking into mixed environments where virtual and physical resources co-exist and they realize they are in over their heads. In fact, something that seems initially simple, such as the separation of trust zones, can actually be quite complex to not only understand, but to figure out how to comply with. But where to start?

Before you bring a QSA into your environment, it’s very important that if you plan on auditing your virtual environment you ensure that the QSA is fully versed in how to audit your infrastructure. Virtualization is a newer technology for a lot of auditors, so if they don’t know what to specifically look for, or they don’t understand what they need to evaluate, it will probably end badly with lots of money spent and missed requirements. Auditors are there to help your organization meet the requirements of compliance to better your security posture, so if they can’t help you, it really defeats the purpose of the whole thing.

The problem facing auditors as it relates to virtual environments is that they are walking into a mixed-mode infrastructure where you have both physical servers and traditional security controls, and virtualized servers which may not even be on the same site. Oh, and what about mixed hosts such as environments running Vmware vSphere, Microsoft HyperV, Citrix XenServer and maybe even RedHat KVM and all the networking, resources and storage attached to them. On top of these platforms you have virtual machines that operate without any regard for the processes going on between the hypervisor and Vms. But at the end of the day, they all still connect to some kind of physical hardware which means you are dealing with physical and virtual in the same breath and puts a spin on how to audit these properly based on where each process and resource maps against the compliance standard.

But its not just separating virtual and physical that makes it tricky, it’s that each network connection to the virtual machines can perform different functions such as management, VM usage and vMotion, and must be segregated properly into trust zones. All these 3 connections are available to a single VM based on how it is purposed, but if we go back to the PCI requirement, it states that you need to separate functionality and trust zones across multiple servers to reduce risk of breach of trust. If you argue that those are background processes in most cases, or that you would limit vMotion to certain VMs only, then what about when we add security to the mix?

Virtual security tools are designed to plug into the hypervisor layer and protect all VMs which reside on the hypervisor regardless of trust zone. This is so that it can see all traffic and protect the hypervisor across all VMs. Well, what if the security control is used to gain unauthorized access to all VMs across the hypervisor? For example, if I use a low trust-level VM to gain access to the hypervisor and create a virtual NIC. I can then use this virtual NIC to connect to any other VM on the same hypervisor regardless of trust zone because the security processes are offloaded. So data that resides in a VM that would fall under PCI compliance requirements share the same hypervisor with security tools (in their own VM) which have a different trust level, immediately breaching compliance as required by PCI. The best way to think about this is to imagine an IPS or SIEM device…they don’t contain PCI data themselves, but they process it through indirect means because they deal with the entire IT environment.

While I expect that right now it’s not common practice to breach virtual machines through this manner, it is important to note because if you are audited against PCI, and you use management tools, you need to ensure that your auditor understands how all these factors apply to compliance. PCI is going to be one of the first key drivers to adopt security for virtual environments in Canada, so it is imperative that auditors and security teams understand exactly what the goals of these requirements are and how to properly enforce them.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s