Visa Raises The Bar For PA-DSS Applications And Vendors

Written by Walter Conway
September 2nd, 2010

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


3 Comments | Read Visa Raises The Bar For PA-DSS Applications And Vendors

  1. Jonathan Rosenne Says:

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

  2. PCI Guy Says:

    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.

  3. Tom Mulder Says:

    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.


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.