For the many companies that process credit card payments, 2008 may shape up to be another year involving intense enterprise compliance efforts. To force more security into payment application development procedures, the Payment Card Industry Security Standards Council is in the process of adding a new provision to the PCI Data Security Standard (DSS), one based on Visa's Payment Application Best Practices (PABP). Visa's guidelines,...
however, should not come as a surprise to any company.
First introduced by Visa in 2005, the best practices spell out how payment application developers -- and their applications -- can meet the requirements of the PCI DSS. The PABP was moved front and center late last year by Visa's initiative to mandate compliance with its application best practices. The PCI Security Standards Council quickly endorsed the move. Soon, Visa's PABP controls will be anointed by the council as the Payment Application Data Security Standard (PA-DSS).
PABP: The controls
Divided into 14 requirements (see sidebar), the demands of the PABP can be mapped to specific requirements of the PCI DSS, as noted in Visa's documentation. In fact, Visa makes it clear that applications should already comply with these guidelines.
Perhaps the 14 PABP items are most striking in their obviousness, which speaks volumes about the relatively slow pace at which digital security has evolved in the retail environment. (When consulting for ICSA and later InfoSec Labs in the mid- to late-nineties, I distinctly recall exhorting nascent ecommerce sites to follow item nine's advice; indeed, all 14 items -- with the exception of wireless-- routinely appeared in recommendations that my colleagues and I were making to clients back then.) A survey of security professionals would likely conclude that the demands of the PCI DSS are not out of line with practices that banks, telecoms and pharmaceutical firms have largely accepted for many years.
As to the specifics of the PABP, the heart of the matter is perhaps the stark exhortation in item five: Develop secure applications. The PABP's five steps to achieving this goal are as follows:
- Develop all Web applications based on secure coding guidelines.
- Develop software applications based on industry best practices and incorporate information security throughout the software development life cycle.
- Follow change-control procedures for all product configuration changes.
- Disable or remove unnecessary and insecure services and protocols.
- Ensure that all Web-facing applications are protected against known attacks either by having all custom application code reviewed for common vulnerabilities by third-party experts or by installing an application-layer firewall in front of Web-facing applications.
The PABP drills down even further. Item 5.1, for example, urges companies to develop Web applications "based on secure coding guidelines such as the Open Web Application Security Project guidelines."
Visa is clearly warning folks that the industry cannot afford to fall victim to known vulnerabilities. In a press release, Visa Senior Vice President Michael E. Smith discussed the frustration of today's state of security, in which "some versions of software in use today are known to store the full content of the magnetic stripe, PIN data or security codes [rich fodder for creating counterfeit cards] contrary to Visa rules and the PCI Data Security Standard."
Criminals are targeting certain versions of software because of their known security gaps. The PABP initiative includes a public list of Validated Payment Applications and a non-public list of vulnerable payment applications. The lists are updated quarterly and made available "to merchants and agents through their respective acquirers."
Visa's three-year PABP implementation schedule
There is a five-stage, three-year timetable for implementation of the PABP initiative, laid out as follows:
Jan. 1, 2008: U.S. acquirers no longer allowed to sign new merchants that use known vulnerable payment apps.
Jan. 1, 2008: Processors on the Visa network (VisaNet) and their agents forbidden to not certify new payment apps to their platforms if they've been identified as vulnerable.
July 1, 2008: VisaNet processors and agents can only certify new payment apps to their platforms if they're PABP-compliant.
Oct. 1, 2008: Acquirers can only board new Level 3 and 4 merchants that are PCI DSS compliant or utilize PABP-compliant apps.
Oct. 1, 2009: VisaNet processors and agents are required to decertify all known vulnerable apps, including those published on Visa's vulnerable list. They must decertify any new vulnerable apps within 12 months of identification.
July 1, 2010: Acquirers must ensure their merchants and agents only use PABP-compliant applications.
While PCI DSS enforcement has been an issue in the past, those days are quickly coming to an end, and the consequences could be severe for those organizations that fail to incorporate the PA-DSS guidelines into their compliance strategies. As an example, Visa levied $4.6 million in PCI DSS fines in 2006, up from $3.4 million in 2005. New fines were added in 2007 for data storage violators as well. To avoid them, acquirers must provide confirmation that level 1 and 2 merchants are not storing full track, CVV2, or PIN data.
If your enterprise is one of those merchants, and you are still using a payment application listed as vulnerable under the PABP, you are likely to see renewed compliance pressure from your acquirer. That could translate into anything from a minor application patch to a major IT project, depending on the system changes you need to make to implement the upgrade. Hardest hit will be enterprises that don't yet have the full security infrastructure needed to meet PCI-DSS, such as individual IDs, strong passwords, log file analysis, secure remote access to applications, wireless security and encryption over public networks.
By providing enterprises with a clearer definition of "secure payment application" and listing the validated and the vulnerable, the PABP should make it easier to understand what compliance entails, but may not make it any less painful to achieve.
About the author
Stephen Cobb has nearly three decades of experience in computer audit, security and data privacy. A CISSP since 1996, Stephen published a privacy handbook for businesses in 2002. He co-founder two successful security startups, developing ground-breaking network security technology later acquired by Symantec Corp. When he is not speaking or consulting, Stephen is an adjunct professor of Information Assurance at Vermont's Norwich University, where he helped create the curriculum for the award-winning Master of Science in Information Assurance degree.