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.The difficulty is that Requirement 12.8.2 is asymmetric. That is, the merchant needs service providers to acknowledge they "are responsible for the security of the cardholder data" they possess. That seems fair. Unfortunately, there is no corresponding PCI DSS requirement telling the service provider it has to provide that acknowledgement in its merchant agreement. We'll see what the Council eventually decides, but I'm keeping my fingers crossed just in case.
The fourth feedback area contains suggestions for updating the SAQs. I think everyone agrees that the shortened SAQs need a fresh look. I've offered my own suggestions for updating the SAQs. (Indeed, I've done it more than once.) I know the Council has been looking at the SAQs, so this should be a great opportunity to hear where its thinking is taking us.
I was also surprised by the fifth feedback area, which is a request for clarification on PCI DSS Requirement 3.4. That requirement describes how to protect stored cardholder data. I am sure the Council knows that encryption and key management are complex topics, and that truncation/hashing and tokenization are not always convenient methods to store and retrieve data. Perhaps that is the whole point of the requirement: to make merchants think twice about storing electronic cardholder data in the first place.
I will be listening for clarification or updates on hashing and tokenization in particular. I'd specifically like more information on what constitutes a "high-value token." (For more background, read "Tokens Are Not The Same As Encryption" and "The PayPal Problem.")
The final feedback area the Council promised to address is PCI DSS Requirement 8.5, which goes into excruciating detail (there are 16 sub-sections) on passwords. I have a lot of sympathy for the POs that asked for a little mercy here. Passwords themselves are a problem area in more than just PCI DSS. I don't know if the Council will simplify or shorten the requirements. What would be interesting to hear is whether it is willing to permit merchants and service providers more flexibility in determining their own password requirements, so long as they meet some generally accepted industry standard for being "strong."
There is precedent for such a change in PCI DSS today. For example: Requirement 6.1 allows merchants to use "a risk-based approach" when installing security patches; Requirement 6.2 has merchants defining their own high-risk vulnerabilities; and much of Requirement 12 lets merchants set their own security policies.
The Council has taken great strides toward making the 2012 Community Meeting a "listening" meeting. It has provided complete information on every piece of feedback on the current version of PCI DSS, and it has included its response as to whether the suggested change or clarification was accepted for current consideration. You may not agree with all the answers, but nobody can criticize the Council for not listening. The next step is seeing what impact the feedback will have on the next version of PCI DSS (and PA-DSS).
Did your organization provide feedback on the current versions of PCI DSS and PA-DSS? Were your suggestions or comments accepted for current consideration or were they deferred? What do you think about the six feedback areas in the Council's press release? I'd like to hear your thoughts. Either leave a comment or E-mail me.