3

A common scenario for e-commerce credit card types of transactions is a website with a connection to a third party payment processor. For a number of reasons you might not want to use an iFrame or page redirect, but doing so opens up your PCI scope significantly. Assuming the cardholder data would never be sent to your servers I would like to know if using a PCI compliant third party CDN (e.g. AWS CloudFront) would reduce your PCI scope regarding infrastructure significantly?

Take this example; a merchant's website consists of one html file that contains a form for collecting a customer's information and their credit card details. When the customer has filled in the details and presses submit the credit card data would be sent to the third party processors directly from the browser via an ajax POST, and receives a token in return. The token and other data is then sent off to the merchant's server, of course excluding any cardholder data.

Assuming the website is the only in scope system it would seem like a lot of the PCI requirements would no longer apply. It would be segmented by default, the CDN provider would take care of antivirus and IDS/IPS, you can't SSH into it, there are no internal services like SMTP, the firewall configuration would be greatly reduced or removed (since there may be only one port in and out)...I'm sure there's more.

Of course you'd still need to ensure the code is written in a secure way, have penetration test, and there are many other requirements that still apply, but at first glance this seems like a very secure solution, like a sealed box, that could greatly reduce scope.

Questions:

  • For the example above what will the scope be? Just the CDN distribution? The origin? The development computer used to upload the html file?
  • Will it be a problem if you can't monitor/log the low level traffic yourself? I guess the CDN will be responsible for that.

Edits: I changed the question from iFrames to using an API as that seems more useful, as often using an iFrame will reduce a merchant to SAQ A unless you're a service provider.

Richard
  • 327
  • 2
  • 13

1 Answers1

3

Yes, moving card holder data (CHD) handling off of your network to PCI compliant 3rd parties is an excellent way of reducing the PCI scope of your implementation. Having the payment page hosted with a PCI compliant 3rd party, and integrating the transmission of CHD to a PCI compliant 3rd party tokenization and secure storage service provider, greatly reduces your PCI scope.

Note that you are still transmitting CHD from this site. So while this implementation would reduce your scope, the integration code would still be in scope. You still need to protect against Cross Site Scripting (XSS), redirection hacks from the payment page to the 3rd party site, etc. I would recommend doing quarterly PCI scans with an approved scanning provider here.

However, I don't feel using a CDN to achieve is ideal. While a CDN could work, it seems like the right technology for this kind of implementation. The origin server could be considered in scope, making its own PCI compliance an issue, and complicating the implementation.

Given that the requirement is to only work with PCI compliant 3rd parties for the payment pages, I would suggest using a PCI compliant service provider for hosting, like GoDaddy Quick Cart, for example. With this service, you can get Level 1 PCI compliance for $9.99 per month, and can customize the payment page to handle the CHD, and interface with the tokenization provider. I think you will have more flexibility with this type of hosted service, and still reduce your PCI scope.

Rodrigo Murillo
  • 1,927
  • 11
  • 17