This is page 2 of:
PA-DSS Reduces Your Scope Less Than You Think
Not one of these is a valid reason to store cardholder data today. Communications are reliable and timeouts are infrequent. When you have a problem, re-swipe the card. If your acquirer loses your transactions and can’t reconstruct them from its own records, get a new acquirer. And if you think you are required to keep the data to process exception items, see Visa’s recent guidance, which makes the point that storing cardholder data is the acquirer’s job, not the merchant’s.
Today, the only way to tell if a payment application stores cardholder data is to ask the vendor. I personally wish the PCI Council would add a column to the PA-DSS listings to indicate which of the following three conditions exist: “Yes,” the app stores cardholder data; “no,” it does not; or “configurable,” meaning the merchant has the option. My suggestion does not require any change to the PA-DSS or the validation process, and it would not cost anything. Unfortunately, this change is not likely to happen anytime soon.
I raised the issue recently with a senior executive of the PCI Council. The response was that reporting this information was not a role that made sense for the Council. Instead, it should be “left to the market,” meaning it should be the merchants’ responsibility. I respect the Council’s position; it is a standards body, after all. But I wish its mission could also include making scope reduction a little bit easier for merchants.
Therefore, because “the market” will have to be responsible, I would like to encourage all those vendors whose application does not store cardholder data to shout that fact on their Web sites and in their sell sheets. Believe me, your customers and potential customers want to know this fact. You provide a merchant benefit that goes beyond PA-DSS validation. Merchants who want to minimize their PCI scope or qualify for a simplified SAQ can make a clear choice.
In the same way, software vendors who re-write their applications so they no longer store cardholder data should highlight the benefits of simplified compliance to their merchants.
Although the functionality of the payment application will be critical, whether that application also stores cardholder data should be part of your cost equation along with price and maintenance.
I want to make it clear that merchants may store electronic cardholder data. My professional opinion is that it does not make sense in most cases (“We always did it this way” is neither a justification nor a compensating control). But if a merchant wants to keep the data, it is permitted. Just understand the result is that you will have a new hobby: PCI DSS.
Did you ever get half the story? Have you ever had what a friend in Texas calls “one of them sales critters” rattle on about how they are compliant, while carefully ignoring the fact that their application increases your PCI scope?
What do you think? I’d like to hear your thoughts and experiences. Either leave a comment or E-mail me at wconway@403labs.com.
-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.