PA-DSS Reduces Your Scope Less Than You Think
Written by Walter ConwayA 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.
I would like to compliment all payment application vendors who have gone beyond Payment Application Data Security Standard (PA-DSS) to upgrade their offerings so they no longer store any cardholder data electronically. These far-sighted vendors have succeeded in reducing their customers’ risk, improving security and, importantly, minimizing their customers’ PCI scope. It is a shame that not all application developers have gotten the message.
Although a payment application may be PA-DSS validated, that validation says nothing about whether it stores cardholder data. This seemingly minor issue actually is pretty important to the merchant running the software. The reason is that if the validated application stores electronic cardholder data, then it does not reduce the merchant’s PCI scope very effectively.
For larger merchants in this situation, you and your QSA still have to protect all that cardholder data sitting on your system(s). For smaller merchants who self-assess, storing electronic cardholder data means having to use Self-Assessment Questionnaire (SAQ) D with all 226+ requirements instead of one of the simplified SAQs. This can be an unpleasant surprise to those merchants with an anything-but-SAQ-D approach to PCI.
The problem arises when a payment application vendor focuses more on how it complies with PCI and less on how to reduce risk and simplify the merchant’s PCI compliance.
Merchants need to use only applications validated against the PA-DSS for a couple of reasons. First—and maybe we can stop with this one—Visa mandates it. If you use a packaged software application for payments, it has to be on the PA-DSS list or approved by your acquirer. The other reason is that when the application is installed according to the vendor’s PA-DSS Implementation Guide and in a PCI-compliant environment, you and your QSA don’t have to dig into the workings of the code; the PA-QSA already did that.
I still meet merchants who think either that PA-DSS is their silver bullet for PCI compliance (it isn’t) or that a validated application will automatically reduce their PCI scope (that is not the case, and the application may actually increase scope).
The problem is that the PA-DSS listing at the Council’s Web site says nothing about whether the application stores electronic cardholder data. Let me be clear that if the application stores electronic data—even for a fraction of a second—it constitutes storing electronic cardholder data for PCI.
Historically, applications would have stored data for a number of reasons. An application might write the data to a database for only a few seconds while waiting for an authorization response from the bank; after that, the data was erased. That way if there was a communication problem or the authorization timed-out, the application could resend the request. Other applications kept the data to help if the acquirer lost the merchant’s transactions for that day. With the stored data the merchant could presumably reconstruct the batch and not lose any transactions. Still other applications stored the data to help the merchant process refunds or chargebacks.
-Marc
February 24th, 2011 at 6:59 am
Strong second on extending the PA-DSS listings to include information relevant to persisting CHD after authorization.
I have a whole series of war stories about vendors flat out lying about whether their POS systems persist cardholder data after authorization.
In some cases we’ve had to dive into the databases themselves and print out what we find in order for the vendor representative to acknowledge that, well, yes, they do store CHD.
Even better are the vendor reps of a Validation Type 5 (persists CHD after authorization) POS system who loudly trumpeted that a number of his customers were “compliant at the SAQ-C” like that was a good thing, in order to assuage a new customers’ concerns about having to maintain SAQ-D compliance around the application.
It’s a really ugly mess out there.
February 24th, 2011 at 9:42 am
Good points Walt. I think more attention needs to be paid to Visa’s guidance. The acquirers have not been rushing to update their specs and usually send the PAN back to the merchant in the response message which is then encrypted and stored by the payment application. In other cases, the PAN must be sent back to the acquirer, post authorization, when doing adjustments such as tips. Payment application vendors may not be able to make much headway on the issue of stored cardholder data until the acquirers change. Perhaps Visa’s guidance should become a mandate.
I’ve said this before: it feels like we are just adjusting the deck chairs. If merchants respond to SAQ C, they still must comply with the full standard. Unfortunately, merchants most likely, and wrongly, get the impression they only have comply with the requirements listed on SAQ C. Doing so will still leave them open to vectors permitting memory parsers or key loggers to enter the CDE. Whether or not the payment application stores encrypted PAN is irrelevant at that point.
We need more focus on core security best practices such as implementing a managed hardware firewall to protect from external threats and deploying whitelisting and anti-malware applications to protect from internal threats. Pushing merchants to complete an SAQ isn’t improving the overall security position when we know merchants aren’t really doing most of what they are attesting to.