PA-DSS Reduces Your Scope Less Than You Think

Written by Walter Conway
February 24th, 2011

A 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.


2 Comments | Read PA-DSS Reduces Your Scope Less Than You Think

  1. jml Says:

    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.

  2. Ernie Floyd Says:

    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.


StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.