Early last week, I presented at cPanel’s Automation Bootcamp 2011. The title of my talk was ‘PCI Compliance: It’s about to get real.” Since neither cPanel nor I recorded the presentation (and the EiC over at  the Whir mentioned having a hard time trying to keep up), I figured I’d recap it here. If you just want the slides from the presentation, you can get those here.

PCI (DSS) Compliance for e-Commerce Sites

As much as people love to hate PCI Compliance (or more specifically, the scanners), it is a necessary evil. In an industry-wide race to the bottom, the Payment Card Industry Security Standards Council (PCI-SSC) had to implement a standard to which they could hold everyone accountable, and by which they would judge the security of consumer data, in all payment card transactions.

In 2006, the PCI-SSC got together and composed a standard that everyone in the Payment Card Industry (everyone who accepts payment cards, from brick and mortar stores to e-commerce), which they called the Data Security Standard. They wanted to help streamline an increasingly complex process (getting approved to process credit cards through your own in-house-developed payment application), but without compromising the security of consumer data. While the importance and relevance of PCI DSS can be overinflated, it is just as necessary as any other standard. Treat it like a list of regulations to follow, use common sense, and you should be fine.

To help you along, I have outlined much of what’s included in the PCI-DSS, and what you can do to help secure your server, and help your server pass its scan.

General Data/Application/Network Security Defined in the PCI-DSS

Most of the points addressed in the DSS would seem to be common sense, but they are outlined to prevent common vulnerabilities.

1) Write your application using clean and secure code.
All of the good developers I know have told me: using good, standard coding practices is key to writing a secure application.
2) “Protect Cardholder Data”
Specifically this means any ‘personally identifiable information’, which is defined below.
3) Encrypt and send securely all traffic and data
Use SSL, and encryption, for all traffic. Do not assume your customer/client will be protecting themselves.
4) Limit what you store.
The DSS clearly defines that you can and cannot store, and how you can store that information which is allowed:

5) Staff access/security
When it comes to “Cardholder” and “Authentication” Data, limit access to only those people and servers who need it.
6) Unique login credentials for each user.
Any person or server who has access to sensitive data has to have unique credentials, to aid in tracking.
7) Restrict physical access to servers hosting sensitive data.
If you are hosting this information in a datacenter, you are probably covered, but you will still want to double check with your hosting provider.
8) Use Anti-virus/malware software/scans.
This applies to application servers as well as employee workstations.
9) Maintain a strong written information security policy.
This policy must be strong, clear, and easily accessible to employees and customers.
10) Use non-default passwords
You cannot use default passwords in any software you have installed.
10) Increase Security through obscurity
Use private networks wherever possible, especially to limit traffic. If you have your sensitive data hosted on a single server, by itself, use a private network to connect it to your public web server, and restrict all other access.
11) Track/Monitor/log all access to your application.
This data is required in the event of a compromise.

Before you scan, every time:

Here are a few things you can do before you scan your server to help prevent unnecessary failures, and to help you retain your certification through future scans.

1) Install and maintain a Firewall

While you can use either hardware or software, you absolutely need a firewall. Any ports that do not need to be open to the public (MySQL for example) should be closed. Any other restriction of access that can be done will only increase your security. Though this isn’t a requirement: I strongly recommend a BFD/LFD like script/daemon. They can be extremely useful in mitigating unnecessary compromises due to weak passwords.
If your application is spread across many servers, I recommend a hardware firewall for the sake of simplicity. The easier your network configuration is to define and maintain, the more likely it is that you won’t leave unintentional holes.

2) Update your software

Software updates do much more than just add new features: they almost always include security patches. In fact, most of the time minor version updates are nearly entirely security patches. Make sure all of your software is at the most recent version you can run. Just to be helpful, a list of software that you are probably running, that you should keep updated:
– Update cPanel/WHM and all of its Plugins
– Recompile Apache (You HAVE to be using 2.0 or newer, due to a recent unpatched exploit in older versions)
– Rebuild PHP: You must be running the latest version in your branch. If you’re running an application on PHP4, you should already be in the process of re-writing and testing to move to PHP5, but the latest version of 4 will pass a PCI scan.
– Update CMS Software (and plugins) should always be kept at the most recent version. “Upgrading breaks my plugin” is not an excuse not to upgrade, and is probably an indication that your plugin was insecure and/or doing something it shouldn’t have been.

