PCI for SMB – Requirement 2- Do Not Use Defaults

Update: Read our new PCI Compliance guide.

If you have an ecommerce website and you accept credit cards from your clients, you probably already heard of the term PCI compliance.

PCI DSS (Payment Card Industry – Data Security Standard) is a standard containing series of security requirements that every merchant, big or small, must follow to be in compliance. PCI was created and is mandated by the five major credit card companies: Visa, MasterCard, American Express, Discover, and JCB.

Every merchant falls under PCI, even if you do not handle a large volume of transactions or use external providers to outsource your credit card and billing processing. Yes, even if you use Stripe, Recurly, or Paypal, you still have to follow the PCI requirements to be in compliance.

In this series of articles, we talk about PCI and how it affects SMBs (small to medium sized businesses) that are going through the compliance process using the PCI SAQ’s (Self Assessment Questionnaires). Here are the articles we have written about PCI in the past:

Part 0: Intro to E-Commerce and PCI Compliance

• Part I: PCI for SMB: Requirement 1- Install and Maintain a Firewall

Requirement 2: Build and Maintain a Secure Network

Do not use vendor-supplied defaults for system passwords or other security parameters.

Continuing with our series we will dive into requirement #2, which is probably the most important one. The requirement is named “do not use vendor-supplied defaults.” This requirement addresses what we have been saying for years in terms of server isolation, hardening, and taking the basic steps to securely deploy applications and servers.

To address requirement #2, you have to fully integrate the idea of security into your deployment and management strategies. If you can account for these three core domains in your overall security strategy, you will effectively account for this requirement:

1. Functional Isolation
2. Minimalistic Install
3. Application Hardening

1- Functional Isolation

The first thing to do is isolate your servers and access per business function. You can’t have a “do it all” server, either in terms of function (i.e., DB, file, email, web), lifecycle phase (i.e., production, staging, testing), or user access. This is the biggest mistake you can make as a small business owner, and will be the biggest roadblock to achieving good security and compliance with PCI.

This applies to how you manage all of your websites as well. This is especially challenging because, by design, most shared hosts facilitate the opposite of this requirement (i.e., a one to many ratio between a single account and number of sites on each server). Doing so breaks the the functional isolation rule as defined here. Additionally, if you are hosting your email server, DNS, or any other service required for your business to function, they have to be isolated as well.

Practical example: If you have a blog running WordPress and an ecommerce store running Magento, they should be on different servers. It also helps by cutting down your CDE (credit card data environment) scope.

2- Minimalistic and Secure Install

You should take a minimalist approach to installing and configuring your applications. If you are using Linux, you should use the minimal install option that comes with the bare bones of the distribution. Install only the applications you will need, nothing more.

It’s not as simple as running the famous 5 minutes install for WordPress, configuring your Woocommerce plugin and moving on. For every new application you are installing, you have to research the recommended secure way to install, follow the recommended hardening tips, then most importantly, document.

Practical example: If you are deploying a new server, you have to choose the minimal install and only install the required tools for the server business function. If you are deploying a new Magento site, all you need is a web service (Apache or Nginx), PHP, MySQL and that’s it. Nothing else should be running.

3- Application Hardening

Once everything is installed and running, you need to follow the recommended hardening guides for each one. This applies to the whole stack. A web server will require the operating system hardening (e.g., Linux), the web server hardening (e.g., Apache, NGINX) and the CMS or web application hardening (i.e., Magento, WordPress).

Here is a very simple example based on a web server running Magento on the CentOS (Linux) distribution. These are some of the things you will have to do:

Install the minimal version of CentOS 7 (latest version)

1. Install httpd, php and mysql
2. Enable SSH via a unique username and use SSH keys (disable password authentication)
3. Configure the server firewall (iptables) to restrict all access except to port 80, 443

Update all current packages and put a process in place to update weekly

1. Install Magento
2. Restrict access to the Magento admin panel to whitelisted addresses
3. Install ModSecurity (or a cloud-based WAF) between external traffic and the Magento website
4. Install a tool to export all logs and send them to a central log location (i.e., OSSEC)

These steps are obviously very rudimentary, but they are aligned with the intentions of the PCI requirement. Personally, I recommend starting with checklists such as the ones provided by the Center for Internet Security (CIS). They provide one for the Red Hat Enterprise Linux 7 benchmarks, and the Apache HTTP Server 2.4 benchmark. These checklists can be long, but they are comprehensive and provide a great workflow to ensure things are not forgotten.

PCI Requirement 2

When you consider the steps above, along with the steps provided in the first article on PCI compliance, you start to see the development of a good security framework. This framework is at the core of the intention behind the PCI standards.

The proposed approach should help you quickly account for each requirement. Where things might not be as seamless are with environments that were developed and built with little regard to security. This is where compliance usually becomes problematic, time-consuming, and costly.

I recommend thinking about functional isolation early, migrating sites to clean servers that can be properly audited and secured. If you have a multiple sites on a server or account, the risk of issues with cross contamination and compliance is very high.