PCI Compliance: the risks of doing e-commerce

It goes something like this:

(Client): I want to add a shopping cart to my site. I heard that xyz cart is free, can you add that for me?

(Developer): Sure! That looks easy.

(Months and a couple thousand dollars later): Okay, I think it finally works, and is all hooked up, ready to go. I put an SSL certificate on your $15/month GoDaddy account and so now you're all safe and secure.

(Client): Great! I'll just check all the boxes on this PCI questionnaire and we're in business!

A few orders come in here and there, and all seems fine. At first.

The first sign of trouble came three or four months later. A customer complained about seeing the store come up in Google under Viagra. The developer checked into it and found that Google had a bunch of results pointing to the site that had nothing to do with the product. Puzzled, he followed the links from Google and the page had nothing like what Google showed -- the site looked completely normal. The developer shrugged, told the client it all looked fine, and he went back to his Xbox.

Then the other shoe dropped. The client's merchant account provider notified the merchant of irregular activity they had matched up to cards used on his merchant account, and they were conducting an audit. A security company had to be hired to verify that the site was intact.

Of course it wasn't. Fortunately for the client, he had not done much business, so there were only 76 credit cards stolen. The merchant account fined the client $1900, $25 for each stolen card number. Unfortunately, they entirely revoked his ability to accept credit cards until he could meet PCI level 1 compliance. When he went to do this, he found it would cost over $100,000 to reach this level of compliance, well out of reach of his budget.

Two months later he closed his business.

Ok. So this story is fiction, but all the elements are true. We have seen this level of negligence around security on dozens of e-commerce sites, have been brought in to clean up sites that have been hacked to feed Google completely unrelated results, and $25 per card is the low end of the fines imposed if you are not PCI compliant and have a breach.

I attended a webinar yesterday by the Commerce Guys on PCI compliance. While we have been doing PCI compliance for ourselves and supporting the efforts of many of our customers for years, two things stood out from the presentation: the overall cost of compliance for the different types of processing, and some of the new online gateways that help keep compliance costs down.

Some definitions

Of course, being in technology, we have lots of acronyms. PCI = "Payment Card Industry", the group that creates "Data Security Standards" (DSS) merchants must comply with when accepting credit cards. Most merchants can do their own compliance and attest they are in compliance using a "Self Assessment Questionnaire" (SAQ). There are 5 different versions of the SAQ, and which one you have to use depends on exactly how you process charges. Three of those versions apply to e-commerce and shopping cart sites, SAQ-A, SAQ-C, and SAQ-D.

There's another dimension that affects how rigorous you must be with transactions, besides the type of processing: the number of transactions, which puts you in a "Level" from 1 to 4. Process less than 20,000 transactions per month? You're level 4. Process more than a million? You're level 1.

If you have a breach, are found to not be PCI compliant at your current level, and even a single credit card number was stolen, you get bumped to Level 1, SAQ-D regardless of how many transactions you do. One strike, you're out.

Compliance costs

SAQ-A is a really simple level to attain. Basically, you don't accept credit cards at all -- you send people to another site entirely to enter their credit card information. You can become compliant in an afternoon.

SAQ-C is quite a bit more stringent. According to the Commerce Guys' presentation, this takes weeks to months. When we're doing e-commerce sites, we assume we need to meet this level, and we have set up provisioning scripts and environments to start out this way, but there is ongoing cost in maintaining this level of compliance. You also need to conduct quarterly security scans.

SAQ-D is far more costly, mainly because you have to get outside audits done by a "Qualified Security Assessor" (QSA).

Here's a summary of costs, from http://drupalpcicompliance.org/ :

Type|PCI Controls to Meet|Estimated Time|Estimated Cost
----|----|----|----
A|13-15|Hours|$100 - $1000
C|80|Weeks to Months|$10,000 - $100,000
D|288|Months|$100,000 - $1,000,000+

Ways to keep compliance costs down

The basic rule of thumb is the less you have access to a card number, the easier it is to be compliant. If you ever store it, that puts you into SAQ-D territory. If your web site takes the card number, immediately forwards it to a gateway, and never stores it to disk, you're in SAQ-C. If you send the user to another site entirely and your site never even sees the number, you can do SAQ-A.

The catch, however, is that even with what could be an SAQ-A site, is that if your code is not kept in a secure environment, and an attacker modifies it to send it to a spoofed gateway, you could still be responsible for credit card theft. For that reason, the Commerce Guys strongly recommended maintaining the SAQ-C level of environment, even if you are using one of the payment methods that entirely bypasses your server.

There are two very common practices out there that basically cannot be done while maintaining a secure environment:

• FTP. This has long been the standard way designers and developers copy code to servers, and it's horribly insecure. If one of your team members connects via FTP to your site in a public wifi setting (like a coffee shop), the password can be very easily intercepted by anyone else on that network. We won't even install FTP on any server running a shopping cart.
• Using a shared server. If you're doing any e-commerce on a server that allows people you don't know to log in, you are putting your whole business at risk. You really need a dedicated server of some kind to do e-commerce (virtual servers are usually fine).

  With those out of the way, there are basically 3 techniques shopping cart sites can use to send the actual card data to a different service entirely, and stay in the SAQ-A range of compliance:

• Hosted page. This used to be the only real way to use a shopping cart and stay in the SAQ-A range. You collect all the product/payment info on your site, and then send that with the customer to an entirely different site, on an entirely different domain, to enter their credit card details and when they are done, bring them back to your site. Some Paypal and Authorize.net options do this, as well as services like 2Checkout, Amazon payments, Google checkout, etc.
• Direct Post. The form that collects the card info gets posted directly to the payment site, instead of your site, and the user gets seamlessly redirected back. This approach is slightly easier to attack than the others, because the user does not see what's actually happening, but it does make your compliance easier. This is also supported by Paypal and a few others, and is a newer technique.
• Embedded Iframe. In this version, you actually embed a page coming from the payment gateway right into your checkout page. This is harder to attack than direct post, but it can have some confusing behavior if the integration isn't quite right. Newer services like Stripe use this technique.

  At Freelock, we still largely use and recommend the SAQ-C type of processing, where the site actually does collect the credit card number and passes it straight on to the gateway -- we think it provides a better, more consistent user experience, and if you start from a secure environment, compliance doesn't have to be that costly (though it is definitely in the $10K a year range). You just need to be aware of this cost, and budget for it.

  If you're accepting credit cards online, don't be that client who is oblivious to PCI and security issues. Would you leave cash in the till and the door unlocked at night? These are basic, fundamental things you need to understand to safely do e-commerce, and if your developer isn't coaching you on these issues, find one who can.

  For more on the costs of doing e-commerce, be sure to read this post from a couple years ago.

  (Update: the webinar is now live, and you can view it here: http://commerceguys.com/webinars/archive/pci-compliance-drupal )