PCI DSS 2.0 addresses use of server virtualization

New data security standard clarifies language dealing with virtualization technologies, but leaves many questions about compliance unanswered

The Payment Card Industry (PCI) has released version 2.0 of the Data Security Standard (DSS), an update to its 1.2.1 version that probably would have been better labeled as a 1.3 release for its lack of any new major requirements.

Instead, PCI DSS 2.0 focuses on clarity of language for a number of key areas, including virtualization. With that, I'd like to welcome the group to 2010 and thank them for finally acknowledging the use of virtualization technologies. It's only been around for 10 years.

[ Also on InfoWorld: VMware vSphere 4.0 achieves an EAL4+ rating from Common Criteria -- the highest-level security certification. | Keep up to date on virtualization with InfoWorld's Virtualization channel. ]

It took some time, but the addition of the virtualization concept into the standard reflects the importance of this technology and its operational impact within the PCI community, but there are still related security challenges that need to be addressed. Adding virtualization into the standard is movement in the right direction, but without any real guidance on how to ensure virtualization compliance, how effective can it be? That remains to be seen.

The PCI DSS 1.2.1 specification has a requirement that only one primary function per server be implemented, which has led to confusion for those using virtual machines in their environments. It wasn't clear in looking at the 1.2 specification if it permitted two or more virtual machines to run on the same physical server (one of the main reasons behind using virtualization). The 2.0 specification at least seems to clarify that issue by allowing multiple VMs on the same physical hardware -- that is, as long as each VM is only performing one primary task.

Specifically, requirement 2.2.1 states the following:

Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)

Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.

This clarification was missing from the earlier version of the standard. Virtualization is specifically called out, so there should be no more confusion when trying to interpret the word "server." However, it does so with limitations. PCI DSS 2.0 goes into further detail with two subsections of requirement 2.2.1:

2.2.1.a For a sample of system components, verify that only one primary function is implemented per server.

2.2.1.b If virtualization technologies are used, verify that only one primary function is implemented per virtual system component or device.

Again, these subsections approve the use of virtualization technology but limits that use to allowing a virtual machine to only have one primary function. This is similar to the old "one app, one server" methodology used on a physical server. In other words, don't put a DNS server and a database server on the same VM -- one app, one VM.

These are the virtualization changes made with version 2.0 of the PCI DSS requirements, but the group also came out with a second document, Navigating PCI DSS, which helps clarify the intent of the requirements. Within this document, virtualization is the only topic to receive its own special section in the preface. It specifically calls out the following further limitations to virtualization:

If virtualization is implemented, all components within the virtual environment will need to be identified and considered in scope for the review, including the individual virtual hosts or devices, guest machines, applications, management interfaces, central management consoles, hypervisors, etc. All intra-host communications and data flows must be identified and documented, as well as those between the virtual component and other system components.

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. For example, there must be a clear segmentation of functions and segregation of networks with different security levels; segmentation should prevent the sharing of production and test/development environments; the virtual configuration must be secured such that vulnerabilities in one function cannot impact the security of other functions; and attached devices, such as USB/serial devices, should not be accessible by all virtual instances.

Additionally, all virtual management interface protocols should be included in system documentation, and roles and permissions should be defined for managing virtual networks and virtual system components. Virtualization platforms must have the ability to enforce separation of duties and least privilege, to separate virtual network management from virtual server management.

Special care is also needed when implementing authentication controls to ensure that users authenticate to the proper virtual system components, and distinguish between the guest VMs (virtual machines) and the hypervisor.

The PCI DSS navigation document does attempt to further clarify the 2.0 requirements around virtualization (read: more limitations and restrictions), but it still leaves a lot of unknowns. What about the architecture of this environment? We have a good idea of what we can't do, but not much beyond that. And while virtualization has been specifically called out in the 2.0 specification, it doesn't seem to leave a lot of wiggle room for a public cloud offering.

Virtualization is the key enabling technology for a public cloud, but the 2.0 guidance is still written as though multitenancy doesn't exist. What happens when people want to use a service like Amazon's to deliver a service that is in scope for PCI?

To support organizations facing these requirements and to address the unique challenges of virtualization and cloud environments, industry leaders such as Cisco, VMware, HyTrust, Coalfire and Savvis -- all core members of the PCI DSS Virtualization Special Interest Group (vSIG) -– have spent months of collaboration, developing a white paper that outlines the configuration guidelines and "best practices" reference architecture, which was implemented and tested in a Savvis advanced-technology lab.

"The latest release of the PCI DSS recognizes that organizations have implemented virtual infrastructures in their cardholder data environments. As the industry increases the adoption of virtualization, the next logical step is to move to a private cloud environment," stated Tom McAndrew, vice president of professional services at Coalfire, one of the leading Qualified Security Assessor (QSA) organizations.

"The PCI DSS represents a minimum baseline of security controls which are being adopted not only in payment environments, but also in other industry verticals such as healthcare, banking, local, state and Federal government. This paper addresses some of the common challenges these organizations face, and how leading providers such as HyTrust, VMware, Savvis, and Cisco have developed solutions to tackle these challenges head-on," McAndrew continued.

While this reference architecture should prove helpful in that endeavor, it is important to also keep in mind that this architecture is based on the vendors' interpretations and is not the guidance of the official PCI standards council.

PCI DSS 2.0 takes effect on Jan. 1, 2011, and represents the first significant update to the standard in over a year. Annual audits that occur after that date will be subject to the new standards. With the wording in the requirements being somewhat vague, and the fact that interpretations can vary from one auditor to the next, you might want to start your planning now to make sure your environment fits within these new guidelines.

This article, "PCI DSS 2.0 addresses use of server virtualization," was originally published at InfoWorld.com. Follow the latest developments in virtualization and cloud computing at InfoWorld.com.

Copyright © 2010 IDG Communications, Inc.

How to choose a low-code development platform