Let's Talk About PCI Compliance for Ubercart and Drupal Commerce.

Submitted by Rick Manelius on Thu, 10/11/2012 - 22:13

UPDATE: A white paper on Drupal PCI compliance is actively being worked on. Please visit the official website for more details.

Drupal makes it incredibly easy to turn even the simplest website into a full fledged commerce solution. All you have to do is download a few modules, check a few boxes, and you’re up and running in no time! Now you can sell your products around the clock to anyone in the world with a credit card. And because there is a strong focus on security within the Drupal community, it’s easy to convince ourselves that nothing can go wrong while we move onto building out the next feature or launching the next website.

When Things Go Wrong

The bank, the credit card company, the website owners, the customers: everyone’s happy as long as the transactions are running smoothly and securely. But what happens when a customer’s data is exposed and/or stolen? Who is responsible?

If I’m a brick and mortar store owner and I write down a full credit card number onto paper, then I’m liable if that card data is stolen and/or used in an unauthorized format. I’m also liable if I do something insecure electronically, such as email a full credit card number without encryption. Hopefully this is obvious, but I’ll underscore it anyway. If a customer’s credit card information can be exposed and/or stolen while it’s within our possession/jurisdiction or as a result of our actions, then we are (at least partially) responsible and liable.

Liability can be a hefty price to pay if a security breach occurs. Fines can go well into the 6-7 figure range and the ensuing PR nightmare can make it difficult to convince customers to trust you again. And if you want to accept credit cards at your store again, you’ll no longer be able to submit your own security assessment questionnaire. Instead, you’ll have to be audited by a 3rd party at a tremendous cost of time and resources.

The effects don’t stop at the individual company experiencing a breach. Drupal’s reputation for being a secure CMS/CMF can be severely undermined, even if it wasn’t the component that ultimately failed.

My Intention

Emailing credit cards should be an obvious no-no, and yet I still occasionally receive them in my inbox from web savvy individuals that I assume should know better. And I don’t believe that they were being careless or intentionally malicious. Sometimes they just didn’t know any better and believe things are far more secure and protected than they actually are.

I was in the very same boat with respect to PCI compliance when I began my Drupal career several years ago. “It just works” was good enough for me. And my colleagues, some of them with 5+ years of prior experience, didn’t seem to bat an eye when we fired up some commerce stores and began processing transactions. This was incredibly naive and stupid of me. But like an otherwise intelligent person emailing credit card numbers, I simply didn’t know any better at the time. And I didn’t get any major red flags when I performed several google searches and searched through the Ubercart threads. So I just assumed everything was ok…

Full disclosure: I have no certifications/credentials with respect to PCI compliance security. However, I probably have 200+ hours of self-study under my belt because there was no definitive guide for Drupal Ubercart and/or Drupal Commerce PCI compliance. Therefore I do feel qualified to have some opinions on the matter based on what I’ve learned, discovered, and implemented along the way.

The reason I’m writing this article is because it seems that everywhere I turn, Drupal developers and Drupal shops are still doing the equivalent of emailing credit card data with their PCI compliance requirements. This is dangerous and has got to change. And I believe the biggest reason this is occurring is due to lack of quality information (as well as the abundance of misinformation) within the community.

So it is time to have “the talk” with respect to PCI compliance and Drupal e-commerce. Let’s get a few major myths out of the way.

Myths About PCI Compliance within Drupal

Disclaimer: I’m not a lawyer and this is not legal advice. Everyone’s card data environment is specific to their configurations and business needs. The information below is my opinion and is accurate to the best of my knowledge. If anything is incorrect, I will do my best to fix it. Please do your own due diligence!

Myth 1: I’m not storing cards on my site, and therefore I’m PCI compliant.

FALSE. While not storing the card data does (significantly) reduce your PCI responsibilities considerably, it does not eliminate them completely. If the credit card data is still submitted to your site and passing through the Drupal form API, then your site + server is still processing and transmitting that data. If someone were to alter a line of code and/or intercept that data with a properly configured hookformalter, the card data could still be collected and distributed.

Myth 2: I’m using Authorize.net, and therefore I’m PCI compliant.

