Becoming PCI Compliant: Requirements Overview

PCI compliance is a critical factor in the trustworthiness of your business when it comes to handling customers’ credit card information. All the stories of large companies who have had cardholder data leaked reinforce the fact that it’s essential to have proper security around the handling of credit cards. The most common way to evaluate a company’s practices for cardholder data is to see whether or not they are certified PCI compliant. Below is an introduction to the PCI-DSS program (version 3.2 at the time of this writing) and an overview of each requirement.

What is PCI-DSS?

PCI stands for Payment Card Industry and is a general term that refers to the handling of customers’ credit card data from a security perspective. PCI Security Standards Council is the organization that publishes and maintains the PCI Data Security Standard (PCI-DSS), which is the framework that outlines how credit card information should be handled. In order to determine whether a business is PCI compliant, an independent Qualified Security Assessor (QSA) will compare the organization’s existing security controls against the requirements in the PCI-DSS standard, and if they meet or exceed those requirements, the company will be deemed compliant and given a report (called an Attestation of Compliance) stating this. This process must be repeated every year in order for an organization to remain compliant.

Requirements Overview:

Section 1 – Build and Maintain a Secure Network and Systems

This section covers the company’s network infrastructure and consists of two requirements.

Requirement 1: Install and maintain a firewall configuration to protect cardholder data. This requirement covers the installation, configuration, and maintenance of firewalls that are used to protect PCI data. The PCI-DSS document lists several specific configurations that must be in place. In general, this section stipulates that firewalls must only allow authorized network traffic into areas that contain cardholder data, and must block all others. The requirement describes approval processes that must be in place when changes are made to these firewalls, and it also details how often firewall rules and configurations should be reviewed.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters. When network devices are shipped in new condition to a business, they will come with a set of default credentials that are often universal for every device produced by that manufacturer – for example, Firewall X by Manufacturer Y is always shipped with the administrative credentials of “admin” for the username and “password1” for the password. Hackers know this, and if they discover that you’re using Firewall X on your network, they will immediately try to gain access with those credentials. This is why it’s important to change the administrative username and password to something else prior to installing the device. Additionally, the default security configurations on these devices is usually universal as well, so you must change these configurations to something custom for your environment.

Section 2 – Protect Cardholder Data

This section governs how the cardholder data itself should be stored and transferred within your network, and consists of two requirements.

Requirement 3: Protect stored cardholder data. This section covers what data should be stored and how it should be managed while in storage. As a general rule, the only cardholder data that should be stored is that which is actually needed for business operations. If there is no need to store the card number (called the Personal Account Number), it should not be – the same applies to other items such as magnetic strip data, expiration dates, CVV numbers and customer names. A retention schedule should also be implemented which establishes the timeline and manner in which cardholder data will be deleted. Additionally, masking and encryption should be implemented to hide PANs when displayed and encrypt them to prevent unauthorized access.

Requirement 4: Encrypt transmission of cardholder data across open, public networks. This requirement discusses how PCI data should be transmitted when it must be sent across open and unprotected networks, including the internet. The data must be encrypted during transmission using strong encryption (currently, at least TLS v1.2) and must never be transmitted in an unprotected format through messaging systems like IM or SMS.

Section 3 – Maintain a Vulnerability Management Program

This section covers the organization’s handling of security vulnerabilities and consists of two requirements.

Requirement 5: Protect all systems against malware and regularly update antivirus software or programs. This means that a reliable and effective anti-malware system be in place on all systems that process or store cardholder data. Usually, this will take the form of a commercially-available antivirus software, but could also include host-based Intrusion Detection/Prevention Systems and device firewalls. These systems must be regularly updated with the most current definitions and patches available, and an owner must be appointed to see that this is done. They must also be protected against tampering by users.

Requirement 6: Develop and maintain secure systems and applications. This requirement covers two general concepts. First, a vulnerability management program must be in place to allow the organization to identify, track, and remediate the security flaws that it discovers. This includes using scanning software (or hiring a third party to perform such scans) to test areas of the network containing cardholder data and identify any security flaws that are present in these areas. After identifying the vulnerabilities, they should be ranked according to severity (High/Medium/Low) and resolved in a timely manner. The second concept in this requirement is secure application development practices. The PCI-DSS document lists several specific factors and processes that must be in place during the development of applications which handle cardholder data.

Section 4 – Implement Strong Access Control Measures

This section discusses how access should be governed for system components that contain PCI data and has three requirements.

Requirement 7: Restrict access to cardholder data by business need to know. This requirement is straightforward and details the approval processes that must be in place before access can be granted to a system or application containing cardholder data. Users requesting access to these systems must have a legitimate and justified business need, which should be documented and logged prior to granting access. A process owner should be identified who is responsible for approving or denying these requests.

Requirement 8: Identify and authenticate access to system components. This requirement discusses the identification and authentication processes when granting access to systems containing cardholder data. First, a unique user ID should be assigned to every individual user so that actions can be traced back to one specific person during an investigation. Systems must also have security features such as a lockout policy for repeated login attempts, removing inactive user IDs within 90 days, and a timeout period where inactive sessions are automatically terminated after 15 minutes. The requirement also describes acceptable standards for passwords and how user passwords should be managed.

Requirement 9: Restrict physical access to cardholder data. This section discusses all of the physical security measures that must be in place to protect systems that contain cardholder data. Some examples are badge readers for data centers, disabling unused network jacks, escorting visitors in sensitive areas, cameras, locking server racks, and others.

Section 5 – Regularly Monitor and Test Networks

This section covers the monitoring and regular testing of networks containing cardholder data and consists of two requirements.

Requirement 10: Track and monitor all access to network resources and cardholder data. Logging systems must be in place to track user activities as they relate to cardholder data. Enabling logging in all network environments allows tracking, alerting, and analysis in the event of a security breach – determining the cause of an incident is almost impossible if these logs are not in place. These logs must be protected from alteration or destruction, and an audit trail must be implemented so that investigators can review each user’s actions as they pertain to cardholder data.

Requirement 11: Regularly test security systems and processes. This requirement discusses several testing methods and procedures which must be implemented in the network environment. Scans for new wireless access points must be conducted, with unauthorized APs being removed immediately. Internal and external vulnerability scans must be performed at least quarterly and after any significant change to the network. Network Intrusion Detection Prevention Systems (IDS/IPS) should be implemented to monitor for unusual activity in the environment.

Section 6

Requirement 12: Maintain an Information Security Policy

This section has only one requirement, which discusses the overall security policy that applies to all personnel in the organization. It first requires that an information security policy be created, published and communicated to all users of information systems. The policy must include: 1) Roles and responsibilities for information security, 2) Assigned individuals to various security management roles, 3) Procedures to manage service provider relationships when cardholder data is shared with third parties, and 4) an Acceptable Use Policy. This section also outlines the need for two additional programs: a Risk Management program to identify, track, and remediate security risks, and an Incident Response program to establish formal procedures for responding to security incidents.

As you can see, the handling of customers’ credit card information is no simple task. If you want to build your customers’ trust and establish your business as one that takes credit card security seriously, consider implementing the recommendations in this guide to help move your organization toward becoming PCI compliant.