Topics:

How About A Little Service Provider Responsibility Here, PCI-Wise?

Tools

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

Among all of the PCI requirements, there is one that reflects a fundamental imbalance. That requirement is 12.8.2, which requires all merchants to: "Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess." This is a great requirement, but it places the entire burden on the merchant. Where is the corresponding requirement that a service provider actually agrees to deliver that written acknowledgement?

This situation can be addressed with one simple change to 12.8.2. It would apply to service providers only. The change is to add wording that requires service providers to deliver this "acknowledgement" in writing to their customers.

Have more PCI phrasings you want changed? You now have your chance. The good news is that you still have time, although not much. Participating Organizations now have until April 15 to submit up to five ideas for improving PCI DSS (as well as PA-DSS). Therefore, your first step is to speak to the PCI contact within your company and see what feedback she/he is preparing.

Depending on what you learn, you may want to consider the following suggestions. I've based them on issues I see at retailers and other merchants. I hope the suggestions stimulate some thinking about what changes retailers want and need to see in the upcoming revisions to PCI.

Participating Organizations can make as many as five comments. The comments may:

  • Request clarification of a particular PCI requirement or testing procedure.
  • Request additional guidance on how to meet a requirement.
  • Suggest a change to an existing requirement or testing procedure.
  • Offer a completely new PCI requirement.
  • Provide feedback to the PCI Council on just about any topic without necessarily requesting any changes.

Let's take them one at a time.

My nominee for requesting clarification is: At what point does a system reseller or integrator become a PCI service provider? I've written about how PCI pretty much ignores system resellers and integrators, even though they play a crucial role in many retailers' POS implementations. In many cases, the reseller/integrator's work includes configuring firewalls, changing default passwords and other security-related functions. When they do this, a retailer (or their QSA) could view the reseller/integrator as a PCI service provider, because their actions directly affect the security of each transaction. When I make this point to clients, the reseller/integrator frequently claims that it is completely out of PCI scope, because it does not store, process or transmit any cardholder data. Rather than repeating all the arguments, the PCI Council can do all parties involved a great service by clarifying what actions, tasks or duties would cause a reseller/integrator to be considered a service provider.

Resellers/integrators should weigh in with the PCI Council and offer their perspective, which may be different from mine. I hope they do this, and I hope the Council will balance retailers' need for security in clarifying this issue.

I'll take a pass on requesting additional guidance, because the Council has three Special Interest Groups (SIGs) currently working on guidance for cloud computing, E-Commerce and risk analysis. Each SIG is active, and we can expect their reports later this year.

Then there's the 12.8.2 issue, the one about service providers taking responsibility. I raised this issue at the PCI Community meeting two years ago. I heard some agreement from the card brand people there, and I saw people taking notes. Unfortunately, nothing has happened to fix this unbalanced situation.

I spoke to the counsel for a large service provider about this seemingly one-sided requirement. They felt the merchant only needed to know the service provider was PCI compliant to meet 12.8.2. I disagreed, noting that the requirement explicitly deals with acknowledgement of responsibility, not just compliance. Alternatively, if the PCI Council believes I am mistaken and merchants can meet 12.8.2 by simply validating their service provider is PCI compliant, then they need to rewrite the requirement to state that.

Most retailers probably feel we have enough PCI requirements, and we don't need to add any more. I suggest we need at least one new requirement based on recent compromises of POS equipment. That requirement is to mandate physical inspection of POS devices on a regular basis.

PCI already requires that retailers document their daily log analysis, semi-annual firewall rule reviews, quarterly vulnerability scans and quarterly tests for rogue wireless networks. Given at least one retailer's recent experience, now is the time to add regular (monthly? quarterly?) inspection of all POS devices for evidence of tampering.

The PCI Council has an excellent publication that describes what retailers need to do. It even has pictures. Now is the time to go beyond "best practices" and make regular, physical inspection a requirement. This new requirement would most logically fit under PCI Requirement 11 (Regularly test security systems and processes). We could make it an extension of 11.1, which addresses rogue wireless networks.

My guess is that every retailer will have loads of thoughts that qualify for the general feedback category. I'd like to contribute the suggestion that the Self-Assessment Questionnaires (SAQs) are out of date, and most reflect neither current merchant practices nor current threat vectors. I've detailed my recommendations for updating the SAQs, so I'll leave it to others to toss in their own feedback.

All of these suggestions address PCI DSS, which is the main concern of most readers here. I would note that the PCI Council is also soliciting comments on PA-DSS. Taking the view of a retailer (rather than a software developer), I would encourage retailers to think about what would make their life easier when choosing a PA-DSS-validated payment application.

Too many merchants are still under the misperception that implementing a PA-DSS-validated application makes them PCI compliant automatically. Unfortunately, that is not the case. Although a PA-DSS-validated application can simplify PCI compliance (if it is implemented per the vendor's PA-DSS Implementation Guide and in a PCI compliant environment), it is not a silver bullet.

A second misperception of many merchants is that PA-DSS-validated applications do not store electronic cardholder data. That is wrong. In fact, many applications on the PCI Council's list of validated applications store cardholder data. That's just the way they were built.

A merchant storing electronic cardholder data may not validate their PCI compliance using one of the shortened SAQs. I work with merchants who aimed to simplify their life by using an application from the PCI Council's list, only to find their shiny new payment app threw them into SAQ D, because it stored electronic cardholder data.

Therefore, I suggest retailers might provide one bit of PA-DSS feedback: Include an item in the PA-DSS validation that states whether the application stores electronic cardholder data at any time. The options for this item would be one of: the application stores electronic cardholder data; the application does not store data; or the application is configurable either to store or not to store based on the merchant's preference.

What do you think? What was your feedback to the PCI Council? I'd like to hear your thoughts. Either leave a comment or E-mail me at wconway@403labs.com.