Third party analytics/tracking javascript tags and PCI DSS

Question

Although variants of this question have been asked before, they seem to be about general risk, and I'm interested in the PCI DSS connotations.

If an e-commerce site is looking for level 1 or level 2 PCI DSS compliance (and therefore needs to involve a QSA as part of the SAQ review or ROC full audit) and the marketing department are asking for third party analytics javascript tags to be inserted onto every page, will this necessarily make PCI compliance almost impossible to achieve?

The risk appears to be that if the third party (for example Google Analytics, but there are many others) 'need' to embed a javascript line into every page, including sensitive checkout or login pages, etc. and that javascript pulls more code from the third party's servers beyond your full control, then you have essentially extended your PCI boundary to include that third party - and giving the PCI DSS auditor access to their servers and processes is going to be almost impossible in any meaningful way.

In essence, you would have to completely take on trust the effectiveness of the third party tracking code, and all the security controls and testing etc. surrounding their code changes because you have little or no control over the script(s) that are pulled in to your website. If I were QSA-ing this solution I'd raise some serious doubts about this approach.

So does this mean that PCI DSS compliant e-commerce web sites can't have active third party tracking javascript embedded onto all pages, or is there some flexibility here?

Answer 1

There is no specific PCI requirement about having 3rd party Javascript on your site or not.

Personally, I would not consider an analytics provider to be a PCI Service Provider under PCI DSS.

There are requirements however for your custom website to be securely developed (6.5), and for it to reviewed via security assessments or to be run under the protection of a WAF (6.6).

Additionally there are requirements for vulnerability scans (11.2) and external penetration testing (11.3.1).

A third party library hosting your website should be flagged as a vulnerability under one of these requirements. During a normal, non PCI security test, this would usually be worded that there is a third party library present and this risk should be reviewed to ensure that the library is trusted, and the domain it is hosted on is also trusted, should this is an external domain. If the third party domain is untrusted, or if it is compromised then it would be a risk to your environment and to your PCI compliance. That is, something hosted on google.com would probably be OK, but something hosted elsewhere may not.

During a security test, this is usually initially ranked by a pentester as a low risk vulnerability. However, it should be reviewed by the business. If your business accepts this risk, then simply document it as such. If you consider it a risk that cannot be accepted, then you should document the steps taken to mitigate such a risk. For example by putting the third party script through a code review, and then hosting the script locally rather than this being fetched from a third party domain. Also, browser subresource integrity is now widely supported, in which the browser rejects remote scripts should they be altered: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

PCI DSS is mostly about documenting how you have dealt with the spirit of each requirement, rather than a black or white list of cans and cannots. Then, should you be audited you can take the QSA through your business decision process to demonstrate how you are meeting the requirements above.

_{Disclaimer: I'm not a QSA, nor, more importantly, your QSA. Only your qualified QSA can accurately assess your responsibilities under PCI DSS, as they will have full knowledge of your business and how it relates to your card processing activities.}

Answer 2

I am not a QSA. You should consult your QSA on this matter.

I entirely agree that delivering javascript from an unsecured source as part of pages containing data in scope for PCI-DSS should not pass muster with an alert QSA. I would go a step further and say that other pages in the same session should not contain unsecured javascripts.

I may be overly conservative, but I would go a couple of steps further than that. Performing server or client side includes of any content would not pass muster were I the assessor. Consider that this source outside you control can change the content without your knowing they have done so. What mechanism do you propose to apply to test the safety of that outside content? A wide and ugly range of potential attacks occur to me. How reliably can you assure that it is safe each time it is included?

As an alternative, consider copying the content to your own server, vetting it security, then serving it up directly, without dynamically loading it from the third-party. In effect, this makes it part of your site and subject to your change control processes.

Answer 3

PCI DSS 3.1 Requirement #12.8 states

"Are policies and procedures maintained and implemented to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data ..."

When examining whether or not analytics falls within scope, consider the following points:

• Analytics providers are definitely providing a service, and should therefore be considered service providers. The PCI Compliance Guide further reinforces this, taking as reference the PCI Service Provider definition:

"Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control or could impact the security of cardholder data. (Source:www.pcisecuritystandards.org)"

• External javascript definitely has the potential to affect the security of your PCI data. (See JaimeCastells's answer)

If you are required to have a QSA review the requirement, then use their opinion. If your PCI level does not require a QSA, you need to make the decision based on your best understanding after thoroughly researching the question (and optionally hiring a consultant QSA).

Answer 4

The main concern is that you have to trust Google or any other third party which helps you to track the users. When you lay out PCI DSS in a strict way you are responsible to make sure that only PCI DSS compliant entities may get access to card holder data or any sensitive data. So loading a script from a third party which is not compliant is not allowed. The compliance has to be proven by an AOC.

However what you can do typically is hosting the tracking script on your server. Which means you can assess once that the corresponding script is not stealing card data. When you host the script you have the control and you do not need to have an AOC. Typically the actual tracking data is passed over to the third party by an image. So when controlling the script you control what data leaves your environment and as such you get compliant.