Back
Common Compliance Hurdles Part 2: Non-compliant Applications
In this, the second installment in a series discussing common PCI compliance challenges, I address non-compliant payment applications. Such applications are nearly ubiquitous in the cardholder data environments of smaller merchants (and even some of the larger ones). However, merchants that store cardholder data are rarely able to attain a compliant state when using an application that has not been validated as compliant with PCI standards (either the older Payment Application Best Practices, or PABP, and the newer Payment Application Data Security Standard, or PA-DSS). In particular, compliance with much of PCI DSS Requirement 3, which deals with protection of stored cardholder data, is difficult or even impossible for these businesses, in many cases due to their payment application(s). Typically, such merchants have three options: migrate to a validated solution, work with the vendor of the current application and encourage them to have the application validated, or implement the required controls themselves. Because these applications pose such a high risk to cardholder data, Visa has mandated that all merchants will be required to use validated payment applications, with a deadline established for July 2010 in the U.S. and Canada and July 2012 for other regions. In the meantime, there are several things a merchant can do to meet DSS requirements, the Visa mandate notwithstanding. In most situations, the best solution is to change the payment application and implement a solution that has already been validated. While this can be a daunting task, especially for larger or distributed environments, it is typically the solution with the most immediate payoff in terms of compliance, especially considering the impending Visa requirement. Chances are good that, if the current application has not been validated, there is a similar application that has been. By migrating to an application that has already been validated, and configuring systems to the standards outlined in the application’s implementation guide, merchants find compliance with DSS requirements much easier. If moving to a different solution is simply not feasible, though, merchants should pressure payment application vendors to attain PA-DSS compliance by having the application validated by a PA-QSA firm (see https://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf). Such a process can take quite a bit of time, which would delay the merchant’s ability to validate PCI DSS compliance. Also, modifying the application can also be expensive for the vendor. However, vendors of these applications should keep in mind that their customer base needs to attain and maintain compliance and it will become increasingly difficult to market and sell non-compliant payment solutions (see https://usa.visa.com/merchants/risk_management/cisp_payment_applications.html). If a payment application vendor is unable to meet compliance with PA-DSS requirements, merchants may be able to implement a number of controls to meet the PCI DSS requirements. Exactly which controls need to be applied will vary depending on the application, but some key areas can include eliminating storage of sensitive authentication data, obfuscating stored primary account numbers using encryption, hashing, truncation, etc., PCI data discovery on payment systems and servers, increased access controls and logging outside of the application, and implementing key management processes and technologies. Essentially, the payment application would be treated as an internally-developed application, and the merchant would be responsible for ensuring all controls are in place to protect cardholder data. In many cases, the cost of implementing these controls will outweigh the cost of changing payment applications. When considering these options, merchants should ask an additional question: “Do I actually need to store cardholder data?” In many cases, smaller merchants can be forced to complete the lengthy Self-Assessment Questionnaire D due to the fact that a single application or point-of-sale stores credit card data. These merchants should note that slightly altering their business processes and replacing such a system with one that does not store cardholder data can pay dividends, as compliance requirements would be drastically reduced.