3) Use Good Passwords

I cannot possibly put too much emphasis on the importance of always using a secure password. Use of insecure or default passwords are an extremely common cause of compromise. Good passwords should be at least 8 characters long, should never be based on a dictionary word, need to contain capital and lowercase letters, and at least one special character. For more detailed discussion of the importance of password strength, see this page.

4) Disable services you don’t use.

WHM/cPanel comes bundled with a bunch of software that many hosts use. If you aren’t using it, disable it through WHM, in the ‘Service Manager’, and make sure that the port that was open for it gets closed in your firewall.

4) WHM: Apache/SSL Tweaks, and Mod_userdir

Make sure that all of your Service SSL Certificates are current, and then force all cPanel/WHM/Webmail traffic to use the secure ports, rather than insecure ports.  Once that is complete, go into the ‘Apache Configuration’. With each setting you will see both a ‘Default’ setting and a ‘PCI Compliant’ setting (they are sometimes the same thing). Make sure all of those settings are moved to ‘PCI Compliant’. The other thing that most scanners complain about is cPanel’s use of Mod_userdir. Under ‘mod_userdir tweak’ in WHM, you will find a full description and you will be able to disable it.

5) Disable/Limit DNS recursion

DNS recursion allows your server to act as a resolver for other computers. This resolver cache can be ‘sniffed’ to allow would-be hackers and exploits to gain knowledge about the domains your server is resolving. For example: the domain of the bank you use, and other information about your application configuration. It’s best to disable or limit recursion as much as possible. If you are using BIND, adjust your name.conf to mimic these:

To disabled recursion:

 

Limited recursion:

6) Add scanner IPs to the ignore list in your monitoring software (BFD/LFD)

Your scanner will be throwing a whole lot of traffic at your server. If you are using BFD or LFD, make sure you prevent your server from automatically blocking the scanning server’s ips. Do not explicitally allow the IPs, as that will circumvent the firewall entirely (which negates the closing of the ports), but make sure they are listed in your ignore list.

What to do when your first scan fails: Backporting, and false positives

The first scan you get will have failures, no matter how much preparation you do. We’ll start with the biggest cause: backporting.

In brief, backporting is where Operating Systems take only the security fixes from software updates, and apply them to existing versions of the software. Redhat does an amazing job of explaining backporting:

We use the term backporting to describe when we take a fix for a security flaw out of the most recent version of an upstream software package, and apply that fix to an older version of the package we distribute.

Backporting is common among vendors like Red Hat, and is essential to ensuring we can deploy automated updates to customers with minimal risk. Backporting will be a new concept for those more familiar with proprietary software updates.

For example, say your server has OpenSSH installed. When the folks at OpenSSH are alerted to security flaws, they fix them. At the same time, they may also push new features, but the feature updates may break things that you already have in place. Obviously, you want your server to be secure, but having the secondary impact of the feature updates is less than ideal. Enter backporting. RedHat would apply the fixes from the update, but leave the rest of the package alone.

However, the updates need to be tracked somehow, so RedHat updates the package number. PCI scanners don’t track the package version numbers for all operating systems, so the scan will indicate that the software is not the appropriate version.

Disputes

Your scanner will have a process in place for how they want disputes submitted. Each failure must be disputed individually, which can be frustrating and time consuming. Just make sure you’re paying attention to the details, and you’ll get through it fine. If you run into trouble, or have questions you can’t find an answer for, ask your Hosting provider. They should be willing to help you out.

So now you know

PCI compliance doesn’t have to leave you sleepless for nights on end, nor does it have to cause you significant headaches. It won’t be easy, but it’s worth it.

One more thing:

Never manually upgrade OpenSSL on a cPanel server.

Never manually upgrade OpenSSH on a cPanel server.

---

Resources/Sources/Further Reading:

• http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard
• http://en.wikipedia.org/wiki/Payment_Card_Industry_Security_Standards_Council
• https://www.pcisecuritystandards.org/
• http://www.pcicomplianceguide.org
• http://www.defendyourdollars.org/2005/02/states_with_not.html
• http://docs.cpanel.net/twiki/bin/view/AllDocumentation/PCIComplianceInfo/
• http://www.cpanel.net/videos/common-pci-compliance-issues-with-linux/
• http://usa.visa.com/merchants/new_acceptance/how_it_works.html