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 