PCI compatible recipe?

Question

I've struggled to find a really straight answer that makes me super comfortable to this question after searching SE, PCI basics, drupal.org, AWS resources, and reading the Drupal PCI Compliance White Paper.

I think I am just looking for some confirmation or denial from folks who have set up eCommerce environments before. Perhaps this is because I am overthinking it (I really don't want to expose a small business to unnecessary liability), and perhaps because environments are all different so it's difficult to say.

I'd like to be sure to create a PCI compatible environment using Drupal Commerce with an onsite payment gateway (Authorize.net). In our MOU it will be up to the site owner to ultimately write down their business processes and take the SAQ (recommended, as they should qualify for level 4 from Visa/Mastercard) to say they are PCI compliant, but since I am building the site out I would like to make sure they don't have any trouble with that piece of it.

As long as we are...

• Hosted in a PCI compliant environment (AWS EC2 in this example)
• Have firewall properly configured
• Serving all relevant (but ideally all) pages over SSL
• Use good passwords, no users are shared
• All security updates are made for Drupal and modules promptly

Is that a recipe for a PCI compatible environment? Have I forgotten any pieces?

My second but related question is - Does using Drupal Commerce with Authorize.net (onsite processing) mean the business should use:

• SAQ-A (Card-not-present merchants: all payment processing functions fully outsourced, no electronic cardholder data storage)

or

• SAQ-EP (E-commerce merchants re-directing to a third-party, PCI compliant service provider for payment processing, no electronic cardholder data storage)

I know Drupal Commerce provides the 'no cardholder data storage' by design, but i'm very unclear on the definition difference between 'all payment processing functions fully outsourced' and 'merchants re-directing to a third-party compliant service provider for processing'.

Thanks for your thoughts!

Answer 1

Disclaimer: Keep in mind I am neither a lawyer nor a PCI QSA.

After doing more research - I'm convinced that using Drupal Commerce with authorize.net AIM (which is the method used by the authorize module that comes with the commerce kickstart profile) should land you directly into SAQ-D in almost all cases (do not pass go, do not collect $200).

This means you need all the things above plus much more management and policy on your end (or your clients end). It wouldn't be feasible for a small company without a huge budget for a custom project.

Here is the best/most robust explanation i've found of which SAQ to use in one place.

To reduce the scope of the CDE using Authorize.net, one would need to integrate with SIM (offsite form generation) to use SAQ-A, or DPM (direct post) to use SAQ-EP. This assumes you can say yes to the entire list of qualifications i.e. only take payment online, no POS etc. The latter option offers more customization but is more work.

This module looks like it will allow you to do so with Drupal Commerce, but I have done no testing or verification.

Looks like smaller budget clients should be briefed on PCI (always) and plan to use the off-site methods such as Authorize.net SIM or Paypal WPS where the form is generated by the CC processing organization's servers, and never touches your environment. This way your environment should be out of scope with proper configuration.

Here is a (albeit pretty old) thread from authorize.net development forum that has some general and scalable config insights I found very useful.

Here is another (1 year old) white paper that sets forth a framework for PCI compliance on AWS in general. Some of these pieces are not applicable to just a Drupal Commerce server, but still interesting and good.

Any more thoughts still welcome.