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.

Expectations are high for the upcoming PCI Community Meeting. In addition to hearing the latest on mobile commerce and point-to-point encryption (P2PE), this is a feedback year. That means this is the meeting when the PCI Council and the card brands respond to the comments and suggestions offered by participating organizations (POs) and assessors. Based on the information provided by the PCI Council, it is listening. The next step is to hear its responses.

Here is how I hope the Council will respond to the feedback on PCI DSS version 2.0.

PCI DSS, along with the companion standard PA-DSS, has a three-year lifecycle. This year, the second year of PCI DSS and PA-DSS v2.0, the PCI Council asked every PO, qualified security assessor (QSA) firm and approved scanning vendor (ASV) firm to provide feedback based on their experience with the current versions of both standards.

I’ll focus on PCI DSS, because that standard has the most immediate impact on retailers and other merchants and service providers.

The Council established its listening credentials. It provided POs with a 66-page document detailing every single comment submitted, together with the disposition of that comment. It makes for some interesting reading. If you haven’t seen the document, get a copy from your principal contact. If you are not a PO, maybe this is another reason you should be: PCI DSS impacts your business, so you might want to have a seat at the table.

The Council summarized the feedback in a press release. Based on that release, here are the six feedback areas it is committing to consider, together with some thoughts on what I hope the Council will say.

The first area is PCI DSS Requirement 11.2, which addresses vulnerability scanning. Suggestions include prescribing use of specific tools, requiring ASVs to perform internal scans and defining what constitutes a “significant change.” I personally doubt the Council will—or should—recommend a particular tool or product, so don’t expect too much on that front. As for what constitutes a “significant change,” that currently includes things like reconfiguring your network, installing new network devices or adding new payment applications. I don’t know how much more specific the Council can be without being overly prescriptive.

Remember that although PCI DSS may be a prescriptive standard in many ways, the standard is full of requirements that call for judgment and a thoughtful risk-based approach to give merchants and service providers flexibility. If you don’t like flexibility, you’ll hate the alternative.

The second feedback area is clarifying the definition of PCI DSS scope. I’ve addressed scoping in an earlier column, so there is not too much to add. Hopefully, the Council can resolve this question and move on to critically important areas such as mobile commerce and P2PE.

The third feedback area highlights an issue that, in this QSA’s opinion, too many merchants take too lightly: PCI DSS Requirement 12.8. This requirement addresses how merchants manage service providers. The feedback asked for clarification on two areas: What constitutes a “service provider”; and what is required in written agreements that apply to service providers.

The first part of this one surprised me. I don’t get what is unclear about “any entity that can affect the security of the transaction.” However, I am happy this area made the list because of the request to clarify what details must be in the service provider’s agreement with the merchant.

I don’t think there is any need to change the current requirement. It is fine as it is. The problem is the lack of a corresponding service provider requirement to agree to the contract language mandated by Requirement 12.8.2. As I’ve written before, the simplest way to fix this is to make providing that language a condition of the service provider’s own PCI DSS validation.

The difficulty is that Requirement 12.8.2 is asymmetric.