PABP: Developing Secure Commerce Software
Perhaps it is best if I start this entry with a disclaimer.
<disclaimer>
I am not, and do not pretend to be, a security expert. If you need the advice and assistance of a Qualified Security Assessor (QSA) or other security firm specializing in compliance, they are listed on both the Visa and PCI Security Council Websites. (For example, Coalfire Systems and Trustwave.)
</disclaimer>
With that said, due to the position of IP Commerce in the industry, I do have more than a passing familiarity with the subject matter and methods to address it.
So, what is Payment Applications Best Practices?
- Soon to be PA-DSS
- Explained in great detail at http://www.visa.com/pabp
I tend to think of PABP as requirements that are tightly aligned with PCI. The main difference is that PABP focuses on secure software development while the PCI focuses on secure operation of payment systems. If you read the PABP document provided by Visa, it lists the detailed requirements for 14 categories of ensuring commerce software is secure. Highlights are:
- Don’t retain mag stripe, card validation, and PIN data.
- The data that can be stored must be protected.
- Manage users and passwords in your application.
- Log application activity.
- Have an SDLC that promotes secure development.
Quite the list. PABP is not only about the code, it is about the way in which the code was developed and is updated. More importantly, particularly considering recent news, addressing PABP issues now is to the benefit of the software company and the merchants the company supports.
How is it done? There are several methods but, ultimately, it requires that the business interact with a "Qualified Payment Application Security Company" (QPSAC, lengthy, eh?) in order to be have the software tested and certified as compliant.
Fortunately, there are ways to simplify the process. . .more on that tomorrow.
What’s your perspective? Anything to add?
The comment form is below. . .
(seat 9E on a flight from DFW to DEN)
November 9, 2007