I got the following comment regarding open source solutions.
“Is it correct to assume that open source e-Commerce solutions like Magento Community, VirtueMart, Ubercart, Zen Cart, etc. will never be PA-DSS compliant since, by their very nature, they are modifiable and extensible via plug-ins?
Does it mean that a commercial e-Commerce solution will need to be “locked down” with encrypted code to be PA-DSS compliant?”
Now before all of you open source “bigots” out there send me tons of nasty comments and flame mail, keep in mind that I am a big fan of open source code and rely on a lot of it in my network security practice. The problem is not with open source solutions but with the practices used to create those solutions that typically create the compliance issues with the PA-DSS. I am not implying that these issues cannot be overcome. Just that given the state of open source at the moment, I just do not see these issues being overcome in the near future. That is not to say that open source solutions cannot be used for payment processing. It is just that they will need to be individually assessed as part of the merchant’s PCI Report On Compliance (ROC) assessment process.
Let us remind everyone about the 14 points that the PA-DSS covers.
- Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data
- Protect stored cardholder data
- Provide secure authentication features
- Log payment application activity
- Develop secure payment applications
- Protect wireless transmissions
- Test payment applications to address vulnerabilities
- Facilitate secure network implementation
- Cardholder data must never be stored on a server connected to the Internet
- Facilitate secure remote software updates
- Facilitate secure remote access to payment application
- Encrypt sensitive traffic over public networks
- Encrypt all non-console administrative access
- Maintain instructional documentation and training programs for customers, resellers, and integrators
In my opinion, none of the aforementioned solutions will ever likely be PA-DSS certified. Here are the highlights of my rationale for that assessment.
Requirement 5 – develop secure payment applications is where I think the majority of the issues with PA-DSS certification occur. Requirement 5 deals with the development practices used to develop the solution. The problem here is in the PA-QSA reviewing all documentation, interviewing the developers and observing elements of the development process.
Open source documentation is typically only available online and can be very spotty at best. Usually the focus is on installation and basic operation. The PA-DSS and PCI DSS require documentation on how to properly install the solution so that it complies with the PCI DSS. Documentation for open source solutions that I have evaluated have not included such information.
One of the biggest stumbling blocks for open source solutions will be in documenting the system development life cycle (SDLC) that is used. In my experience, while documentation on the application can be scarce, documentation on the development life cycle typically is non-existent with open source. As a result, it will be impossible to get around the requirement of an SDLC.
Then there is the whole process around change control. How changes are managed from the initial request through implementation is a big part of the PA-DSS assessment process. These communities usually do not have a change control process that can be audited let alone meet the rigor required by the PA-DSS. There is also the question of who approves the changes. These open source solutions usually do not have a documented organizational structure, so who is the person that approves the changes for development, approves the changes for production?
As with change control, testing is another big part of the PA-DSS certification process. While open source communities conduct testing before releasing their products, the testing they perform is usually not documented in a way that it would meet the requirements of the PA-DSS assessment. Testing also requires documented approvals, so the issues with change control approval exist with testing.
While all of these requirements can be met with compensating controls, without a control environment to start with, just how one would develop compensating controls is a big hurdle to overcome.
Besides the problems in meeting Requirement 5, here are some other items that I also think preclude a PA-DSS certification for open source solutions.
Who would be the organization of record that certifies the application? Most of these open source projects and communities do not exist in a legal sense. As a result, they technically cannot legally represent the application in question which is required for PA-DSS certification. And for those instances where there is a legal entity, would such an entity be willing to assume the risk entailed in certifying their solution?
Then there is who would pay for the certification? Most of these projects and communities exist on the goodness of the people who devote their time to the software solutions in question. There is little if any money involved and it would be difficult for most to raise the kind of money to pay for a PA-DSS assessment. For those of you wondering, most PA-DSS certifications cost at least $30,000 or more depending on the complexity of the application and the number of platforms involved. When you are structured like most open source projects, such an amount of money is daunting to raise.
And finally, assuming that your open source solution gets PA-DSS certified, how would you know that your version of the open source is untouched? . This basically means that the solution now needs to be distributed in a secure manner. So, the community will need to have a known, secure distribution point for the software, not distributing it from any outlet that wants to provide it for downloading. Yes, you can use MD5 or similar hash algorithms to confirm that the version is the correct, certified version. However, given the requirements of the PA-DSS regarding distribution of the solution and any updates, open source communities will have to invest in a bit better distribution system.
The bottom line is that the PA-DSS is skewed to commercial software, not the open source community. That is not to say that open source solutions will not get certified as I believe there may be some that do get certified. I think what you will see is organizations spring up that offer a certified version of the open source solution but you will have to purchase that version, you will not be able to download it for free. Very similar in concept to how Red Hat and Novell operate with their versions of Linux. However, based on the current certification process, in my humble opinion, PA-DSS certified open source solutions will be the rarity not the rule.
PCI Guru 
As I understand it PA-DSS and PCI-DSS is only an issue if the shopping cart software is handling credit card data, ie card number, expiry date, security code. If the shopping cart software utilises a third party secure payment gateway eg Paypal, or SagePay Forms integration then it is only transmitting the customer’s name, address, payment value and order details so should then does not need auditing and certification, is that correct?
When using an iframe integration, even over an encrypted SSL connection, it most likely becomes a different matter, and almost certainly if using a tokenization integration.
If, at a minimum, cardholder name + primary account number (PAN) + expiration date are entered and transmitted by an eCommerce site, then it must comply with the PCI DSS and any other relevant PCI standards.
In your examples of PayPal and SagePay, the actual credit card data is stored away from the actual transaction process, so the payment from the shopping cart would not be in-scope for PCI compliance because no cardholder data (CHD) is processed, stored or transmitted. Similarly, in those instances where a completely separate window/dialog box is spawned that is connected to an entirely different server hosted by a payment processor such as Barclay’s or CitiBank, that would also not be in-scope for the merchant’s PCI SAQ/ROC because the merchant is not responsible for that solution.
When the merchant does host the payment solution as either their own iFrame or in the repost scenario, the merchant’s servers could be compromised leading to the compromise of the payment processing solution which is why those payment methods end up in-scope for PCI compliance.
However, with the network segmentation clarification at this year’s PCI Community Meeting (i.e., “connected to and connected to”), technically, even using a third party source could bring the merchant’s eCommerce solution back into scope if the connectivity between the merchant and third party could lead to a breach of the third party.
It all comes down to WHO processes, stores or transmits the CHD and if that entity is physically or logically segregated from the merchant.
Zen Cart 1.5 is now PA-DSS certified…
Look it up: https://www.pcisecuritystandards.org/approved_companies_providers/validated_payment_applications.php?agree=true
The other options to “outsourcing” the payment processing to PayPal or Google is to go with a PCI compliant hosted shopping cart such as CoreCommerce, or if you want to “self-host” use a PA-DSS compliant shopping cart like PDGSoft.
Great options for the retailer that only does e-Commerce, but not very helpful for a traditional, brick & mortar operation. Everyone points to the “cloud” for traditional retailers, but as I explained in my post on that subject, the cloud is not necessarily PCI compliant nor can it always be made PCI compliant.
Well…talking about rarity
Zen Cart 1.5.0 is PA DSS certified. Go to list of PA DSS certified applications.
Perhaps is not the best looking opensource platform but put some work in to design and it will rock your store 🙂
Hope it helps
Regards
Webdesigner0
At the DrupalCamp Colorado conference this June, the presenter Rachel Mackrucki stated that according to the advice her organization received from their QSA (Coalfire Systems), open source GPL licensed software was exempt from PA-DSS licensing requirements.
However, GPL licensed ecommerce solutions would be treated the same as “in-house” developed solutions meaning that they would still need to make sure they don’t break the broader PCI guidelines. That makes a certain amount of sense I think.
So there might be some practical difficulties in documenting certain development practices given the nature of community based open source code, BUT there seems to be nothing stopping website owners from using GPL ecommerce PROVIDED that the other PCI conditions are met.
Would you concur with that?
Rachel’s presentation here:
http://www.dogstar.org/drupal/content/drupalcamp-co-pci-compliance?utm_source=twitterfeed&utm_medium=twitter
Thank you for the link to the presentation.
The fact that DRUPAL is covered under GNU General Public License (GPL) means nothing regarding PCI compliance and specifically means nothing regarding PA-DSS certification. However, as Ms. Makrucki points out, you are required to make sure that the open source solution is PCI compliant by reviewing the code and testing it in detail to ensure that it operates as designed. The problem with that is that most organizations do not have the expertise to perform such a detailed code review and the requisite testing to ensure that things operate as expected. As I stated in my post, open source software is likely not able to be certified because all of the requirements of the PA-DSS are difficult, if not impossible, to accommodate because of the nature of how open source is developed and maintained. Using open source can be PCI compliant, but merchants need to understand that their QSA will need to conduct much more work because of the open source solution which may make the solution not as cost effective as the merchant thought.
Thanks for the prompt reply.
Since watching the slide show I’ve seen a few things online which tend to support what you say and also make me believe that open source GPL solutions ARE also required to be PA-DSS certified, every bit as much as commercial ones.
1) I’ve followed some online dialogue in the Zen Cart community where core project members have indicated that Zen Cart is “currently undergoing the PA-DSS assessment”, whatever that means. In any case I’ve seen no statements from the team to support the conclusion that Zen Cart is exempt. http://www.zen-cart.com/forum/showthread.php?t=157332&mode=linear
2) The PCI FAQ themselves.
Q: What constitutes a payment application?
A: What constitutes a payment application as it relates to PCI Compliance? The term payment application has a very broad meaning in PCI. A payment application is anything that stores, processes, or transmits card data electronically. This means that anything from a Point of Sale System (e.g., Verifone swipe terminals, ALOHA terminals, etc.) in a restaurant to a Website e-commerce shopping cart (e.g., CreLoaded, osCommerce, etc) are all classified as payment applications. Therefore any piece of software that has been designed to touch credit card data is considered a payment application.
http://www.pcicomplianceguide.org/pcifaqs.php#15
The fact that an official PCI document specifically mentions osCommerce (an open source solution) seems pretty conclusive.
Until we see what PA-DSS 2.0 specifies, card terminals were exempt from PA-DSS and PABP compliance because they were considered “dumb” terminals. I have argued repeatedly that this was not a good decision and apparently the PCI SSC and the card brands agree as they are changing the PA-DSS and coming up with criteria as to when card terminals need to be PA-DSS certified.
I’m sorry to drag up an old point here, but from the PA-DSS:
– PA-DSS does NOT apply to payment applications developed by merchants and service providers if used only in-house (not sold, distributed, or licensed to a third party), since this in-house developed payment application would be covered as part of the merchant’s or service provider’s normal PCI DSS compliance.
I don’t see how free (no cost, not sold) and open source code would ever need to be certified under the PA-DSS in the first place. It’s just another homegrown application that would need to be a part of the merchant’s PCI-DSS procedures.
(For what it’s worth, cost isn’t always the with with open source. I like to say that it’s free, like kittens are free)
The PCI SSC and the card brands define open source as a commercially available solution and therefore covered by the PA-DSS. Their rationale is that open source solutions are developed by third parties, not in-house, and therefore are covered by the PA-DSS. That is not to say that open source MUST be PA-DSS certified, it is just recommended. Some card brands have mandated that merchants only use PA-DSS certified software and since that was Visa and MasterCard, that pretty much means that payment applications have to be PA-DSS certified.
For E-Commerce, handing off to a payment gateway (i.e. a hosted checkout page) is the way to go, but I know for a number of clients I’ve worked with in the past, this is not an acceptable solution. There is a noticeably higher order abandonment rate once you go a hosted payment page other than Paypal. A lot of shoppers then think twice that this is some kind of “unprofessional” or fly by night operation regardless of the fact that it is probably safer for the end user.
We’re dealing with this on the Point-of-Sale side of the house. The equivalent of hosted e-commerce pages would be a hardware swipe terminal separate from the POS. However, again, this is not what people that use the software want. They want the integrated package and don’t care about openness.
Great points! I think you’ve hit the nail right on top of the head. Open Source is known for playing loose with code and the databases due to the ability of programmers of all levels being able to make changes that affect the application.
I think the cost of a QSA to come and evaluate was going to be the biggest hinderance but I believe that those open source projects that try will be hit with the issues you’ve discussed her.
Again, great post!
I think it is more likely that open source programs will steer towards integrated gateway payment solutions, such as some of the newer implementations allowing iFrame support, which can actually appear quite seemless, giving the buyers a similar buying experience to an integrated solution. Biggest bonus of all? This makes PA-DSS a non-issue.
Cheers