A couple of weeks ago we had a conference call with our PCI SSC QA team. During that call, one of the areas we discussed was the relevance of PABP or PA-DSS certification on the PCI DSS Security Assessment Procedures (SAP) or the Self-Assessment Questionnaires (SAQ). At the end of the discussion, essentially what we were told was that the PABP and PA-DSS were not relevant to a merchant’s compliance with the PCI DSS.
Based on this definition, I can understand why software vendors are so anti-PCI compliance. If the PABP or PA-DSS does nothing to help customers achieve PCI compliance, then why pay to have your solutions certified? From a merchant’s perspective, why buy a PABP or PA-DSS certified application if it is meaningless to your PCI compliance under the PCI DSS? We were even told in our QSA recertification training in the spring that the relevance of PABP and PA-DSS was really nothing. Trust me, there is nothing worse than telling a client that, even though their application is PABP or PA-DSs certified, you still have to cover all of that ground all over. In my mind, what this implies is that PA-QSAs are not to be trusted. This is a situation similar to relying on other QSA’s work.
Yes, I know that Visa mandates application certification for purchased solutions. However, if there is no business benefit other than making Visa happy, why bother? It is positions like this that give critics the material to successfully argue the short sidedness and irrelevance of the PCI standards.
I do agree that you cannot use PABP or PA-DSS compliance to just brush aside all of the PCI DSS. However, there are some obvious areas where such a PABP or PA-DSS certification should be a valid control as long as the application is implemented per the vendor’s Implementation Guide which must explain how to maintain PCI compliance.
For instance, if you have an application that is PABP or PA-DSS certified, what is the point of covering requirements 3.2, 3.3 and 3.4? In my opinion, if the application is implemented properly, this section should be Not Applicable because the application is PABP or PA-DSS compliant. However, based on our training, marking this not applicable is not allowed.
Another set of meaningless requirements when dealing with a certified application are 6.3 – 6.5. As long as the client is not modifying the application, these are pointless. The PABP and PA-DSS cover these for the software publisher, so they should be not applicable as well. However, as a QSA you are still required to prove that you did the proper assessment of these points regardless.
Nine times out of ten, the vendor is really irritated (this is being kind) when you ask them to explain how they meet these requirements. And rightly so. They have spent tens of thousands of dollars per application to have them assessed as PABP and/or PA-DSS compliant. And now you have an army of QSAs contacting them to cover the same ground as the PA-QSA covered.
At some point, the PCI SSC needs to get a clue about what is going on out in the field. I know that this topic has been brought up on a number of occasions, but there just does not seem to be any interest in dealing with the issue. Until merchants, service providers and software vendors start to see that the PCI standards have a real business benefit, we are going to fight our way tooth and nail to a secure card processing environment.
I have a question that I think is related to this post.
Is correct to assume that open source ecommerce solutions like
Magento Community, VirtueMart, Ubercart, Zen Cart etc
will NEVER be PA-DSS compliant since (by their very nature) they
are modifiable and extensible via plugins?
Does it mean that a commercial ecommerce solution will need
to be “locked down” with encripted code to be PA-DSS compliant?
I think maybe X-cart is going in that direction with the “X-payments” module.
Thanks for the post! Very enlightening.