PCI DSS version 1.3 or 2.0: The next version will matter to you (NCSAM)

The Payment Card Industry’s (PCI) Data Security Standard  (DSS) has long served as the cookbook by which anyone dealing in the storing, transmittal or processing of credit card payment information retains the certified right to do so (i.e. continue to accept credit cards as payment).

Arguably this is the lifeblood of most businesses regardless of size, so the standard is not only one of the best known world-wide but has also spawned an industry need of Qualified Security Assessors (QSAs), Approved Scanning Vendors (ASVs) and certifications like the Internal Security Assessor (ISA) program to ensure that adherence to the standard’s guidelines is somewhat uniform, (emphasis on the somewhat, more on that later) regularly monitored and frequently updated.

This ensures that as businesses change their network and data center infrastructures, the methods by which they protect cardholder information at rest and in transit remain largely compliant to the spirit of the standard.

Conceived nearly six years ago as a collaboration by Visa, Mastercard, and Discover to merge their individual guidelines, it has become an eloquent set of instructions composed of what are known as the “12 Requirements” and although they are not prescriptive of technology vendors they are detailed (there are over 220 sub requirements) and specifically mandate the use of firewalling and encryption, arguably action verbs as much as technologies, to achieve the overarching goal of continuous protection for cardholders.

PCI’s History

Version 1.0 was updated to 1.1 in 2006 and 1.2 in 2008, which is where it has remained until now. A revision to version 1.3 is anxiously anticipated in the next month or so. Rumor has it that it may even surface as a v2.0.

So what is all the fuss about and what can security practitioners, QSAs and firms that deal in credit card payment processing expect with 2.0? In one word – virtualization. The meteoric adoption of virtualization software from firms like VMware, Citrix and Microsoft that turns physical servers into virtual machines has been spawning a healthy debate as to what it means to adhere to PCI DSS requirements in the “virtualization” era.

In order to provide the much-needed guidance, PCI formed a virtualization special interest group (SIG), which examined some of the issues and challenges posed to PCI compliance in virtualized environments.

The group began meeting in the fall of 2008 and has brought together security vendors, practitioners, banks, merchants, auditors and QSAs, whom all have met on a regular basis over the course of a year and a half in order to draft a recommendation for how the PCI DSS might be enhanced to include virtualization technology.

The result of those discussions will be a revision to the PCI DSS v1.2 in order to include virtualization. However, if prior efforts are any indication, we can expect the PCI DSS council to start promoting solutions, technologies or vendors. What PCI DSS v1.3 or v2.0, as it may be called, will do is acknowledge that virtualization may require additional consideration in order to achieve compliance.

A Closer Look

Virtual machines (VM) aren’t like physical machines – they can’t be easily isolated from others. Physical servers can be easily cabled to a physical firewall or networking and routing device that will ensure traffic flows to and from that server are tightly controlled. Those same physical security and networking technologies are however blind to traffic flows between virtual machines.

Further, virtual machines are much more mobile than their physical counter parts. VMs can be added or replicated on a mouse click and they can change physical location just as easily. That means a VM containing cardholder data may reside on or migrate to a host with VMs that do not. This mixing of in-scope and out of scope VMs creates serious challenges for meeting the mandates of PCI DSS specifically when it comes to Section 2.2.1, which states organizations, should “implement only one primary function per server.” 

The crux of the problem is in how one interprets “server.” If a server is a physical device, then to restrict its function one does so with physical security and isolation constructs. However, if a server can be a VM then the way to restrict its function will require virtualization environment specific means of isolating that VM which contains cardholder data and ensuring that access to it is appropriate, limited, and that the VM is not at risk from neighboring VMs on the same host which may not be in-scope (i.e. doesn’t contain PCI regulated information).

The interpretation then of requirement 2.2.1 for the virtualized environment becomes extremely important both for adopters of virtualization who are looking to maintain their PCI compliance and for qualified security assessors (QSAs) and auditors who need to guide their clients on network architecture to meet compliance requirements.

What Organizations Need to Know

How can organizations implementing virtualized data centers and cloud computing environments meet the intent of PCI DSS 2.2.1 (there are obviously a lot more requirements and sub requirements with which to comply but this particular one is central to the debate)?

For starters, one obvious way to compliance is to confine in-scope VMs to certain VM hosts and disable vMotion which is the automatic migration of VMs. Essentially, this employs physical networking and security constructs to isolate VMs and restrict traffic flows to those PCI regulated VMs.

The shortcoming of this approach is that it takes a highly flexible network fabric, virtualization, and constrains it by legacy means (i.e. physical routers, switches, firewalls). The reason to allow live migration or vMotion on automated triggers is so that the virtualized network can self-optimize based on performance needs.

Also mixed-use workloads (i.e. critical VMs sharing a host with non-critical ones) is very common. In fact, a recent survey noted 86% of organizations that have virtualized allow mixed workloads. This again maximizes virtualization’s benefits for capacity and organizational self-provisioning of resources.

Another way to restrict and isolate PCI-regulated VMs is by employing virtualization specific security measures. There are quite a few options here as well, in terms of specialized software that is purpose built to protect virtualized environments and achieve compliance. The best performing of these solutions (i.e. the ones that deliver the highest throughput and most granular isolation) use the VMsafe fast path API.

The key takeaways include:

- Don’t look for the PCI DSS current or upcoming version to tell you exactly how to be compliant in your virtualized environment.

- Do look for QSA’s that have some measure of experience in providing guidance (i.e. are familiar with your virtualization platform and are aware of the options which maximize its value).

- Know that you have choices in achieving compliance.  Those choices include a new crop of virtualization specific security solutions that are actually fast performing and provide a higher degree of isolation and protection than what you are used to from your “traditional” non-virtualization specific security products.

This is a contributed byline from Johnnie Konstantas, the Vice President of Marketing at Altor Networks.

The Tech Herald sometimes publishes vendor articles, but retains the right to edit them for length and content. The opinions in this article are those of the author. They do not necessarily represent those of The Tech Herald or Monsters and Critics.

Like this article? Please share on Facebook and give The Tech Herald a Like too!