Visa Raises The Bar For PA-DSS Applications And Vendors
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.
Do you want to know if the people who wrote your payment application have criminal records or whether your reseller actually knows this? What about implementing tokenization without paying for an expensive upgrade? Do retailers want to know that, too? Visa thinks so, and the company spelled it all out in its recently issued Top 10 Best Practices for Payment Application Companies.
This document should be required reading for retailers. Although it is aimed at software developers, resellers and system integrators, the document has just as much relevance for any merchant who uses a third-party payment application (which is just about all of them). What I hear Visa telling retailers is: “You should expect more than just a PA-DSS validation.” And the result is, everybody benefits, including smart vendors and resellers (who now have a basis to differentiate themselves) and their merchant customers.
The PCI Council’s Payment Application Data Security Standard (PA-DSS, and don’t ask me why it is hyphenated and PCI DSS is not) is a minimum standard. It is the Mendoza Line of application security in that it is designed only to “facilitate and support” PCI compliance. To be truly secure, you need to go beyond the requirements.
For example, using a PA-DSS validated application by itself does not make you PCI compliant. Rather, you still need to implement the application according to the vendor’s implementation guide (which is sometimes an issue when resellers are involved), and you have to implement it in a PCI-compliant environment. Remember, too, that PA-DSS does not address the application’s functionality. A particular application may or may not meet your needs; all PA-DSS says is that it is compliant when properly implemented.
Here are some of the more important Best Practices Visa recommends for software application vendors, system integrators and resellers, and why they matter to every merchant, too.
- Perform background checks on new employees. Wouldn’t you like to know that the programmer who built your POS system at least didn’t come from a criminal gang? The idea is to reduce the likelihood of your getting bonuses like a backdoor or malware with your payment application or suffering a data breach because customer support did more than just upgrade your system when they accessed it for maintenance. Because PCI Requirement 12.7 requires merchants to conduct background checks for their new employees, it seems only reasonable to ask the same of their application vendors.
- Train programmers in secure coding techniques. Programmers learn to program quickly and efficiently but not necessarily securely. Smart application developers already train their staff in secure coding techniques and/or send them to training (e.g., OWASP’s AppSec USA) so they won’t accidentally add vulnerabilities in their code.
-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.