Fighting Vulnerable Payment Applications

By  Seth Peter, chief technology officer, NetSPI
Until recently, many payment applications lacked good security features like encryption and key management. That situation is changing with the codification of VISA's Payment Applications Best Practices (PABP) into the industry-wide standard known as Payment Application Data Security Standard (PA-DSS). Under the PCI umbrella, PA-DSS aims to eliminate payment applications that are vulnerable to cyber-thieves and ensure that all payment apps conform to the PCI DSS. The new standard does impose some burdens on retailers, but it also has some good news.

For one thing, PA-DSS applies specifically not to retailers but to the third-party payment software vendors. That is, it concerns payment apps that are sold or licensed to others to use. Some retailers have chosen to develop or customize their own applications; these businesses are then responsible for demonstrating that the various elements of the application - encryption, key management, auditing and logging, access and authorization, conducting security code reviews, vulnerability identification, and security testing all software updates - all pass muster with the PCI standard, not PA-DSS.

But suppose you are a merchant looking to buy a new POS payment application, not develop a home-grown one. With PA-DSS in place, the burden of validating the application falls on the vendor, not you. You will need to buy and properly implement a compliant application; however, the application vendor has to do the heavy lifting of compliance work, which includes creating an application that:

- Does not retain full magnetic strip, card validation values, or PIN block data.
- Encrypts or obfuscates cardholder data.
- Provides robust secure features.
- Appropriately logs all payment and application activity.

In addition, the application vendors must demonstrate they have appropriate business processes in place to ensure their software is created and maintained with bulletproof security.

Some Caveats
It is important to note that retailers are not completely relieved of responsibility under PA-DSS. For one thing, the job of demonstrating proper network segmentation and monitoring and logging of card activity is NOT offloaded to the developer. Retailers should also know that many software vendors are electing to validate only the most recent version of their applications. This saves them time and money in going through the validation process. And perhaps not coincidentally, validating only the current release of their software also serves as a way to speed up the purchase cycle for their products.

There is another potential problem retailers need to be aware of: PA-DSS applies not only to pure-play payment applications but also to any software that stores, processes, or transmits cardholder data, including code that integrates with ERP modules and management software for parking lots, hotels, pharmacies, and kiosks - anything that handles card transactions.

Some Important Dates and Trends
Visa, as part of the overall PCI compliance drive, specifies certain milestones for payment application compliance. For example, as of October 1, 2008, Visa acquirers are not to accept new level 3 or 4 merchants that use non-compliant payment applications. And acquirers have until July 1, 2010, to ensure that all their merchants and agents are using only PA-DSS-compliant applications.

Driving Industry Trends
Finally, the PA-DSS standard is encouraging some favorable industry trends and driving creative and effective strategies for risk mitigation in order to minimize PA-DSS concerns for software vendors - and ultimately for merchants. One trend is to move the payment application off the POS to a separate, hardened device. Another is to reduce the transaction data that is saved. Both of these strategies can greatly reduce PCI's scope within the merchant environment, reducing the cost and time needed for demonstrating compliance.

Seth Peter is a founder and the CTO of NetSPI, a consulting firm that provides risk management and security program assessment. Seth has worked with both national retail organizations and with developers of payment applications. He is a Payment Card Industry Qualified Security Assessor and Payment Application Qualified Security Assessor.