FALSE. Authorize.net (or whatever payment gateway you select) is one piece of the puzzle. And while Authorize.net can handle its portion of the process securely, your system is only as strong as its weakest link. Is your site running on a shared hosting environment? Are your Drupal security patches up to date? Do you have your SSL certificate properly installed? Did you turn on HTTPS?

If you’re accepting cards on your site, you’re probably PCI SAQ C. Reviewing all the requirements for this level (approximately 40) will give you a better understanding of your responsibilities.

Myth 3: I use Drupal Commerce, and therefore I’m PCI Compliant.

FALSE. Just because Drupal Commerce is newer than Ubercart does not mean that it’s compliant out of the box. A single configuration change can open up a security hole. Example: an admin logs in and disabled HTTPS browsing. Now a user’s session data and or form submission data can be sent in the clear and potentially stolen.

Myth 4: PCI Compliance is an extortion racket and I don’t have to comply.

TRUE and FALSE. There is also nothing compelling you to pay your taxes, until a government agent is knocking at your door. While I also think the process is more security theater than security, the fact of the matter is that you have to comply with their requirements for the privilege (not the right) to accept credit card payments on your site. And while this may seem difficult and annoying, there are other solutions available to you if if you or your client simply cannot put forth the time and energy to get your site fully compliant.

Myths 5, 6, 7, etc

I could go on, but I think you’re getting the point. PCI compliance is not so simple and blanket statements about Ubercart and/or Commerce being compliant out of the box are simply not true!

Solutions

It’s easy to be negative and point out what’s wrong, but what about solutions? If PCI compliance is so difficult and expensive, what can we do about it? I will do my best to give a concise overview and specific examples.

The PCI compliance standard targets 5 major security goals, which break down to 12 areas of focus (see here). In total, there are 288 possible items to be responsible for in order to prove your compliance. Thankfully, you can configure your system to offload or outsource a portion of those responsibilities to other people or services. The PCI compliance industry broadly groups 5 levels of responsibility: A, B, C, C-VT, and D. Typically, a website would fall into A, C, or D so I’ll ignore B and C-VT for now.

If you’re storing credit cards on servers that you personally manage or edit the code, then unfortunately you’re SAQ D and you have to comply with all 288 responsibilities. This can take most companies several months and hundreds of man hours to comply with and document. However, if you only process and transmit cards, you’re likely SAQ C. This sheds off almost 85% of the line items and now you’re down to 40 items to comply with. However it’s still a very difficult process. It also limits what types of services you can use. Example: don’t bother trying to use Rackspace cloud because you they don’t have a PCI Level 1 certification for their cloud server offering. You’re limited to managed only, and it still will require time and attention to get it up to spec.

The holy grail for Drupal eCommerce are PCI SAQ A solutions. At this level, you and your company are now responsible for only 12 out of the original 288 PCI responsibilities/requirements. And fortunately most of these items are easily achievable by just about anyone and within a few hours or days.

The easiest way to achieve PCI SAQ A is to configure an Ubercart or Drupal Commerce store to redirect to an external payment site (e.g. Authorize.net, Paypal, etc) so that they handle ALL the payment data before redirecting the user back to your site after a successful transaction. This type of redirection is called ‘outsourcing’ and is the only way (IMHO) to fully get to PCI SAQ A on Drupal.

The unfortunate reality is we all dislike this type of solution. Sending users to another site can be confusing and we lose control over what the payment site looks and feels like. It also limits our options of features and functionality. For example, using Authorize.net SIM doesn’t allow us to leverage their CIM services, such as card on file, which is usually needed for any site doing recurring billing.

This type of use case puts us into a bit of a dilemma. We either tell the client that we have to alter their business model OR we push forward with the feature set as requested and take on the PCI SAQ C responsibilities.

Tokenized Payment Gateways

To combat this, we’re seeing an emergence of a hybrid solution which can give us the best of both worlds: total feature flexibility with payments on site while still achieving PCI SAQ A. They are often described as “tokenized” payment gateway solutions. To understand why they are different, let’s first look at how a traditional payment gateway works.

In a traditional payment gateway with payment on site, the credit card first has to go through a series of validations within the CMS and then pass onto to the payment gateway servers from our website directly. While it’s doing this, shopping carts like Ubercart and Drupal Commerce do encrypt and protect this data as best as they can, but it’s still vulnerable to any deficiencies in our setup because it’s passing through our setup.

