Getting Your Site Up to Speed With PA-DSS Compliance

Remember the “Millennium Bug,” or Y2K scare, when we thought computer systems would come crashing down at midnight on Jan. 1, 2000? Direct merchants now have a fresh headache and new deadline to contend with: PA-DSS.

You have just 15 months to make sure the systems you use to process credit card transactions comply with the new Payment Application Data Security Standard established by the Payment Card Industry Security Standards Council (PCI SSC).

If your systems are not PA-DSS compliant by July 1, 2010, you can't meet PCI standards, and you'll be in danger of losing your merchant account — your right to accept credit card transactions. Ouch.

PCI compliance has been around for several years, but until recently it had all the earmarks of the Y2K scare: warnings of dire outcomes, but no major consequences for the non-conforming.

But last year, the PCI SSC announced this new component in the compliance equation. PA-DSS applies not to the merchants, but directly to the credit-card processing systems themselves.

PA-DSS represents specific requirements (see “Top 10 PA-DSS requirements” on page 38) that a system must meet if it is used in processing credit cards. An assessor approved by the PCI SSC must audit each and every such system, and assign a “pass” or “fail” to the application.

Those that pass will be put on an official list of PA-DSS-compliant applications. (The list is available at www.pcisecuritystandards.org.) If a merchant is using a third-party system that's not on that list on July 1, 2010, it is not truly PCI-compliant.

Are there any exceptions? If you have a homegrown system, or one that has been written for you on a custom basis by an outside developer, it is exempt from PA-DSS requirements. You only have to pass the PCI test.

The only other exception is for merchants using browser-based systems or thin-client applications on solutions hosted off-site (software as a service), with all data maintained on the hosted solution. But these systems themselves must be certified PCI-compliant, and merchants using them still need their own PCI certification.

MCompliance strategies There are, inevitably, a number of gray areas with PA-DSS and PCI DSS compliance. For instance, there's the way in which PA-DSS compliance is determined by qualified security assessors (QSAs) designated and approved by the PCI DSC.

A software vendor can approach several QSAs for preliminary discussions and select the one that seems most likely to approve its system. While no QSA will run the risk of disqualification — or worse — by fabricating compliance where it doesn't exist, one QSA could make a good faith assessment that differs in its conclusions from another QSA.

From the merchant's perspective, there is no difference: As long as a system is on the approved list, it doesn't matter how it got there. And indeed, no QSA is going to misrepresent a system that is clearly out of compliance; only those that come close but may use unorthodox security strategies could be “passed” when they should be “failed.”

Some of these will make use of “compensating controls,” which are workarounds permitted in PCI SSC compliance testing, but not allowed in PA-DSS testing. This difference is bound to cause confusion.

MTime and money Any way you slice it, though, PA-DSS is going to cost everyone more money than they would care to spend — especially now. Most software vendors will have to invest some tens of thousands of dollars (possibly more than $100,000) to get their systems to conform to the PA-DSS regulations, and from $2,500 to $30,000+ for a compliance audit.

To add insult to injury, there is an annual fee of $1,250 just to be put on the official list of compliant applications.

And only the latest version of a system is likely to be listed — although PA-DSS allows multiple version listings if the vendor wants to retrofit them. So a large proportion of the users of any given order management system — for instance, those running on older versions — may have to pay to upgrade to the compliant, listed version of the system.

Expense aside, there will be a rather daunting scheduling challenge to get all merchants upgraded in time.

Another gray area is whether a standard third-party system that has been highly customized for a specific user site is exempt or not. The official PA-DSS language is ambiguous here: “PA-DSS does apply to payment applications that are typically sold and installed ‘off the shelf’ without much customization by software vendors.”

Uh, how much is “much customization”? You could argue that the vast majority of enterprise multichannel order management systems are installed with enough customization to render them exempt.

MSystems and tokens Which systems are involved? This is more clearly defined by PA-DSS, although open to misinterpretation by vendors. Any system that captures, processes, stores and, most important, transmits or receives credit-card data must be certified.

This includes every multichannel OMS, POS systems and any e-commerce shopping cart module. If the e-commerce platform itself does not capture or store any credit-card data, it would not be included; if it does, it would.

Some system vendors are hoping that use of a third-party payment-processing module, operating off-site, will let them dodge the bullet.

That may be the case for e-commerce or browser-based solutions in which a third-party payment “widget” can be incorporated into the order processing screen or checkout process. But it's much harder to include this in a client-server application in a call center.

There's no point in capturing the credit-card data in the legacy system and passing it immediately to a separate module behind the scenes. The simple capture/passing activity — even if the credit-card data is encrypted — renders the order management system vulnerable to PA-DSS testing.

With most third-party modules, and sometimes within a system itself, part of the security strategy involves creating a unique data string “token” that represents the credit-card number. Once the encrypted credit-card data is passed along to the transaction processor, the merchant never has it again, using the token instead to refer to the data.

Tokenization can be set up by the transaction. This means that once the card has been charged for the order, the token no longer has a reference to the card information.

Or tokenization can be set up by credit card, meaning that the credit-card number can be referenced for follow-up activity, such as back-order cancellation or customer refunds. For catalogers and Web merchants, card tokenization is clearly preferable.

Continue on Page 2