Achieving PCI Compliance for SAQ D with Amazon AWS

A client of ours had pressed upon them a requirement from their merchant account provider that they certify PCI Compliance for their software.

The software in question was a custom web application we developed for them, which implements a unique subscription model for their product.

When we originally developed the application, PCI compliance rules were at version 2, and we engineered the software to comply with the version 2 rules to minimize their exposure. We utilized Authorize.net as the payment gateway, and stored no credit card information locally on the web server. In order to charge customer cards, we integrated with Authorize.net CIM, establishing customer and payment profile ID’s stored locally to reference payment information on Authorize.net’s servers, which we could then charge as needed according to the subscription model.

This effectively delegated the most cumbersome PCI Compliance requirements to Authorize.net. Most e-commerce web applications are going to require compliance with SAQ A or SAQ D. However, PCI version 3 rules added an additional SAQ A-EP for applications that do not receive cardholder data but can affect the security of the transaction. One of the main differentiators of SAQ A or A-EP is how the cardholder data is delivered to the third-party payment processor.

SAQ A currently allows the use of a redirect to the third-party payment processor or an embedded iFrame. However, if a POST or JavaScript submission directly from the merchant’s page to the payment processor is utilized then it’s promoted to SAQ A-EP. The main reason is that an attacker can quietly intercept cardholder data without the merchant or customers noticing. Authorize.net CIM’s hosted forms didn’t have the look and feel that we wanted, nor did Authorize.net’s CIM product support a “Direct Post Method” – which required that we comply with SAQ D.

If you’re unfamiliar, the difference between the standards SAQ A vs SAQ A-EP vs SAQ D, the difference is between addressing a couple dozen requirements (SAQ A), almost a couple hundred (SAQ A-EP), and almost four hundred (SAQ D). In the former, your system would not even be transferring cardholder data, so there is no need for an ultra secure network environment. In the latter, if your system touches cardholder data in any way, you must take great pains to secure your network.

In contemplating the cost / benefit of re-engineering the application’s payment system and subscription model vs achieving SAQ D compliance, we concluded it was pretty much break even in the near term, and in the long term, having compliance would give us maximum flexibility to structure payments on the site however we wanted to.

So, off we went on one of the most sophisticated hosting configurations we ever engineered.

First off, we had to switch from Rackspace Public Cloud to Amazon AWS, for the simple reason that Amazon’s cloud is PCI certified, and Rackspace’s Public Cloud is not.

Next, we had to engineer a cloud server configuration using VPC network configurations & ACLs along with EC2 and RDS security groups & instances that complied with the requirements of SAQ D. Here is a diagram of our network architecture:

As you can see, one of the major concerns, is separation of responsibilities per server, and preventing direct connections between the server which transfers (or stores) cardholder data with the outside. This is achieved by proxying all incoming SSH requests through the “bastion” server…. and all outgoing connections originating from the server (for instance, SMTP, or HTTP originating from cron jobs, through a proxy.

Proxying in this way provides additional levels of security, which, to an attacker, are additional barriers to overcome. Plus it also lets us more easily log and detect threats, which is another requirement of PCI Compliance for SAQ D.

Besides all the technical work of setting up the network architecture, there is a lot of paperwork to do! A policy document must be developed,  periodically reviewed, and maintained, which documents not only the technical aspects of the network configuration and cardholder data flow, but states the human policies that are in place for protecting cardholder data.

All in all, it was a lot of complicated work, but it is also right up Endertech’s alley, because that kind of complicated work that we thrive on. We were able to configure this network, migrate the client’s application, compose the policy docs, and achieve SAQ D compliance in only about 30 days.