PCI Compliance
You get a call from your client. His business has been accepting credit cards for some time, but today he received a call from his bank. The bank wants him to confirm he’s PCI compliant. He calls you and wants to confirm he’s OK before he responds to his bank. You smack your forehead with the palm of your hand and reach for the aspirin. After taking a deep breath, you explain he’s likely not compliant, but you can review the PCI requirements with him and walk through the steps to get compliant.
Let’s start with the basics.
- The standard is called the Payment Card Industry Data Security Standard (“PCI-DSS”).
- It has twelve requirements.
- These twelve requirements have over 220 sub-requirements.
- Collectively, they are a mixture of technology controls and human processes designed to protect credit cards from getting into the wrong hands.
You can help your client with the technology requirements, but the human controls will be entirely on his end. You can give him advice on the human controls, but it is up to him to police his business to ensure continued compliance. This is not a “one-and-done” project. It requires vigilance on the part of his business.
First, you can give him some good news. Your client’s bank has likely contacted him to submit his annual Self-Assessment Questionnaire. Small merchants are not required to formally validate their compliance. The annual submission of their Self-Assessment is enough. And there’s more good news. Unless your client’s business is in Minnesota, Nevada, or Washington, they are not required by law to be PCI-DSS compliant.
But if your client is not PCI-DSS compliant, they can be fined by Visa/Mastercard and even lose their merchant status which means they can no longer accept credit cards.
- This can happen, even if they never had a breach.
- If they accept credit cards, it’s important they get compliant and stay vigilant.
Secure the Network
In this article, we look at PCI-DSS Requirement 1 – Build and Maintain a Secure Network. There are several moving parts to this requirement, but we can take a short cut to immediately make the task easier.
Let’s establish some terminology. The PCI-DSS specification makes regular reference to the Cardholder Data Environment (“CDE”). The specification is focused on protecting this environment so let’s be clear on what it is. According to specification:
The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. “System components” include network devices, servers, computing devices, and applications.
Pay particular attention to the “store, process, or transmit” phrase. This is a broad brush stroke. It encompasses everything used within the customer’s operation that either comes in contact or could come in contact with credit cards. Even if we focus on the technology side of the environment, this is a large scope. Don’t worry; we’re going to show you how to cut down the scope to make it more manageable.
Before we start discussing solution, we need to review PCI-DSS Requirement 1.2.1 which has some particularly onerous issues:
Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.
This is further expanded by Requirement 1.3.4:
Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
The regulators are clearly saying they expect all merchants to limit access to the Internet. Merchants should allow access only to those parts of the Internet required for the CDE. Everything else must be blocked. To put this more simply, unless the Internet request is to the bank to clear the credit card transaction or to the ecommerce site where the credit card data is coming from, it must be blocked by the firewall.
This is tough.
- It effectively shuts down your client’s use of their Internet for things like surfing, emailing, chatting, and other miscellaneous uses.
- Even if you took the bold stance that surfing, emailing, and whatnot were “necessary” according to the clear language of the requirement, your client would be required to meticulously list each and every host and network that they wanted to allow. This would be an administrative nightmare.
Segmentation to the Rescue
The PCI-DS regulators recognized the conflict they were creating with their requirements. They choose to resolve the conflict by adding the following suggestion to the specification:
Network segmentation of, or isolating (segmenting), the cardholder data environment from the remainder of an entity’s network is not a PCI DSS requirement. However, it is strongly recommended as a method that may reduce:
- The scope of the PCI DSS assessment
- The cost of the PCI DSS assessment
- The cost and difficulty of implementing and maintaining PCI DSS controls
- The risk to an organization (reduced by consolidating cardholder data into fewer, more controlled locations)
Network segmentation is the process of separating the client’s main network from their credit card processing network. The assumption is that the client is using a limited number of systems for processing credit card transactions. Ideally, they may even be using just a single PC running the credit card processing application.
Let’s assume the client is using just a single computer – we’ll refer to this computer as the “Accounting PC”. Creating a segmented architecture is trivially simple. Install a simple router between the client’s main network and their Accounting PC. Presto, you’ve successfully segmented the network.
Dotting the “i”s
Once segmented, there are small details to address.
- First, install the router configured as a NAT. This automatically blocks all inbound traffic to the Accounting PC.
- Next, add basic firewall rules for the router. The rulesets limit what Internet hosts the Accounting PC can access. The rules should list the bank for clearing transactions and if credit card data is coming from an ecommerce website, that site is also allowed. After allowing the required destinations, the firewall rules should finish with a default DENY rule.
A few more items must be addressed.
- The PCI-DSS specification requires the client retain a year of logs. Increase the default retention to this time period. Furthermore, the rules require these logs be ‘retrievable’. The only way to comply with this requirement is to ensure the logs are backed up — preferably offsite to protect from hardware breakdown and filesystem corruption.
- The rules also call for documenting the network segmentation. This documentation comes in three parts.
- The requirement is that the client creates and maintains a network diagram that identifies all components in the CDE.
- The documentation must detail specifically what is permitted and why. In this case you document the ports, protocols, and hosts that you allowed through the firewall.
- and the documentation requires the client record the process the business must go through when they want to make a change to the firewall.
Finally, the PCI-DSS requires the router’s firewall ruleset be reviewed every six months. The motive is to ensure removal of obsolete rulesets. Often, firewall exceptions are made when someone is troubleshooting or dealing with a special exceptional case of access. Review the rulesets bi-annually to be sure exceptions are removed when no longer required.
Closing Thoughts
Segmenting the client’s CDE from the rest of their network solves so many other issues – you should really consider this less of a suggestion from the PCD-DSS regulators and more of a must-do. It makes your client’s compliance tasks easier and reduces his exposure to the risk of fines.
We’ll look at other elements in the PCI-DSS specification in future articles. You can download the latest PCI-DSS specification for free from https://www.pcisecuritystandards.org/document_library .