The Payment Card Industry Data Security Standards (“PCI DSS”) version 2.0 dated October 2010 became effective on January 1, 2011. There were many subtle and not so subtle changes from the previous version of the standard. The majority of the change became effective January 1, 2011, when requirement 6.2 was only considered a “best practice” by the PCI DSS. As of June 30, 2012, requirement 6.2 will become a requirement. With June 30 just a few days away, if your report on compliance is not in the final stages of report issuance, you need to be prepared to comply with requirement 6.2.
Requirement 6.2 requires that your organization “establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.” The intent of the requirement as outlined in Navigating PCI DSS published by the PCI Security Standards Council (“PCI SSC” or the “Council”) is to keep your organization up-to-date on newly discovered vulnerabilities. The PCI DSS requires your organization to shift from a reactive vulnerability remediation process, where you wait for communications from the vendor, to a proactive vulnerability identification process that includes information from independent third parties, such as news groups and vulnerability mailing lists.
In order to comply with this requirement your organization should have three critical steps in place; vulnerability identification, risk ranking and remediation. The QSA will perform testing procedures to ensure these steps are in place to meet the requirement.
The first step requires that your organization has a process in place to identify new vulnerabilities “to monitor common industry vulnerability news groups and mailing lists for vulnerabilities and potential workarounds that may not yet be known or resolved by the vendor.” To comply with this portion of the requirement you should update or implement a policy that identifies the mailing list(s) and who in the organization should subscribe to them. There are several industry accepted mailing list that disseminate information regarding vulnerabilities including lists published by SysAdmin, Audit, Network, Security Institute (“SANS”), National Institute of Standards and Technology (“NIST”) and Security Focus BugTraqs.
The next required step ranks the vulnerabilities based on their risk to your organization. The process of ranking involves analyzing the impact to your organization if the vulnerability is exploited and the likelihood that an attacker can exploit the vulnerability in your organization. The Council provided additional guidance on the risk ranking process by referencing the NIST Common Vulnerability Scoring System Support (“CVSS”) http://nvd.nist.gov/cvss.cfm and NIST Special Publication 800-53 Recommended Security Controls for Federal Information Systems and Organizations http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf. Your organization will need a documented methodology for ranking vulnerabilities and evidence that the vulnerabilities have been ranked based on the methodology.
Lastly, a process should be implemented to remediate the vulnerabilities identified as High. There are two specific places that High risk vulnerabilities should be considered. During the application development process the vulnerabilities should be reviewed as part of the secure coding process to ensure the newly developed application is not susceptible to the vulnerability. Also, they should be considered as part of the quarterly vulnerability remediation process.
Requirement 6.2 is not only a requirement for organizations that comply with PCI DSS, but a security best practice for securing your environment. By implementing the steps above, you will be able to proactively identify security vulnerabilities that could negatively impact your environment and take the necessary steps to remediate them based on the risk they present to your organization.