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

Update: Read our new PCI Compliance guide.

If you have an ecommerce website, allowing you to accept credit cards on your site, PCI compliance should not be a new concept or term. PCI DSS (Payment Card Industry – Data Security Standard) is a standard that was established in a collaborative process between the major credit issuers – Visa, MasterCard, Discover, American Express and JCB – to help merchants protect their payment systems from breaches and theft of cardholder data.

If you operate an eccommerce site, PCI compliance is a requirement. Compliance is not dictated by the volume of transactions, or restricted solely to storage, transmission, and processing; it applies to any business that accepts credit cards. What this means is that even if leveraging services like Stripe, Recurly, PayPal (or any of the number of secure payment options available) as a business owner you have an obligation to follow the requirements as set forth by PCI DSS.

In this series of articles, we will talk about PCI and how it affects SMB’s (Small / Medium sized businesses) that are going through the compliance process using the PCI SAQ’s (Self Assessment questionaries).

PCI Requirements

The latest version of PCI DSS is version 3.2, released April 2016. There are 12 requirements distributed between 6 core domains:

The core 12 requirements are divided into multiple sub requirements and hundreds of actions. At first glance, it can feel like a daunting task for a small website owner. In this series we hope to provide a simplistic approach to addressing each.

We will explain each PCI requirement in practical terms, and design our insights for small to medium businesses that are using their own limited infrastructure (i.e., small number of servers, leveraging cloud-based servers and external providers for payment processing.). If you’re a larger organization, please defer to your Qualified Security Assessors (QSA) and/or Internal Security Assessors (ISA) for instructions. For everyone else using the Self Assessment Questionnaires (SAQs), this is a good place to start.

Requirement 1: Build and Maintain a Secure Network – Install and maintain a firewall configuration to protect cardholder data.

The very first requirement is about securing and documenting your network. The high level guidance to “Build and Maintain a Secure Network” itself is very generic and ambiguous, which is why the PCI standard breaks the first requirement into five subcategories (1.1, 1.2, 1.3, 1.4 and 1.5), which within themselves have multiple detailed requirements.

If you are going through the PCI assessment process filling out the SAQ (Self Assessment Questionnaries), this is what I would recommend:

1. Take a good look at your network and servers and how they talk and connect to each other. I would recommend creating a “Firewall Process” document where you write down and list all your servers, what they do, who has access to them, what’s externally accessible, and the kind of services running on each box. Create diagrams so you can visualize all connections and make sure there are no mistakes. You can use a simple tool like LucidChart to assist you in the process. This document can be of dual purpose, to account for the change control process specific to the server environment. This seems more daunting a task than when you actually start doing it.
2. Based on that document, create a firewall rule that blocks everything, only allowing what is needed for the server required business functions. Yes! Block all and only allow what is needed, both inbound and outbound. This is a security by default mindset, and employs a whitelist approach which is more effective than maintaining a blacklist configuration.
3. Write your rules into the document and apply to all your servers.

By taking these steps, you will be following the spirit of PCI requirement 1, which is to a) know your assets and b) restrict and separate access between environments through the employment of a firewall. For example, if you look at requirements 1.1, 1.2, 1.3 and 1.5:

1.1 Establish and implement firewall and router configuration standards.

1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.

1.3 Prohibit direct public access between the internet and any system component in the cardholder data environment.

1.5 Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.

You would be covered with a restrictive, deny-all by default rule set. That’s not always easy to do, but by having that setup, you will not only be compliant, you’ll have a much more secure network (which is the objective of PCI in the first place). What you want to avoid is a checkmark mentality. You can be compliant but insecure, if you’re secure you’re most likely going to be compliant.

One section that is not covered there, is 1.4, which requires a personal firewall on any device that connects to the Card Data Environment (CDE). For this requirement, you will need a list of every employee that has access to servers that have access to the CDE. Ensure they have a firewall on the devices they use to connect to the environment. A great approach is to leverage a JumpBox, so that there is no direct access to the CDE environment from the individual’s box without going through JumpBox. Whether the JumpBox does or does not do away with the requirement for the end user’s machine is completely up to your assessor to make that determination. For reference, requirement 1.4 says:

1.4 Install personal firewall software or equivalent functionality on any portable computing devices (including company and/or employee-owned) that connect to the internet when outside the network (for example, laptops used by employees), and which are also used to access the CDE.

Example of Firewall Process Documentation

Here is an example of a Firewall Policy and Procedures document that you can use to be in compliance with PCI. In this example, the Business “My Company” only has one server hosted at Amazon AWS and they use Recurly’s JS for their secure payment process.

Because “My Company” is using Recurly.js it controls how the information is presented to the card holder and as such needs to comply with the new PCI DSS Self-Assessment Questionnaire A-EP.

Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor;

Sample Document

My Company - Firewall Policy

last modified: date
last revision: date

In order to maintain a secure network, all access to our servers will be fully 
restricted on a deny-by-default basis, where only the services needed for our 
business will be allowed.

We have one server with these ports opened:

web.server: allowed ports: 80 (http), 443 (https) and 22 (ssh).

Port 80 (clear text HTTP) will be opened only to redirect to port 443 (HTTPS) 
and both ports will be opened to the world, as our clients need it to visit 
the site. Port 22 will be restricted to only these 3 static IP addresses used 
by our 2 administrators:

-admin1: IP1
-admin2: IP2 and IP2

diagram 1

diagram 2

iptables rule:

# We block all by default
iptables -I INPUT -j DROP
iptables -I OUTPUT -j DROP

# We allow HTTP and HTTPS:
iptables -A INPUT -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT

# We allow SSH for the whitelisted IP addresses
iptables -A INPUT -p tcp --dport 22 --source IP1 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 --source IP2 -m state --state NEW,ESTABLISHED -j ACCEPT
..

change control:

-date2: Firewall rules tested and applied to server
-date1: Document created.

As you can see, you do not need anything formal. A simple document will work if all requirements are addressed, and it’s maintained and current.

With the rest of PCI requirements, while scary at first, achieving it is more attainable than most assume. Most are common sense security best practice that everyone should follow. In fact, even if you aren’t a merchant it would do you a lot of good to read through the documentation; there are excellent recommendations that as security professionals we take for granted but for those just starting out can be a great security framework to start from.

If you have any questions, let us know, we’re here to help. You can engage us via the comments below.