One of the questions we received at the last PCI Dream Team session was:
“What about open source for 6.5?”
I am sure the person asking wanted to know whether open source payment solutions must comply with the PCI DSS requirements in 6.5.x?
The quick and simple answer is of course, ‘Yes’! Why would it not? It is source code after all, so therefore it must comply with the requirements in 6.5.x (as well as other requirements in section 6 and throughout the PCI DSS). The PCI DSS does differentiate between different sources of application code. For PCI compliance purposes, code is code is code, regardless of the source.
Now what does come into play is whether or not the PA-DSS validation standard applies to an application. As PA-DSS relates to open source, I wrote about that over eight years ago, but it is still relevant today. For the purposes of this post, I am not talking about PA-DSS validated applications.
The next question a QSA typically gets is, “Well 6.5 only applies to internet-facing payment applications, right?”
Wrong! Any payment application needs to meet the requirements in 6.5.x whether it is internet-facing or internal facing. Also, it does not matter whether a browser is involved or not although a significant number of the requirements in 6.5.x are related to browser-based applications.
But ensuring open source is PCI compliant goes beyond just 6.5.x. There are other requirements that, at a minimum, must be applied as well. Not every requirement in a section or group or requirements may apply, but some will be needed to be covered depending on how the application works.
- Section 3 related to encryption of stored data and encryption key management;
- Section 4 related to encryption of communications;
- Requirements 6.1 and 6.2 for patching and vulnerability management. This can become problematic for open source because as time goes on applications can develop vulnerabilities that the developer community does not address. This is most likely because the community moved on and your application became an orphan;
- Requirements 6.4 for application development. Remember, just because your organization did not develop the application, if it is not PA-DSS validated, then it is your responsibility to ensure the code securely processes, stores or transmits sensitive authentication data and/or cardholder data;
- Requirement 6.6 is also in play regardless of whether or not the application is browser-based. At a minimum, code reviews must be performed. If the application is browser-based, then you can add in a Web application firewall (WAF) for additional security;
- Sections 7 and 8 related to access control and user management; and
- Section10 related to application log data.
Remember, every time a new release of your open source solution becomes available, you have to go through all of this all over again if you intend to use the new release.
So those of you thinking that you can somehow leverage open source to reduce your PCI compliance footprint, think again. All you have done is outsourced the development of your solution. The rest is still on you. In the end, it is really not much of a savings.
PCI Guru 
Can you please advise how the potential development using Agile development of payment systems can align with requirement 6.4.5
In particular
6.4.5 Change control procedures must include the following requirements:
6.4.5.1 Documentation of impact.
6.4.5.2 Documented change approval by authorized parties.
6.4.5.3 Functionality testing so that the change does not adversely impact the security of the system.
6.4.5.4 Back-out procedures.
6.4.6 Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.
And that is just it, isn’t it? There is NOTHING in Agile that says you have to do this so you need to have something in place to address those requirements. That said, these are development “best practices” are are the practices documented in the PA-DSS standard. I’m sorry if you think this is “stifling”, but it is something that needs to be done to ensure that information (PIC or otherwise) is kept secure and private.