10
Jun
09

PABP or PA-DSS Compliance Does Not Imply PCI DSS Compliance

I wrote about this at the ‘old’ PCIAnswers.com Web site but apparently, it bears repeating after dealing with a number of clueless software vendors lately.  PABP or PA-DSS compliance does NOT, repeat, NOT mean that your customers are automatically PCI DSS compliant.  These standards complement one another, but they do not supersede each other.  The PABP and PA-DSS standards just mean that the certified software properly processes, stores or transmits cardholder data.

Some vendors seem to be very myopic regarding their responsibilities regarding their customer’s compliance with the PCI DSS.  They apparently have never read the PCI DSS requirements.  They believe that if they successfully go through the PABP/PA-DSS certification process, their responsibility is done.  All they have to do once their solution is certified is sell their software and say that they have their PABP/PA-DSS certification.  Wrong!

In some cases, I have to wonder how these vendors even got their PABP/PA-DSS compliance in the first place.  The reason I believe this is the difficulty I have had getting a hold of the required implementation guide.  I have run into instances where vendors have refused to provide an implementation guide or have even admitted that such a document does not exist.  Hello!  This is a requirement of the PABP and PA-DSS standard.  See page vii of the PA-DSS Requirements and Security Assessment Procedures, Software Vendors, third bullet point that states, “Creating a PA-DSS Implementation Guide, specific to each payment application, according to the requirements in this document.”  If that is not enough, on page ix under PA-DSS Implementation Guide and Appendix A are dedicated to nothing but what the implementation guide needs to document.  And just to add insult to injury because a lot of you vendors have so irritated me on this subject, PA-DSS requirements 1.1.4, 1.1.5, 2.1, 2.7, 3.1, 3.2, 4.2, 6.1, 6.2, 9.1,10.1, 11.2, 11.3, 12.1, 12.2, 13.1, 14.1 and 14.2 all reference the implementation guide and also reference PCI DSS requirements as well.  Similar language was in Visa USA’s PABP standard, so do not say that you were not aware of this requirement.

If vendors think their customers have no right to the implementation guide, think again.  On page ix of the PA-DSS Requirements and Security Assessment Procedures under Customers, bullet two states, “Configuring the payment application (where configuration options are provided) according to the PA-DSS Implementation Guide provided by the vendor” and reiterates under bullet three. “Configuring the payment application in a PCI DSS-compliant manner.”  Therefore, you vendors out there that believe your implementation guides are state secrets, you had better provide this document to your customers or your customers are going to be judged non-compliant with the PCI DSS because of your bullheadedness.

For all of the vendors that are providing implementation services to customers, on page viii of the PA-DSS Requirements and Security Assessment Procedures states under Resellers and Integrators at bullet two, “Configuring the payment application (where configuration options are provided) according to the PA-DSS Implementation Guide provided by the vendor” and at bullet three, “Configuring the payment application (or instructing the merchant to do so) in a PCI DSS-compliant manner.”  So, vendor’s consultants need to be following the implementation guide as well and they need to leave it behind for the customer to reference.

With that said, there are a number of PCI DSS requirements that your precious PABP/PA-DSS certification does not address.  The first is PCI DSS requirements related to encryption key management.  Yes, the PABP/PA-DSS covers this topic, but in the end, someone still has to mange these keys once the system is implemented at a customer.  In some cases, the customer is responsible for key management.  In other case, we have seen the vendor or another third party managing key management.  PCI DSS requirement 3.6 must be followed by whoever is responsible for encryption key management.  And if this is the responsibility of a third party, you had better expect to have the customer’s QSA investigate and assess how you are performing this requirement.

Then there is backup and recovery.  Requirement 3.4 requires that the PAN be encrypted even on backup media.  Unless your application software is also providing the backup and recovery functionality, I seriously doubt that you have any influence on this procedure.  So, you had better address this in your implementation guide.

And finally, so as not to be piling on the software vendors, there are PCI DSS requirements 6.1 (patching) and 6.2 (vulnerability identification).  For most vendors, they have little control over these, yet a majority of those vendors I have dealt with all claim that any questions regarding section 6 of the PCI DSS have been addressed by their PABP/PA-DSS certification.  Really?  I do not think that you even want to be responsible for these, but if you really do, you are more than welcome to them.  You are really only on the hook for 6.3 through 6.6.  And with requirement 6.6, one could argue responsibility is split between the vendor (code reviews) and customer (application firewall).

Thank you all for the soapbox.  I hope to get back on track soon.

Advertisements

2 Responses to “PABP or PA-DSS Compliance Does Not Imply PCI DSS Compliance”


  1. 1 PCI too
    August 19, 2009 at 8:45 AM

    Whoa, slow down there. No need to get snippy. Some of us “Vendors” are simply trying to get past this process as soon as possible. We know our applications are secure and do not store any sensitive data and find it ridiculous that we have to constantly re-iterate in our document what is already covered in the PCI-DSS docs.

    • August 19, 2009 at 7:38 PM

      Sorry to be snippy, but you are obviously one of those rare software vendors that actually gives a d@mn about your customers. Unfortunately, not all vendors are like you. And that was my point.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

June 2009
M T W T F S S
« May   Jul »
1234567
891011121314
15161718192021
22232425262728
2930  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,836 other followers


%d bloggers like this: