May 22nd, 2009 by Jamie Estep
PA-DSS, and you thought PCI was a mess!
Filed in: Fraud, Industry News, Merchant Accounts, My Favorite Posts | 24 comments
PA-DSS, is a security standard set for payment application developers, outlining security and auditing procedures for electronic payment applications. Software that falls under the PA-DSS envelope could include anything from a POS system to online shopping cart software. PA-DSS requires that a program be audited by a 3rd party and pass a series of security test and adhere to best-practices before it can be distributed. If it is not audited or fails any part of the audit, it cannot be used as a payment application.
Phase V – July 1, 2010
Phase V mandates the use of payment applications that support PCI OSS compliance, requiring acquirers, merchants and agents to use only those payment applications that can be validated as PA-DSS compliant.
Put this into perspective. There are currently millions of websites using paid and open source software for their online stores. Software like Oscommerce, Zen Cart, Magento, and others have millions of users. There are only 2, online store software packages that are PA-DSS compliant. If there is not a mass-movement to get software PA-DSS compliant in the next year, almost every single online store will be out of compliance and subject to fines, or being shut down. This is only a small part of the problem. There’s still thousands of retail businesses using older payment software and the cost of upgrading would be in the millions, assuming it’s even possible.
As written by Evan Schuman
“Essentially, this standard could cause merchants of all sizes in all industries to have to switch payment application vendors.”
Where the real mess begins…
There are currently about 40 companies certified to perform PA-DSS validation. The cost to certify a single payment application could be $100,000 or more if the application is extremely complicated. There is an additional “mandatory” yearly fee of $1250 just to be listed as a Validated Payment Application. Based on cost, and complexity, there’s not many shopping cart software providers that can come close to getting PA-DSS certified in the next year. Even then, that still leaves the open source solutions, which the majority of all ecommerce sites are using.
From Rick Wilson
“What about home grown and open source shopping cart solutions? What happens to them on July 1st, 2010. I asked this question to our auditor and his answer was telling, he said that “essentially if an application can’t be PA-DSS certified because it’s not developed by a single entity for example, then the service provider of that entity will need to become PCI Level 1 certified in order to keep offering that and be in compliance”.
Level 1 certification is nearly as expensive as PA-DSS certification, so don’t expect any relief from if you’re using a custom or open source solution. They’ve truly left no way out this time…
In conclusion…
We’re about to experience a payment industry nightmare potentially having the ability to halt commerce as we know it. If you thought that the $20 per month fee from your processor was bad, you’ll really hate the $50,000 bill when you go to get level 1 certified. If Visa takes the hard-line stance that merchants not using PA-DSS certified software get shut down, it’s going to get really ugly. The current focus of the processing industry is on PCI-DSS compliance and a slew of new fees and charges related to it. But, in about a year, we’re going to see the true fallout of implementing ineffective regulations without foresight into what it actually takes to adopt them, or whether they actually do anything. The only thing we got out of the congressional hearing on PCI is that congress thinks it’s not enough, and merchants think it’s way too much.
Houston, we’re about to have a problem!
Related reading…
PA DSS in One Easy Lesson…Sort Of
PA DSS Is Remarkably Misunderstood
PA-DSS and Ecommerce Web Hosting
Great post. I agree with the sentiment of your post – it is indeed truly one big mess.
We’ll see how things shake out over the next few months.
Roy / Magento
Actually, there is only one PCI PA-DSS certified e-commerce application (PDG Commerce). The other one has a note that is is not recommended for new deployments.
[…] Everyone involved in eCommerce needs to read this article below about PA-DSS. We all know about being PCI complaint, but in about a year or so it could get ugly in the land of eCommerce. This article from The Merchant Account Blog explains it a little better and explains what could happen. [Article] […]
Thanks for the post on PA-DSS – just a couple of comments…
First of all, I work for NetSPI, one of the few PA-QSAs (the 40 or so companies that can certify apps under PA-DSS). I suppose that I should get that out in the open right off the bat so you know where the comment’s coming from …
Second – I’m not one of NetSPI’s QSAs – I’m on the client management side of the house working with a number of our PA-DSS clients, so am heavily involved in our PA-DSS practice, but I don’t want to mis-represent the value of my opinion…
Your post is really very interesting and you are hitting on some really important points regarding a standard that a lot of people are only just beginning to realize is a pretty big deal. This can be a very confusing standard that is starting to have some far-reaching effects in the marketplace.
I did want to make a couple of points, however. Not of correction, but of clarification…
Comment #1:
The $100K number you mentioned is a very scary number and really not the reality for the vast, vast majority of organizations that are going to have to deal with PA-DSS (on the software vendor side.)
Larger companies that have many applications that are affected may certainly have a program in place that gets very large, but the vast majority of applications, when looked at individually, won’t be anything near that cost.
Please don’t mis-understand me – it’s not an inexpensive process (the level of work and detail required of our company in doing these assessments is intense – this is a very, very in-depth inspection of the application, the software company’s development practices, and all documentation); however, most individual applications that need to go through this process should expect to pay something well less than half of that number.
Comment #2:
After saying it ‘won’t cost that much’ I’m going to add something back in – the way the program is structured, applications may need to address ‘minor update’ attestations for releases that are less than a full revision update, but don’t impact the ‘payment’ portion of the application.
It’s not quite the same process as a ‘major release’, but just so people are aware….
Comment #3:
The quote you have in the post (from Rick Wilson) … The information that he was given is slightly confusing for me on a couple of fronts:
1) Anyone hosting ecommerce sites (and handling credit card information) is going to have to be a PCI-DSS compliant service provider – whether you are level 1 is going to be determined by # of annual transactions (or by choice)…. One of the requirements of PCI-DSS (regardless of level) is going to be that you are running PA-DSS (or PABP) applications or have implemented custom code that is PCI-DSS compliant.
and
2) I actually haven’t seen any ‘official’ guidance on dealing with open-source applications, but my gut would tell me that, in most cases, there is customization taking place with those open-source frameworks prior to implementation. That could mean that the applications would be considered ‘customized’ for a single user (i.e. the company implementing them). That would mean that the burden of proving that the application/implementation was PCI-compliant would fall on the company deploying, but that they could still pass PCI-DSS if properly written/implemented.
Sorry for the really long comment, but PA-DSS is something that is very confusing to a lot of people and when I read your post, I got excited to comment…
Have a good one!
Alex/NetSPI
Alex,
Thanks for the commenting. This definitely clears up some of my and others’ misconceptions about the PA-DSS.
We were looking at getting some software PA-DSS certified back when there were only 8 or so certified auditers, and the cost quoted to us with astronomical. It’s good to hear that the cost ‘can’ be quite a bit lower than what I stated.
Open source is one that I’m still very concerned about, not just in how unaddressed it currently is, but also in how many people it would affect very quickly. A lot of these smaller websites have a hard time grasping the idea of PCI, and PA-DSS adds something with a much larger scope in the mix.
We’ll see how all this gets addressed over the next year, but there’s definitely a lot of work to be done.
I’d like to add my 2 cents to this thread and include some interesting wording that Visa has included in their website (http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html):
“While the use of PA-DSS validated payment applications is recommended, a payment application NEED NOT BE included on Visa’s list of PABP validated payment applications or PCI SSC’s list of PA-DSS validated payment applications in order TO COMPLY WITH Phase 2, Phase 3 and Phase 5 requirements for use of PA-DSS compliant applications. ACQUIRERS MAY DETERMINE the PA-DSS compliancy of a payment application THROUGH ALTERNATE VALIDATION PROCESSES, which should confirm that payment applications meet PA-DSS requirements and should facilitate compliance with the PCI DSS.”
So, if you read between the lines, the wording gives the impression that Acquirers can perform their own assessments of the applications their merchants are using to detemine (and attest) that these meet (or do not meet) PA-DSS requirements.
Just thought I’d add this comment to spice up the thread.
I’m not sure that much more spice was needed but this definitely makes things more interesting.
That’s a painfully ambiguous paragraph on Visa’s PA-DSS description.
Q: To whom does PCI apply?
A: PCI applies to ALL organizations or merchants, regardless of size or number of transactions, that accepts, transmits or stores any cardholder data. Said another way, if any customer of that organization ever pays the merchant directly using a credit card or debit card, then the PCI DSS requirements apply.
(source: http://www.pcicomplianceguide.org/pcifaqs.php#2)
The important word in this answer is “direct”. Most online stores do not take credit card data themselves and therefore do not have to get certified at all!
Good post, I’d never thought of this before.
This might be useful, too, a concise list of popular e-commerce applications along with their PCI PA-DSS certification status: http://www.hens-teeth.net/blog/pci-pa-dss-certification-summary/
I agree that the whole situation needs to be straightened out but honestly PCI certs are the only game in town. I smell bean counters having a red-tape induced orgasm right now. I hope that something simpler presents itself in the next five years. Maybe we’ll move back to trading oxen and cattle, a shekel for you finest fatted calf Ishmael. 🙂
You make it sound like PA-DSS suddenly fell out of the sky. Visa instituted these mandates in 2007, and has been very public about them. But like most compliance issues, however, biz people don’t pay attention until enforcement kicks in. The reason for PA-DSS is because 7 out of 10 data breaches that happen at small merchants are done through unsecure payment apps; of which (you are right) there are many. Developers and merchants can find tons of free advice and information at http://www.knowpci.com
What about fraudulent credit card use?
“But like most compliance issues, however, biz people don’t pay attention until enforcement kicks in.”
That’s probably a pretty accurate statement (comment made by Chuck Phipps)…
However, most small business owners expect (perhaps naively) that their merchant account provider (or payment processor) is responsible to take care of all of these compliance details. They’re usually too busy putting out fires NOW, to worry about what may happen over a year from now.
I agree with you. It will lead to a big mesh.
[…] http://www.merchantaccountblog.com/7…pci-was-a-mess […]
So if we all comply and get a PA-DSS audit complete at great expense and in three years time fraud is still on the rise can we fine MasterCard & Visa? 🙂
Merchants processing payment transactions must be PCI DSS compliant. However, they are NOT required to use PA-DSS compliant applications.
If they do not then they must demonstrate that the payment applications they use are compliant with the PCI DSS which won’t need to do if the apps are PA-DSS certified.
Having said this, a merchant cannot use an application that would fail the PA-DSS (eg if it stored CVV2 permanently or stored CHD unencrypted) without compensating controls.
The long and the short of it is that PA-DSS is not mandatory but not having it is a major drawback for payment application vendors.
What you wrote here is not exactly true. People need to have a better understanding of the things they chooose to write about.
“If there is not a mass-movement to get software PA-DSS compliant in the next year, almost every single online store will be out of compliance and subject to fines, or being shut down. This is only a small part of the problem. There’s still thousands of retail businesses using older payment software and the cost of upgrading would be in the millions, assuming it’s even possible.” This is according to Visa: “Payment Application Security Mandates
On January 1, 2008, Visa implemented a series of mandates to eliminate the use of vulnerable payment applications from the Visa payment system. These mandates require acquirers to ensure that their merchants and agents do not use payment applications known to retain sensitive cardholder data (i.e. full magnetic stripe data, CVV2 or PIN data) and require the use of payment applications that are compliant to the PA-DSS.
While the use of PA-DSS validated payment applications is recommended, a payment application need not be included on Visa’s list of PABP validated payment applications or PCI SSC’s list of PA-DSS validated payment applications in order to comply with Phase 2, Phase 3 and Phase 5 requirements for use of PA-DSS compliant applications. Acquirers may determine the PA-DSS compliancy of a payment application through alternate validation processes, which should confirm that payment applications meet PA-DSS requirements and should facilitate compliance with the PCI DSS.”
This is half the problem…
Acquirers have no idea how to, nor the means to police the situation. This is exactly why we’ve all seen the emergence of the PCI compliance fee, that most level 4 merchants are now subject to. Even FDR added a PCI fee for non-compliant level 4 merchants. Many ISO’s charge an additional fee if their customer’s don’t use their prefered PCI scanning vendor…
I’ve worked with about 8 ISO’s related to the PCI mess, and none of them have any real idea on what PCI is, or who it actually applies to, or why we have it, or what it actually is.
They simply add a PCI compliance fee to their customer’s accounts because it somehow removes their liability from a data breach.
And Visa… Visa is so far removed from the situation that they have no idea what is actually happening on the merchants level. The whole situation is out of control…
Can this really be true? This would essentially kill ecommerce! Think of how many people use ZenCart, OSCommerce, Virtuemart. And even several of the commercial carts that would never be able to afford a 100k validation procedure. Are they trying to shut down the Internet or what?
> Are they trying to shut down the Internet or what?
I agree.
It seems that somebody wants to earn more money.
It seems that somebody wants to earn more money on this situation.
It is nightmare for ecommerce.
See pg11 of the PCI DSS (v1.2.1)document. It clearly states it is *NOT* a PCI-DSS requirement to use PA-DSS validated applications. The sky is really not falling.