The PCI Security Standards Council released version 2.0 of its data security standard. Rick Vanover shares his thoughts about what this means for virtualization environments.
The PCI Security Standards Council released version 2.0 of its data security standard (PCI 2.0) in October 2010. So what does this mean for virtualization environments? I checked to see what my colleagues in the virtualization community had to say about it, and I found this excellent post by Edward Haletky.
As Edward states, PCI 2.0 addresses virtualization but not in a concrete way; that is to be expected, as compliance standards rarely give very specific configuration requirements. The technology simply moves too fast for this to be effective. Virtualization, cloud, and other technologies are not necessarily new in terms of a compliance perspective -- they just require a different interpretation. In a previous post where I interviewed Dorian Cougias from Unified Compliance Framework, the same issues that apply to cloud technologies resonate here with virtualization and PCI 2.0.
Specifically for PCI 2.0, the critical language that I zeroed in (again echoing Edward's interpretation) is this line on page 5 of the PCI 2.0 standard:
The implementation of a virtualized environment must meet the intent of all requirements, such that the virtualized systems can effectively be regarded as separate hardware.
The intent of all PCI requirements applied to virtualization is the key interpretation. This is an area where the level of separation of virtualization components determines how this will be interpreted. There are a number of questions about what level of separation needs to be in place. For example, it is generally accepted that VLAN trunks are a good separation mechanism; they are not inherently a protection mechanism, but do represent a level of separation and in the case of virtualization. This is loosely equivalent to the technology that the switching equipment would use. Operating system separation in terms of guest virtual machines is a good separation layer. Likewise for development and production systems or in-scope of PCI or out-of-scope of PCI systems are good separation layers. In most cases, these separation levels and other configuration guidelines are part of the intent of PCI 2.0.
The storage layer is where things get questionable. Does a separate storage system and storage network need to be provisioned for in-scope systems? This goes back to interpretation, and controls such as multi-tenancy solutions may not be as much of a cure-all as they appear.
Note: This blog post is not direct PCI guidance. You should seek guidance about compliance issues from an authorized party.
How have you started to address PCI 2.0 in regards to a virtualized infrastructure? Let us know in the discussion.