Does all source code need to be PCI compliant?

Question

We have never transmitted, processed or stored credit card information in the past as we did everything via PayPal so we never needed to be PCI compliant.

However, we are launching a new online store and by having a seamless checkout where credit card information in processed without redirected to PayPal, we need PCI compliance now.

We are going to consult a Qualified Security Assessor Company to guide us through getting and maintaining PCI compliance. However, I wanted to get a decent idea of what i'm looking at before consulting them, before they try to sell you every service in the house that you may not need.

In terms of PCI compliance, I understand it needs to be done on the software and hardware level and meet the 12 points + required. We are going with Magento Professional as it has a PCI compliant payment system, and we are going with a PCI compliant web hosting company (dedicated server). But in terms of software, do you need PCI compliance on EVERYTHING? Or just the software that transmits, store and processes credit card information?

For example, according to Magento, the Payment Software is PCI compliant, while the Magento Platform is not. So this allows you to make changes, modifications and customisations to Magento without affecting the PCI compliance of the payment software.

In other words, i'm asking, do you only need PCI compliance on the source code/software that deals with transmitting, processing and storing credit card information? These 'Qualified Security Assessor Companies' give the impression that all source code needs to be checked for PCI compliance, which is impossible!

For example, in the case of Magento, can I make changes and modifications to it and still remain PCI compliant? So long as the payment module is untouched since it is PCI compliant and the web hosting, server and OS is PCI compliant?

I mean the php, javascript, mysql stuff that does not deal with credit cards don't need to be compliant do they? they will be on the same server of course.

Answer 1

The basic answer is that it depends. In general, only the source code that deals (or can deal) with the sensitive and protected data of PCI needs to be PCI compliant. However, this means that if other areas of your code have access into the secure areas, you need security there as well. If another area of your application were to be vulnerable to SQL injection, for instance, it might compromise your credit card systems. That is why some people will lean towards PCI compliance for all software. There has to be some assurance that a poorly-written piece of software can be exploited to compromise the safety of the data.

I say it depends because there is always some room for interpretation by those doing the inspection. However, the good news is that of all the standards, PCI seems to be the most direct and specific about what you need to do and what you cannot do. Here is more information about what PCI says directly:

https://www.pcisecuritystandards.org/documents/infosupp_6_6_applicationfirewalls_codereviews.pdf

The basic issue here is to be sure that the site cannot be exploited anywhere. If you develop sufficient "firewalls" between your application areas (credit card data versus normal website), it will go a long way towards showing that you only need to scan some code. Also, as the above document states, you don't have to do a source code review in order to be PCI compliant. However, your application needs to be extensively tested to be sure it is safe from typical vulnerabilities.

Answer 2

I can't speak to the legal details of PCI compliance, but if I were an auditor of your system I would squawk very loudly if any non-certified code runs as the same userid that runs the certified code.

I'd also look pretty closely at what setuid/setgid executables are on the system, what runs as root or with elevated capabilities(7) that could influence the PCI-compliant software, and I'd probably demand mandatory access control tools such as AppArmor, SElinux, TOMOYO, or SMACK, and an appropriate configuration that prevents tampering with the PCI-compliant portions of the server by untrusted execution domains.