PCI-DSS (Payment Card Industry Data Security Standard) version 2.0 is out since October 2010, but vulnerability ranking as defined in the 6.2.a testing procedure was considered as best practice until Jun 30, 2012, after which it becomes a requirement. The vulnerability ranking, how is now mandatory, will impact they way you classify your vulnerabilities, your change management process, your internal vulnerabilities assessment, your NTP monitoring, the way you document your hardening guides and your software development process.

Requirement 6.2

Just for recap, if you don’t know this requirement:

6.2 Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.
Notes: Risk rankings should be based on industry best practices. For example, criteria for ranking "High" risk vulnerabilities may include a CVSS base score of 4.0 or above, and/or a vendor-supplied patch classified by the vendor as "critical", and/or a vulnerability affecting a critical system component.
Testing procedure 6.2.a: Interview responsible personnel to verify that processes are implemented to identify new security vulnerabilities, and that a risk ranking is assigned to such vulnerabilities. (At minimum, the most critical, highest risk vulnerabilities should be ranked as "High".

As described above, PCI-DSS requirement 6.2 request that a formal vulnerability management process exist in order to rank the risk of the discovered vulnerabilities, before assets are put in production. Also the process should include outside sources for security vulnerability information (from vendors and/or vulnerability scanning tools and/or external sources). The vulnerabilities risk ranking could be “Low“, “Medium” and “High“, but at minimum the most critical vulnerabilities should be ranked as “High“. As described in the “Notes” of 6.2 requirement you could use CVSS scores for you risk ranking mapping.

Using CVSS v2 scoring

As described by Thierry Zoller in his “CVSS – Common Vulnerability Scoring System – a critique [ Part1 ]” blog post, CVSS v2 is not perfect and need some enhancements, maybe in v3. In order to explain the impacts of CVSS scores on the risk ranking we will use CVE-2012-1875 as example.

The base CVSS score, on National Vulnerability Database, for CVE-2012-1875, one of vulnerabilities patched in MS12-037, is 9.3 (HIGH). But by doing a Vulnerability Management process you could increase or decrease the risk ranking.

In CVSS v2 “Base Score Metric“, actual “Attack complexity” for CVE-2012-1875 is by default defined at “Medium“, but since an exploit is available through Metasploit we could consider that the “Attack complexity” should be set to “Low” (The attack can be performed manually and requires little skill or additional information gathering).

In “Temporal Score Metrics“, I would define “Exploitability” to “High” cause the Metasploit module is working for Internet Explorer 8 over Windows XP SP3 and Windows 7 SP1/SP2. For “Remediation Level” set to “Official fix” and for “Report Confidence” to “Confirmed“. In my opinion “Remediation Level” is the most disturbing in CVSS v2, cause if a patch exist, it does not imply that you have actually plan to deploy it or have actually deploy it.

In “Environmental Score Metrics“, “Collateral Damage Potential” and “Target Distribution” are related to your organization and on the number of potential vulnerable assets.

Example 1: If your vulnerable assets have a “Low” “Collateral Damage Potential” and they represent only “0 to 25%” of the total assets, the overall CVSS score will be 2.2.

Example 2: If your vulnerable assets have a “High” “Collateral Damage Potential” and they represent only “26 to 75%” of the total assets, the the overall CVSS score will be 7.

Example 3: If your vulnerable assets have a “Low” “Collateral Damage Potential” and you don’t known the number of potential vulnerable assets, the overall CVSS score will be 9.4. This score demonstrates you the importance to have a good inventory of your assets.

You can also play with the CVSS v2 “Security Requirements” metrics how will allow you to customize the CVSS score depending of the importance of the affected assets in terms of confidentiality, integrity and availability.

I would recommend to organizations, how don’t have the resources (updated CMDB, automatic vulnerability scanner, etc) to customize the CVSS score, and also because CVSS v2 is not perfect, to only take the base CVSS score as the default value to do vulnerability ranking.

Requirement 2.2

Requirement 2.2 is also impacted by requirement 6.2. Just for recap, if you don’t know this requirement:

2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
2.2.b Verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.2

If a vulnerability is discovered or published, and one of your system component is vulnerable despite an industry-accepted hardening standard is configured, you will have to update, asap or before going in production, your configuration standard in order to avoid new vulnerabilities during installation of a new system component.

Requirement 6.5

Requirement 6.5 is also impacted by requirement 6.2. Just for recap, if you don’t know this requirement:

6.5 Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities in software development processes, to include the following:
6.5.6 All "High" vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.2).

As described in the requirement a formal software development process should exist and include references to the vulnerability ranking with associated resolution processes. If a “High” vulnerability is discovered or published, and one of your application is vulnerable, you will have to correct or mitigate the vulnerability, asap or before going in production.

Requirement 10.4

Requirement 10.4 is also impacted by requirement 6.2. Just for recap, if you don’t know this requirement:

10.4 Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.
10.4.a Verify that time-synchronization technology is implemented and kept current per PCI DSS Requirements 6.1 and 6.2.

Accurate time synchronization is an important part of the security process, and most of time this requirement is under estimated and risks associated to time synchronization defect are under evaluated. Each reported time synchronization vulnerabilities should be carefully evaluated and associated with a risk ranking. For example, if a server has an offset of more than x seconds then the event could be considered as a “High” vulnerability ranking. Another examples could be that the NTP client could no more connect to the NTP server, or that a configuration change has be done on the NTP client or server, etc.

Before Jun 30, it wasn’t mandatory to resolve “High” vulnerabilities related to time synchronization vulnerabilities. Now it is mandatory and you should correct it asap and validate the correction.

Requirement 11.2.1

Requirement 11.2.1 is also impacted by requirement 6.2. Just for recap, if you don’t know this requirement:

11.2.1 Perform quarterly internal vulnerability scans.
11.2.1.b Review the scan reports and verify that the scan process includes rescans until passing results are obtained, or all "High" vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved.

As described in the requirement a formal quarterly scanning process should exist and include references to the vulnerability ranking with the requirement of a rescan until the vulnerability is resolved. Before Jun 30, it wasn’t mandatory to resolve “High” vulnerabilities after a quarterly internal vulnerability scan. Now it is mandatory and you should correct it asap and validate the correction by a rescan.

Requirement 11.2.3

Requirement 11.2.3 is also impacted by requirement 6.2. Just for recap, if you don’t know this requirement:

11.2.3 Perform internal and external scans after any significant change.
11.2.3.b Review scan reports and verify that the scan process includes rescans until: 
- For external scans, no vulnerabilities exist that are scored greater than a 4.0 by the CVSS, 
- For internal scans, a passing result is obtained or all "High" vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved.

As described in the requirement a formal scanning process, after any significant change, should exist and include references to the vulnerability ranking with the requirement of a rescan until the vulnerability is resolved. Significant changes are defined by examples in requirement 11.2 : new system component installations, changes in network topology, firewall rule modifications, product upgrades.

Before Jun 30, it wasn’t mandatory to resolve “High” vulnerabilities introduced by a significant change and discovered by an internal vulnerability scan. Now it is mandatory and you should correct it asap and validate the correction by a rescan.

Conclusion

As you can see, requirement 6.2 has introduce tonnes of new requirements and you should plan asap, if you are PCI-DSS compliant, all required actions in order to comply with them.