Fortinet Blog | News and Threat Research

If your organization accepts credit cards online you are likely more than familiar with the Payment Card Industry Data Security Standard (PCI-DSS). Since late 2004 this framework for developing payment card data security processes – including prevention, detection and incident response – has continued to evolve. The areas covered by PCI-DSS are extensive and range from installing and maintaining a firewall configuration, monitoring access to network resources, and even includes testing Web applications, all in order to protect cardholder data.

A key component of the requirements is quarterly vulnerability scanning; both to detect and report potential threats. Since January 1st, 2012 all assessments have been required to measure against version 2.0 of the PCI-DSS standard, which placed increased emphasis on promoting awareness around new vulnerabilities and exploits quickly. Starting on June 30th, 2012 requirements 6.2 and 6.5.6, formerly best practices, become mandatory for compliance.

Requirement 6.2 mandates than an organization “establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities” affecting the Cardholder Data Environment (CDE). The assessment procedures go on to say that risk rankings should be based on industry best practices. For organizations developing the risk ranking and classification system, best practices equates to an approach that assists in prioritization for remediation; such as a three-tier model (High-Medium-Low) or a decimal scale (5.0 down to 1.0). For example, criteria for ranking ‘high’ risk vulnerabilities may include a Common Vulnerability Scoring System (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. Implementing this risk ranking system within your organization’s vulnerability management process is important; scanning is not a vulnerability management program by itself.

For internally developed applications within the scope of an organization’s CDE, requirement 6.5.6 mandates testing against vulnerabilities classified as ‘high’ risk as part of the secure application development process. Applications are still required to be developed based on secure coding guidelines as defined in Requirement 6.5. This includes the common coding vulnerabilities outlined within the sub-requirements of 6.5 as well as industry best practices such as the OWASP Top 10. After June 30th, organizations will also need to ensure that secure coding guidelines attend to “All ‘High’ vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.2).”

For scanning vendors, PCI is requiring a more proactive and preventive stance towards vulnerabilities. Historically, PCI-certified scanning vendors have not been required to automatically warn a customer that they are vulnerable (upon discovering a vulnerability); when section 6.2 becomes a mandatory requirement, these same vendors will also have to update their software to ensure that issues are detected in subsequent scans. The ranking component is partially dependent on individual vendors and how they measure different results, but this is means that rather than waiting for another organization to designate the severity level of a specific vulnerability, vendors will now be required to assign them at least an interim risk ranking on discovery.

As you might expect given the complexity and associated confusion around PCI compliance, there are additional requirements both directly and indirectly affected by 6.2 and 6.5.6 becoming mandatory. Some of these include verifying that minimum security baselines (MSBs) required by Requirement 2.2 are updated, continued scanning until all vulnerabilities classified as ‘High’ and scored greater than a 4.0 by the CVSS as defined in PCI DSS Requirement 6.2 are resolved. Additionally, when a qualified security assessor (QSA) is engaged, they will be looking for additional materials related to requirements 6.2 and 6.5.6, including vulnerability management policy, risk ranking or risk classification methodology.

What does this change mean for those involved? If you are already following the best practices, perhaps very little from a compliance perspective, for online retailers the enforcement of this change should make it more difficult for exploits to remain undetected, hopefully avoiding a greater number of XSS, SQL-injection and other attacks. For scanning vendors, the effect of this change results in more efficient detection and notification to the client. Overall, ensuring that these requirements are addressed prior to the June 30th deadline will not only reduce the risk of falling out of compliance with PCI-DSS v2.0 but provide one more step toward making cardholder data more secure.

You can read more about the requirements on the PCI standards website:

https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf (pages 39 & 42)

For more information on Fortinet’s scanning capabilities, please visit: http://www.fortinet.com/solutions/vulnerability_management.html