PCI DSS 2.0 Clarifies Compliance in Virtual Environments

Chris Noell

The good news about the new PCI DSS standard version 2.0 is that it’s not earth-shaking. In most respects, the changes it introduces are relatively minor, and there are no huge hurdles to adopting it. ANX strongly urges enterprises to start their PCI DSS 2.0 migration now to begin realizing some of the benefits it introduces – such as the fact that patching requirements move from the hard deadline of 30 days to a risk-based approach.

 

Enterprises that operate in virtualized environments or are looking to do so should definitely step up to PCI DSS 2.0, as virtualization is one area where the new standard does make substantial changes. There are several improvements that provide insights for best business practices, and that should also make QSAs much more consistent.

 

In assessing PCI DSS 2.0 compliance in virtualized environments, QSAs will be looking at four primary issues:

 

• Visibility. In cloud environments especially, it can be difficult to identify data flow with precision. Firewalls, IPSes, and other types of network security aren’t in the traffic path of packets flowing between VMs, so monitoring and testing the virtual network requires specialized technology.

 

• Separation of Duties. Virtualized network servers and networks are grouped logically, not necessarily physically, and sensitive data can become mixed with applications that have no business being in the cardholder environment. Access policies must be tied to logical rather than physical groupings to enforce separation of duties and need to know.

 

• Live Migration. In another issue of knowing exactly where data is, VMs, unlike physical servers, can move from one physical location to another in search of a host that can provide more computing resources. VM may traverse zones of trust, moving to areas where the security policy is not as restrictive as it should be for an in-scope PCI server.

 

• Single Function to a Server or VM. If a VM equals a server, then PCI DSS compliance requires that it be purposed for a single function to reduce potential vulnerabilities.

 

So, how to best address these concerns? If you follow these seven recommendations, audit outcomes should be very positive:

 

1. Ensure you have the means to visualize and report on all inter-VM and intra-VM traffic.

 

2. Logically isolate any individual VMs or VM groups by a security policy that limits access and restricts their function to a single application.

 

3. Introduce a mechanism that will inspect traffic allowed into in-scope VMs and alert/report if vulnerabilities or malware are detected.

 

4. Automatically enforce a compliance policy for in-scope VMs.

 

5. Automatically quarantine in-scope VMs whose security posture changes to non-compliance.

 

6. Segregate virtual network, system, and security function administration in the virtualized environment by individuals and their role in the organization.

 

7. Define and enforce security policy governing access to in-scope PCI servers and VMs consistently and as part of a singular process.

 

As further protection in a virtualized environment, take steps to ensure that you’re not storing any cardholder data that you really don’t need to be storing. Eliminating data that’s really not needed, including such shadow databases as Excel worksheets and stored reports, can go a long way toward reducing scope.

 

And to really reduce scope, consider tokenization, which encrypts sensitive data, stores it in a central data vault, and generates surrogate values (“tokens”) to reference it. As the tokens that flow throughout the virtualized environment reveal no sensitive data to unauthorized persons and applications, you can argue that such data is entirely out of scope.