SecureState Blog

Read SecureState's award winning blog.

Payment Card Industry (PCI) requirements 6.2 and 6.5.6, formerly best practices, become mandatory requirements for PCI Data Security Standards (DSS)compliance on June 30, 2012!


How will this affect our compliance with PCI DSS?

Organizations will be required to assign risk rankings to newly detected vulnerabilities affecting the Cardholder Data Environment (CDE) as part of the on-going vulnerability identification process established in Requirement 6.2 and as part of their comprehensive Vulnerability Management Program.

Requirement 6.2 states that organizations must “establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.”

When developing a risk ranking or risk classification system, ensure that these systems are based upon industry standards or best practices.  The risk ranking assignment should classify risks in a manner which facilitates prioritization for remediation, such as a three tier model of High, Medium, Low or a decimal scale of 5.0 to 1.0.


What impacts does this have on our in-house or internally developed applications?

When application development is in-scope of an organization’s CDE, Requirement 6.5.6 will obligate testing against vulnerabilities classified as “high” risk as part of the secure application development process.

In essence, you will be required to develop your applications based on secure coding guidelines as required by Requirement 6.5. This includes preventing common coding vulnerabilities in software development processes as outlined within the sub-requirements of 6.5 and industry best practices like the OWASP Top 10. After June 30, you will also need to ensure your secure coding guidelines address “All ‘High’ vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.2).”


How else might this change impact compliance with PCI DSS?

A few other requirements are directly and indirectly affected by 6.2 and 6.5.6 becoming mandatory. They include:

  • As new vulnerability issues are identified and risk ranked, you must verify that the system configuration standards and/or minimum security baselines (MSBs) required by Requirement 2.2 are updated.
  • When performing quarterly internal vulnerability scans and remediation, you must continue the process until a rescan has passing results or all “High” vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved.
  • When performing internal and external scans after any significant change, you must scan/rescan and remediate until:
    • A passing result is obtained or all “High” vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved (internal scans).
    • No vulnerabilities exist that are scored greater than a 4.0 by the CVSS (external scans).


What to expect from your QSA

When a Qualified Security Assessor (QSA) is engaged to consult on your CDE, complete a PCI Gap Assessment, and/or complete a PCI Audit to issue a Report on Compliance (RoC) they will be looking for additional evidence related to requirements 2.2, 6.2, and 6.5.6. Some of the evidence will include:

  • Your organization’s Vulnerability Management Policy
  • Your organization’s methodology and process to assign risk ranking or risk classification to identified vulnerabilities
  • Your organization’s system configuration standards and/or MSBs and documented change requests or completed changes as new vulnerability issues are identified and risk ranked
  • Your organization’s quarterly internal vulnerability scans, rescan, and remediation steps between scans


Ranking risk an increasing priority

It is important to implementing a risk ranking system within your organizations’ vulnerability management program and process. Remember, just completing yourvulnerability scanning is not a vulnerability management program by itself. Vulnerability Management is an ongoing process to find, categorize, and address vulnerabilities in your environment. By taking proactive measures to ensure that proper controls are in place prior to the June 30 deadline, you can reduce the risk of falling out of compliance with PCI DSS v2.0.