This is page 2 of:
Visa Raises The Bar For PA-DSS Applications And Vendors
Visa makes no claim that these are the only Best Practices vendors should follow or that they cover everything. Therefore, I would like to suggest adding a couple more items to the list.
I would like to see vendors state explicitly whether their POS application stores cardholder data, even if only briefly (e.g., during authorization). Too many merchants mistakenly believe that because the payment application is PA-DSS validated, it does not store electronic cardholder data. Some smaller merchants are under the mistaken impression that using a PA-DSS application will automatically qualify them to use a simplified Self-Assessment Questionnaire (SAQ). Unfortunately, PA-DSS validation only means the application is compliant, not that the application does not store cardholder data.
Another Best Practice I would like to see on the list is to provide training for customers, too. That is, I agree that all vendors should provide secure implementation and use training for installers and resellers, but how about encouraging those vendors to provide that knowledge to the customers, as well? (Note: The golf can be optional.)
Visa didn’t develop its Top 10 Best Practices out of altruism. As the company states in the document, “Recent payment card data compromises have demonstrated the critical need for payment application companies to maintain mature software processes for their customers that go beyond PA-DSS compliant software.”
Smart vendors know this, and they already go beyond PA-DSS. They implement internal practices to maintain their own security and support their customers during implementation and afterward. My guess is that with this document, Visa is trying to make good software vendors, integrators and resellers better, while raising the bar for those that may need a little, let us say, encouragement.
Every retailer evaluating or considering a POS software application should read this document carefully and apply it to their procurement decision process. On a related note, I would like to see every processor and acquirer have their account reps send it to each of their merchants. Because acquirers and processors are ultimately responsible for their merchants’ PCI compliance, anything that will help merchants–especially small and midsize businesses–be secure benefits everyone.
Some good news for application vendors is that Visa is working with the SANS Institute to develop a series of training courses targeted at helping vendors meet its Best Practices. I’m sure the courses will cost something, but at least vendors are not being left on their own to implement Visa’s suggestions.
What do you think? I’d like to hear your thoughts. Either leave a comment or E-mail me at wconway@403labs.com.
-Marc
September 3rd, 2010 at 9:34 am
“Programmers learn to program quickly and efficiently” – I would say “Programmers learn to write code quickly and profusely”. Leaning to program isn’t so easy. One of the payment application problems is precisely this – the programmers do not know how to program.
September 3rd, 2010 at 6:28 pm
Visa’s new PA-DSS Best Practices guidelines will place vast new burdens on vendors and merchants, with very little gain in card data security, and leaves at least one oceanliner-size loophole that benefits–guess who! Visa themselves.
Consider background checking employees, for instance: I doubt Visa can point to even a single incident where any software developer–with or without a criminal record–deliberately introduced a vulnerability that resulted in a compromise of card data. And a “clean” background gives no assurance an employee will not “go bad.” If anything, relying on background checks might lend a false sense of security. Code reviews and third-party audits (already a part of the PA-DSS) are the appropriate mechanisms to prevent such exploits. But Visa’s attitude seems to be, “What the heck! Let’s put background checks on the list anyway, it doesn’t cost Visa anything!”
And just exactly what specific transgressions does Visa feel should disqualify someone from being allowed to work on payment applications? Drug use? Bad grades in school? Car theft? Writing bad checks? Bankruptcy? Homicide? Perhaps the PCI Council will someday create a list for us but, given their historic torpidity, that seems highly unlikely.
Aside from those background checks being essentially useless, many good people object to such ham-fisted trampling of personal privacy. Apparently, that does not include the folks at Visa.
Even if you don’t give a hoot about privacy, there are some major land mines in the new guidelines: Vendors of PA-DSS validated products must “Implement an installer, integrator and reseller training and certification program that enforces adequate data security processes when supporting customers” to “ensure that customers are not being exposed to data compromise due to poor implementation, maintenance or support processes employed by internal installers, independent integrators or resellers.”
Wow! What a colossal burden for everyone involved! Just think of all the employee time that will be spent attending training classes in order to obtain “certification” required to install, integrate, or even resell a PA-DSS validated product. (“Enforces” is a wonderful word there, too.)
But wait! There’s more: “At minimum, installers, integrators and resellers must certify to these data security requirements through an internal vendor program requiring quarterly reports, which include employee training, certification and ongoing compliance to the requirements.” Quarterly reports! Are you kidding me? Leave it to the bureaucrats at Visa to come up with something like that. What data are those reports supposed to provide, exactly? And to whom will they be submitted? And what is the receiver supposed to do with them?
A major loophole concerns transaction gateway providers. Under the new guidelines, if a merchant creates a software application and uses a PA-DSS validated middleware product (such as PCCharge or ICVerify) to route transaction data to the processor, then the middleware provider must “enforce” certification requirements on the merchant’s technical team. But that’s not true if the merchant uses a transaction gateway service (such as, say, CyberSource) for routing those transactions. In that case, no one needs to attend any training classes, and their application software could be riddled with security vulnerabilities due to “poor implementation, maintenance or support processes employed by internal installers, independent integrators or resellers.”
Oh, by the way, did you see the recent news? Visa just bought CyberSource for $2.0 billion. I think I now understand how they plan to recoup that investment. This smells like an antitrust issue to me.
These new Best Practices guidelines are a gross over-reaction to the 2009 breach of Radiant/Aloha POS systems in Louisiana. The problem in that case appears to have been caused by the installer leaving passwords set to their default values. A much better way to address that problem is by updating the PA-DSS to prohibit software from operating until default passwords are changed. A surgical correction like that would do a lot more to improve security, without imposing millions of dollars of additional burden on merchants and vendors.
September 10th, 2010 at 2:38 pm
One again I see Visa pushing the ultimate responsibility for their Cardholders down to the 2 players that have the least ability to deal with it… The retailer and the Software Provider. I have asked many times “who’s problem is PAN data, Card Bands/Issuing Banks or the Merchant/Software Provider?” In the card brand’s mind it is the latter, however, in my mind it is them! They should have a program that has their data encrypted on the card and then have the MSR encrypted it again. That way no matter where the data goes it is always encrypted. Of course this only really works for card present environment and maybe we should never allow manual keying of card numbers in these environments. As for card not present environments, maybe the card brands should provide a smart phone app with a rolling account number for those transactions.
Why has this best practice not been adopted by the card brands, I suspect that it is due to cost and time. It is cheaper for them to use their monopolistic world to force us to deal with their problem. They have the contract with the cardholder to provide a secure and safe environment to use their card. The rest of who accept the card should not be held responsible for their lack of security measures to ensure their customer’s information is safe and secure.
The card brands are in a much better position with their bank members to facilitate security. After all they already have vast IT staffs that focus on nothing but security whereas software vendors focus on selling points that are related to many other aspects of retailing that have nothing to do with payment processing. I am not saying that a software providers should not have to be aware, but the fact that they have to deal with PAN data in clear text because the current processing environment cannot take encrypted account data during actual authorization is the real problem. In reality, no one outside of the issuing banks and their customers should ever know the actual account number.