Adventures in PCI compliance

Inspired by the "Storing credit card numbers" thread, let's talk about what it takes for a site, particularly a Drupal-powered shopping site, to become and to stay PCI compliant, and for keeping our sites secure in general.

A side effect of FOSS shopping cart systems like osCommerce, Magento, and of course Ubercart and Drupal e-Commerce is that they're commonly used by smaller stores or one-man shops who may not be aware of the standards in this regard, or have enough knowledge to comply with them - or maybe even they just don't care. It doesn't help that a lot of info out there about security can alternate between being utterly boring and utterly confusing.

Fortunately, Wikipedia's article on the Payment Card Industry Data Security Standard is blissfully short and easy to read, though it does only list the basics. Some of the elements which stand out to me are:

1. Install and maintain a firewall configuration to protect cardholder data. Probably impossible if you're using a shared hosting service to host the site due to lack of budget and/or tech savviness. I've been looking in to getting PF up and running on our company's spiffy new FreeBSD server, but it's a bit complicated and I'm afraid I'm gonna end up locking myself out…

2. Do not use vendor-supplied defaults for system passwords and other security parameters. The biggest weakness I can think of here with regards to Drupal is that its most common database back-end, MySQL, by default allows remote connections, and has a blank password for the root user. If you correctly followed installation instructions, you should have at some point changed the root password; as for the former issue, you should add the line skip-networking under the [mysqld] section of your my.cnf file - again, this might not be easy if you're on shared hosting. Restart the daemon, then telnet <hostname/IP address> 3306. You should be told to get lost. Even if you're not using Ubercart, this is a pretty smart practice to follow - the fewer open ports on your machine, the better.

4. Encrypt transmission of cardholder data across open, public networks. In other words, use SSL/HTTPS. Duh.

5. Use and regularly update anti-virus software on all systems commonly affected by malware. In other words, be vigilant about malware if you're hosting on Windows - or be really vigilant and don't host on Windows in the first case.

10. Track and monitor all access to network resources and cardholder data. Another requirement which may be difficult to fulfill on shared hosting.

It's not on this list, but obviously you also want to select strong passwords for everything - for your user account on the web server, for all MySQL accounts, and for all administrator Drupal accounts. For passwords that I don't have to type often, such as MySQL user passwords which I rarely use after putting them in settings.php, I like to use the Strong Password Generator site to generate a fourteen-character password full of nonsense. They're not easy to remember for passwords you have to type often, though. For those, remember - at least seven characters, using capital letters, lowercase letters, numbers, and at least one symbol. For just a little more security, don't use a common name like "bob" for the user account username, since brute force attacks typically work by trying common usernames together with common passwords. If you're in a position where you can choose someone's username but they will be able to change their own password (to something like "password," for example), giving them a username like "su5Anj0nEs6" might be your only salvation… (And for Pete's sake, never use a username like "admin" or "root" if you can help it…)

Also, when installing third-party modules, be careful to only use ones you've downloaded from drupal.org. Here's a possible attack vector; I hack Views or some other common module to include a hook_form_alter() hook which takes note when a user is submitting a payment form and emails me the credit card details. I then advertise it on an IRC channel or forum or such as my own improved version of Views which works 200% faster than the original, knowing full well that most of the people who try it won't bother to see if that's really true - or what else the module may be doing. You download and install the module, and now I have your customers' credit card data. Sticking only to modules on drupal.org doesn't totally insulate you from this kind of attack, but at least you'll get some assurance that thousands of other developers can easily take a look at that code at various points in time and make sure it's not and has not ever done anything like that. And just in general, both for speed and for security reasons, you really do want to use as few modules as necessary on any given site…

I think Ubercart itself is helpful with regards to maintaining customer safety, such as with its ability to delete credit card numbers from permanent storage after a payment is completed. It would be really awesome if that data could be "whited out" with zeros or random data on the physical hard drive somehow, but that's at a far lower level than Ubercart operates, obviously.

Enough blathering from me. Your thoughts?