In tokenized solutions, the credit card data never touches our servers through the clever use of a javascript API. Now when the browser page is loaded on a clients computer, there is subtle but important difference. When the user clicks the submit button, the data is first sent directly to the payment gateway to validate the card first. If it validates, a one time token is returned to the user’s browser. Then and only then does the customers information and token get submitted to the Drupal site. Now the only thing passing through your Drupal site and servers is a token that represents the users card. When that token then arrives at the payment gateway again, the transactions is a success and the checkout process continues. 

And if that explanation didn't fully make sense, check out this excellent step by step breakdown and infographic by Braintree Payments.

In short, the user never left the site and yet the payment never touches your servers. I can’t emphasize how awesome this is! Not only does this drastically reduce the amount of time and effort it takes to achieve PCI compliance, but it still allows you to leverage the full power and feature set of Drupal by keeping the customer on site.

What the Drupal e-commerce community needs is more of these PCI SAQ A solutions. Unfortunately, only a few exist for Ubercart and Commerce, which means we are still slogging through the SAQ C and D responsibilities… or ignoring them altogether. And with 45,000 active Ubercart installations and 17,000 active Drupal Commerce installations, we can not afford to keep ignoring these concerns forever.

Responsibility and Opportunities

Clients come to us because we are perceived as having expertise in an area of knowledge that they do not. And as consultants, I believe it is our job to not only help them achieve their vision but to alert them of decisions and directions that would be the equivalent of stepping on a landmine.

My hope is that we no longer find it acceptable, as a community, to create a hand over a commerce website without even mentioning the ramifications of PCI compliance. At the very minimum, we should at least point them in the right direction so they can ultimately navigate through this by themselves.

My hope is that when a potential client comes to us with a sub-$10,000 budget wanting a SAQ D commerce solution, we do one of 3 things: decline, educate, or upsell. We either walk away because it’s not right to hand over a ticking time bomb. Or we educate them into adopting a solution that fits their budget. Or we upsell them on additional contracts and services to perform a security audit and ongoing maintenance in order to achieve and maintain their compliance.

But in no way to do we simply walk them up to a minefield, wish them good luck, and run onto the next client. If we keep doing that, someone’s (eventually) going to get hurt.

A Proposal

Although this is a lot of material, we’ve really just scratched the surface. I typically like to be much more comprehensive with examples and citations, but we have to start the conversation somewhere. I hope that, at the very least, I’ve made my case that becoming PCI compliant is not as easy as turning on a switch or just making sure you’re modules are up to date. I also hope that this puts more pressure on the community to seek and develop PCI SAQ A payment gateways so that becoming compliant becomes affordable and achievable for every business wanting to have an eCommerce solution on their Drupal site.

But we’re not there yet…

In the meantime, I believe we need a more definitive PCI compliance resource tailored specifically to the needs of the Drupal community. Maybe this would simply be a series of articles (such as this) where we take on one aspect a time: starting with the needs and requirements and walking through a series of case studies and solutions.

Or perhaps the best approach would be a whitepaper like the one found at Drupal Security Report. In this scenario, we could have an all inclusive document that could be sent to prospective clients before a conversation about a commerce installation. Providing such material ahead of time could be extremely valuable, save a lot of time, and set proper expectations about what is possible given their vision and budget.

I’d be very excited to play a part in creating such a whitepaper and I also believe I would be a good candidate to take on such a task. During my PhD tenure at MIT, I successfully published 6 articles (yay for carbon nanotubes!) in peer-reviewed journals and in conference compilations as well as successfully defended my thesis. But I also know that I would not want to take this on alone, and would welcome additional authors, particularly those with extensive knowledge and experience in this field.

Continuing The Conversation

And if these articles and/or a whitepaper never comes to fruition, at the very least I want to spark this conversation…

Thoughts? Questions? Comments? Rebuttals? I’d love to hear from you!

Resources

Here are is a list of resources I’ve collected during my research and study. Some of them might be a little out of date or no longer relevant, but I did my best to update the labels so that someone other than myself would understand what they mean.

Tags: Drupal, Drupal Planet, security, PCI compliance
comments powered by Disqus