Getting Your Site Up to Speed With PA-DSS Compliance

Apr 01, 2009 9:30 PM  By

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

Keep in mind that with data encryption, a system must support “key rotation” (to periodically refresh encryption algorithms) or “split keys” (which require input from two key holders for decryption) to be PA-DSS compliant, not just simple encryption or data masking.

MWhat you should do Contact your system vendors immediately to find out what they are doing to become PA-DSS compliant. As of early March, no OMS vendors were on the PA-DSS approved vendor list.

Ask when your vendors expect to be certified, and whether the version of the system the merchant is running will be included in certification. And if so, will there be any additional costs to the merchant? If PA-DSS compliance will require an upgrade, how much will it cost, and when can an upgrade installation or conversion be scheduled?

Most vendors are likely to be uncertified until early 2010. By then, if your provider is still not on the list, you’ll have little time to convert to another system by July 1.

So it behooves you to put pressure on your current provider to achieve PA-DSS compliance as soon as possible — and to secure your place now in the upgrade queue if an upgrade will be required.

If your compliance efforts go awry, you might be able to work with your provider to maintain your account if you can demonstrate steady progress toward compliance. So it’s better to do something, and have a process in place with your system vendor, than to do nothing at all.

Beating the clock: PA-DSS is a work in progress for the Security Standards Council, so there will likely be a crush of assessments in the first half of 2010. And there will probably be revisions of current mandates to clarify some of their ambiguities as assessors start dealing with the reality.

But one thing is for sure: Even if the Council is forced to move the deadline to a later date, coping with PA-DSS is going to be a major challenge that multichannel merchants will ignore at their peril.

Ernie Schell (ernie@schell.com) is director of Ventnor, NJ-based consultancy Marketing Systems Analysis.

TOP 10 PA-DSS requirements

  1. CVV or card validation codes must be encrypted, and not stored anywhere after card authorization

  2. Encrypt credit-card numbers everywhere

  3. Require secure authentication log-ons for system users

  4. Keep logs of all payment activity

  5. Maintain network security

  6. Maintain secure data communications

  7. Don’t store credit-card data on servers with Internet access

  8. Test all interfaces to other systems for meeting PA-DSS security standards

  9. Maintain instructional documentation for system use

  10. Maintain a PA-DSS Implementation Guide that documents how PA-DSS requirements are met for this system

ADVERTISER INDEX

Receive supplier information fast using Multichannel Merchant Advertiser Index

ADVERTISER PAGE PHONE WEBSITE
AccuData Integrated Marketing 18 800-732-3440 www.accudata.com
B&W Press 23 877-246-3467 www.bwpress.com
Blue Package Deliver LLC 3 651-773-0031 www.bluepackage.com
CCT Marketing, LLC 4 800-213-4144 www.cctll.com
Dydacomp 21 800-858-3666 www.dydacomp.com/mmm
Escalate Retail 39 888-777-6811 www.escalate.com/ecometry
FedEx SmartPost 11 800-GoFedEx www.fedex.com/us/smartpost
Global Response 12 800-537-8000 www.globalresponse.com
InOrder Enterprise Management System C2 888-667-7332 www.getinorder.com
iServe Direct Commerce Services 26 866-895-4379 www.iServeDCS.com
Lexis Nexis 36 866-818-0265 www.risk.lexisnexis.com/charge-back
MeritDirect C3 914-368-1000 www.MeritDirect.com
Millard Group, Inc. 29 603-924-9262 www.millard.com
NewPage 14 800-638-3313 www.Newpagecorp.com
NXTbook Media 30 866-268-1219 www.nxtbookmedia.com
PCS ProfitCenter Software C4 888-446-6240 www.profitcenter.com
Ripon Printers 17 800-321-3136 www.riponprinters.com
U.S. Monitor 33 800-767-7967 www.usmonitor.com
Walter Karl, Inc. 6 845-620-0700 www.walterkarl.com
William-Neil Associates 32 800-846-8902 www.william-neil.com
MCM NCOF SUPPLEMENT 2009
24-7 InTouch N2 800-395-8301 www.24-7intouch.com
ACCM 2009 N5 www.accmshow.com
Blower Application Company N4 800-959-0880 www.bloapco.com/rungreen
Chicago Tag & Label, Inc. N7 800-826-8260 www.chicagotag.com
Dydacomp N11 800-858-3666 www.dydacomp.com/mmm
Endicia N12 800-576-3279 www.endicia.com/mcm