Evan Schuman's StorefrontBacktalk

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

PCI version 2.0 changed July 1. There actually are no new requirements, per se. But as of this date, the stated “best practices” for identifying and ranking risk vulnerabilities in Requirement 6.2 became mandatory. Merchants and service providers need to realize that this change reverberates through at least two other PCI requirements. Merchants and service providers who ignore this change may find themselves up a PCI tree later this year or when they begin their next compliance validation, especially if they don’t update their internal vulnerability scanning procedures.

As I wrote when PCI version 2.0 emerged in 2010, there were “evolving requirements” in the new version as well as clarifications of some existing ones. For the evolving requirements, the PCI Council gave merchants one-and-one-half years to plan their implementation before the changes became mandatory. We are now through this “best practices” period and, effective July 1, the new requirements are in place.

The principal change is to Requirement 6.2, which states that merchants and service providers must “establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.” This requirement applies to everybody. What changed from the previous PCI version is that it is the merchant or service provider who develops the risk ranking. The guidance indicates that the ranking should be on industry best practices, and this can include outside sources such as application vendor guidance, security Web sites or Common Vulnerability Scoring System (CVSS) scores.

This change generated a lot of discussion and anxious questioning when the Council unveiled it at the 2010 PCI Community Meeting. The Council’s intent was to give merchants flexibility in identifying and ranking risks based on their own industry and operating environment. The tone of the questions from the floor, however, challenged whether merchants had the security knowledge, expertise or even the time to assign these risk rankings.

Assigning the risk rankings is not to be an academic exercise. Those rankings feed back into at least three other PCI requirements.

One affected requirement is a subsection of 6.5. That requirement tells service providers and merchants who write payment applications that they must develop that code securely to prevent common vulnerabilities such as SQL injection, cross-site scripting, buffer overflow and insecure error handling. Under sub-requirement 6.5.6, merchants and service providers now must also reflect the risk rankings they developed under 6.2 in their application development process. Specifically, they must prevent those vulnerabilities they classified as “high” in 6.2.

A similar change is in Requirement 2.2, which tells service providers and merchants to update their configuration and system hardening standards to reflect those “high” vulnerabilities from 6.2.

However, it is the new internal vulnerability scanning requirement that will most likely affect the greatest number of merchants and service providers in the coming months.

Requirement 11.2.1 requires service providers and merchants to perform internal vulnerability scans at least quarterly or when there is a significant change in the network. What changed on July 1 is that now these internal scans have to include the high vulnerabilities identified in 6.2. As before, rescanning is required until passing results are obtained.

Keep in mind that PCI compliance requires passing quarterly internal scans for each of the previous four quarters. Therefore, the risk for merchants who neglect to identify and rank their vulnerabilities is that they will fail to scan for them and, as such, their internal vulnerability scans will be incomplete. As I’ve noted before, developing a backward-looking compensating control is possible, but it can test the creativity of the best QSA.

My advice for all merchants and service providers is to make sure you comply with the “new” Requirement 6.2. Then reflect those vulnerabilities in both your code development process and your internal vulnerability scans. Another clarification in 11.2.1 is that the scans must be performed by a “qualified” person who has “organizational independence” from the network being tested. In practice, this would include either an internal or an outside tester who has the expertise to run the scanner and interpret the results but is not involved in the management or administration of the target systems.

I suggest consulting with your security team and your QSA if you have any questions on these new requirements or their impact on your assessment. The time to get ready for your assessment is now, not in three or six months when you could already be looking at having incomplete or noncompliant internal scans.

What do you think? I’d like to hear your thoughts. Either leave a comment or E-mail me.