Tip

A new twist on PCI DSS: Visa's Payment Application Best Practices

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),

Requires Free Membership to View

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

The PABP Requirements

1. Do not retain full magnetic stripe or CVV2 data.
2. Protect stored data.
3. Provide secure password features.
4. Log application activity.
5. Develop secure applications. 6. Protect wireless transmissions.
7. Test applications to address vulnerabilities.
8. Facilitate secure network implementation.
9. Cardholder data must never be stored on a server connected to the Internet.
10. Facilitate secure remote software updates.
11. Facilitate secure remote access to application.
12. Encrypt sensitive traffic over public networks.
13. Encrypt all non-console administrative access.
14. Maintain instructional documentation and training programs for customers, resellers and integrators. (Source: Visa)

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:

  1. Develop all Web applications based on secure coding guidelines.
  2. Develop software applications based on industry best practices and incorporate information security throughout the software development life cycle.
  3. Follow change-control procedures for all product configuration changes.
  4. Disable or remove unnecessary and insecure services and protocols.
  5. 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."

For more information

Diana Kelley explains how organizations can use the PABP for application development guidance.

Take a look back at the key compliance events of 2007

Learn how to pass the application security requirements of PCI DSS Section 6.
A logical first step for enterprises is to check the lists to see if they are using validated applications (paying close attention to the "Application Version" in column three). In some cases, compliance may be as simple as upgrading to the latest version. Visa notes that many applications have been upgraded to remove vulnerabilities and data-handling practices that violate PABP, but not everyone has upgraded to these compliant versions. While taking this step may require nothing more than a few phone calls, upgrading to a secure version of an existing application may also be far more onerous, not to mention costly. However, because the PABP is essentially a delineation of specific implications of PCI-DSS, it would not seem to break any new ground as far as compliance is concerned. After all, an enterprise should not be able, in theory, to pass a PCI-DSS audit while using a payment application that is exposing card data in violation of the practices now spelled out in PABP.

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.

(Source: Visa)


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.


This was first published in January 2008

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.