What’s New in PCI v2.0 for Vulnerability Management (NCSAM)

On Thursday, the PCI SSC released version 2 of the PCI Data Security Standard. It’s the first big change to the DSS since July 2009. Most changes in the new version are minor clarifications or additional guidance. The new standard is more explicit about requirements to protect cardholder data, including more detailed procedures to verify that organizations are compliant.

All in all, there is a growing number of merchants who are implementing security controls for compliance with PCI DSS. The Council has done a great job listening to feedback and being responsive, in an open community-based effort, to get the standards to a mature state.

Now it is attempting to stay ahead of the curve with new technologies in a dedicated effort working with industry leaders. Ultimately, we expect DSS 2.0 to help merchants improve the security of their cardholder data environment, while providing flexibility with their compliance efforts.

Summary of New Requirements

Requirement 6.2: Assign risk ranking to vulnerabilities (Internal scanning)
DSS requires merchants to have a vulnerability management program in place to identify and fix vulnerabilities discovered in the cardholder data environment (CDE). With the old v1.2.1, merchants were required to patch and rescan internal networks until “passing results are obtained.”

The term “passing result” was not defined and did not account for the criticality of the systems within the CDE. With v2.0, the Council requires merchants to use a risk-ranking system for these vulnerabilities based on industry best practices like CVSS. At minimum, the scoring system should identify critical high risk vulnerabilities as "HIGH."

Depending on criticality of the vulnerability related to a critical component in your CDE, a low severity vulnerability on your database storing cardholder data might be HIGH and a high severity vulnerability on a backend router might be a LOW.

The Council has left it open for merchants, Approved Scanning Vendors and Qualified Security Assessors to decide which scoring methodology to use. I expect most merchants to use CVSS 2.0 scoring with its base, temporal and environmental components to decide what is HIGH.

New steps in v2.0’s Requirement 6.2 take effect after June 30, 2012. Till then, this is considered to be a best practice.

Requirement 2.2.1 Virtualization and one primary function per server

The old Requirement 2.2.1 was to implement only one primary function per server. For example, this prohibited implementing a web server function and database server function on the same 'server.' It was not clear in a virtualized environment if two VMs running on same physical hardware box was considered as two primary functions per 'server.' In v2.0, the Council clarifies this by saying in virtualized environment, you can have multiple VMs on same physical box as long as each image implements one primary function.

So you can have VM for webserver and VM for DB server running side by side but you can't have one VM with webserver and DB server on the same image. This should definitely accelerate the use of virtualization in PCI CDE since clarity for compliance was an issue that was holding back the adoption of virtualization.

Requirement 6.5 Secure application development best practices

DSS v2.0 is no longer tied to OWASP guidelines. There is now room to use other industry best practices such as OWASP, CWE Top 25, CERT Secure Coding, etc.

Requirement 1.3.5 Outbound traffic from CDE to IPs outside DMZ

Language in the old Requirement 1.3.5 seemed to indicate there was no room to have any outbound connection from CDE to IPs outside the DMZ – even for legitimate reasons such as transmitting encrypted information from one network to another over SSL port 443. DSS v2.0 says merchants can have outbound access open as long as there is legitimate reason and the access has been explicitly authorized by the merchant.

Requirement 4.1.1 WEP as security control

DSS v1.2.1 indicated there should be no WEP in the CDE at all after June 30, 2010. But DSS 2.0 has modified the language to say ‘Use of WEP as security control is prohibited’. So mere presence of WEP in CDE does not fail you as long as the WEP is not used as the security control.

You can have WEP in the CDE as long as it is considered the same as an open wire. This means you need to have another level of encryption to protect data sent across a WEP connection, it can't be pain text because you have WEP (e.g. send data over SSL on a WEP witless connection would seem to be ok).

Requirement 8.3 Use of two-factor authentication

You might find it funny to learn that some merchants have used the same authentication method twice and called it “two factor.” Folks: that is NOT two-factor authentication. Even having two different passwords is NOT two-factor. To illustrate, think of a stealth key logger installed on your computer that will be able to steal both of your passwords, and used those to log in and steal cardholder data.

The Council explicitly says you must use TWO different methods of the following: 1) Something you know, like a password; 2) Something you have, like a token or smart card; or 3) Something you are, like biometric data.


During the Community Meetings, the Council described its ongoing work to address security of cardholder data as it relates to emerging technologies such as EMV, point-to-point encryption, tokenization and virtualization.

Some of the changes in v2.0 already reflect recognition of the new technologies. I am sure more updates will be coming in these areas. The Council now has a dedicated Chief Technology Officer who is actively working to make sure the DSS stays in step with rapid changes in technology.

Three Year Lifecycle

You can expect regular updates to the DSS every three years. The old cycle was 24 months, which ended up being too rushed for everyone. The PCI DSS 3-Year Lifecycle provides a more orderly process, and includes provision for shorter-term adoption of new controls to meet urgent vulnerabilities.

Expect PCI DSS v3.0 in October 2013. Given the maturity of the DSS, future changes are likely to be continuous refinement rather than major new requirements.

Key Dates

- October 28, 2010 - PCI DSS 2.0 and supporting documents published. Merchants should review the new requirements, along with documents such as Navigating the PCI DSS guide, and new Self-Assessment Questionnaires (SAQ).

- January 1, 2011 - PCI DSS 2.0 becomes effective. Merchants can chose to validate compliance against v2.0 or the old v1.2.1 after this date. Merchants are not allowed to mix and match requirements from both.

- December 31, 2011 - PCI DSS 1.2.1 is retired and can no longer be used for compliance validation.

Essentially, for all of 2011 you can use either version as long as your assessment is completed before the end of 2011. Assessments ending in 2012 must use v2.0 for compliance validation.

Sumedh Thakar is the Director of Engineering for Qualys. The views expressed in this feature are his, and should not be considered an authoritative interpretation of the new or old DSS for purposes of compliance.

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!