Reminder About “New” PCI DSS Requirements
We wanted to remind those organizations impacted by the Payment Card Industry Data Security Standard (PCI DSS) that two “best practices” will be maturing and going into effect as requirements after June 30th.
Both of the soon-to-be requirements fall under the section of the Standard devoted to developing and maintaining secure systems and applications (Requirement 6).
The first “new” requirement comes in the form of 6.2.a:
6.2 (a) Is there a process to identify newly discovered security vulnerabilities, including a risk ranking that is assigned to such vulnerabilities? (At minimum, the most critical, highest risk vulnerabilities should be ranked as “High”.)
Here is the guidance offered from the PCI Security Standards Council in the “Navigating PCI DSS” document for this specific requirement:
The intention of this requirement is that organizations keep up-to-date with new vulnerabilities that may impact their environment.
While it is important to monitor vendor announcements for news of vulnerabilities and patches related to their products, it is equally important 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.
Once an organization identifies a vulnerability that could affect their environment, the risk that vulnerability poses must be evaluated and ranked. This implies that the organization has some method in place to evaluate vulnerabilities and assign risk rankings on a consistent basis. While each organization will likely have different methods for evaluating a vulnerability and assigning a risk rating based on their unique CDE, it is possible to build upon common industry accepted risk ranking systems, for example CVSS. 2.0, NIST SP 800-30, etc.
Classifying the risks (for example, as “high”, “medium”, or “low”) allows organizations to identify and address high priority risk items more quickly, and reduce the likelihood that vulnerabilities posing the greatest risk will be exploited.
Requirement 6.5.6 is the other requirement going into effect this weekend:
6.5.6 [Is prevention of common coding vulnerabilities covered in software development processes to ensure that applications are not vulnerable to] All “High” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.2)?
Again, here is some guidance from the “Navigating PCI DSS” supplement:
Any high vulnerabilities noted per Requirement 6.2 that could affect the application should be accounted for during the development phase. For example, a vulnerability identified in a shared library or in the underlying operating system should be evaluated and addressed prior to the application being released to production.