Posted on Jul 26, 2017
PCI compliance is a critical factor in the trustworthiness of your business when it comes to handling customers’ credit card information. While PCI compliance does not equal bulletproof security of credit card data, it does set a bar for companies who transmit, store, or process credit card data must meet. The Payment Card Industry Data Security Standard (PCI DSS) is this bar for those companies- It’s most recent 3.2 version has all the robustness of the prior version with a few added modifications and additions.
The standard is split into six sections for a total of twelve requirements. For new businesses subjected to PCI compliance, we’ll provide an overview sections one through three of PCI DSS 3.2 in this post and sections four through six in another post.
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 stating this, called an Attestation of Compliance. This process must be repeated every year in order for an organization to remain compliant.
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.
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.
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.
These 6 requirements are detailed, specific and come with a plethora of sub-requirements- and this is only half the battle. Check back in for our overview of Sections four through six. (In the meantime, you can also reference the document library at the PCI Security Standards Council site for more resources on this topic.)
Check out our list of 3 top third party risk management (TPRM) challenges, and the actions you can take to bolster your program. Learn more.
Performing cybersecurity risk assessments is a key part of any organization’s information security management program. Read our guide.
Templates and vendor evaluations are needed to level that playing field, in a time efficient and fair way, so that the best vendors are chosen.
Co-founder and CEO, Alex Yampolskiy, speaks about the importance of measuring and acting on key indicators of cybersecurity risk.
You’ve invested in cybersecurity, but are you tracking your efforts? Check out our list of 20 cybersecurity KPIs you should track. Read more.
No waiting, 100% Free
Get your free scorecard and learn how you stack up across 10 risk categories. Answer a few simple questions and we'll instantly send your score to your business email.