Payment Card Industry Data Security Standard (PCI DSS)
Definition of Payment Card Industry Data Security Standard (PCI DSS)
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards designed to ensure that ALL companies that accept, process, store or transmit credit card information maintain a secure environment.
The Payment Card Industry Security Standards Council (PCI SSC) was launched on September 7, 2006 to manage the ongoing evolution of the Payment Card Industry (PCI) security standards with a focus on improving payment account security throughout the transaction process. The PCI DSS is administered and managed by the PCI SSC (www.pcisecuritystandards.org), an independent body that was created by the major payment card brands (Visa, MasterCard, American Express, Discover and JCB.). It is important to note that the payment brands and acquirers are responsible for enforcing compliance, not the PCI council.
History of PCI DSS
Five different programs have been started by card companies:
- Visa's Cardholder Information Security Program
- MasterCard's Site Data Protection
- American Express's Data Security Operating Policy
- Discover's Information Security and Compliance
- the JCB's Data Security Program
The intentions of each were roughly similar: to create an additional level of protection for card issuers by ensuring that merchants meet minimum levels of security when they store, process, and transmit cardholder data. To cater out the interoperability problems among the existing standards, the combined effort made by the principal credit card organizations resulted in the release of version 1.0 of PCI DSS in December 2004. PCI DSS has been implemented and followed across the globe.
The Payment Card Industry Security Standards Council (PCI SSC) was then formed and these companies aligned their individual policies to create the PCI DSS. MasterCard, American Express, Visa, JCB International and Discover Financial Services established the PCI SSC in September 2006 as an administration/governing entity which mandates the evolution and development of PCI DSS. Independent/private organizations can participate in PCI development after proper registration. Each participating organization joins a particular SIG (Special Interest Group) and contributes to the activities which are mandated by the SIG.
The following versions of the PCI DSS have been made available:[promotional source?]
1.0 was released on December 15, 2004.
1.1 in September 2006 provide clarification and minor revisions.
1.2 was released on October 1, 2008. It enhanced clarity, improved flexibility, and addressed evolving risks and threats.
1.2.1 in August 2009 made minor corrections designed to create more clarity and consistency among the standards and supporting documents.
2.0 was released in October 2010.
3.0 was released in November 2013 and was active from January 1, 2014 to June 31, 2015.
3.1 was released in April 2015, and has been retired since October 31, 2016.
3.2 was released in April 2016, and has been retired since December 31, 2018.
3.2.1 was released in May 2018.
PCI DSS Objectives
The PCI DSS specifies and elaborates on six major objectives.
- First, a secure network must be maintained in which transactions can be conducted. This requirement involves the use of firewalls that are robust enough to be effective without causing undue inconvenience to cardholders or vendors. Specialized firewalls are available for wireless LANs, which are highly vulnerable to eavesdropping and attacks by malicious hackers. In addition, authentication data such as personal identification numbers (PINs) and passwords must not involve defaults supplied by the vendors. Customers should be able to conveniently and frequently change such data.
- Second, cardholder information must be protected wherever it is stored. Repositories with vital data such as dates of birth, mothers' maiden names, Social Security numbers, phone numbers and mailing addresses should be secure against hacking. When cardholder data is transmitted through public networks, that data must be encrypted in an effective way. Digital encryption is important in all forms of credit-card transactions, but particularly in e-commerce conducted on the Internet.
- Third, systems should be protected against the activities of malicious hackers by using frequently updated anti-virus software, anti-spyware programs, and other anti-malware solutions. All applications should be free of bugs and vulnerabilities that might open the door to exploits in which cardholder data could be stolen or altered. Patches offered by software and operating system (OS) vendors should be regularly installed to ensure the highest possible level of vulnerability management.
- Fourth, access to system information and operations should be restricted and controlled. Cardholders should not have to provide information to businesses unless those businesses must know that information to protect themselves and effectively carry out a transaction. Every person who uses a computer in the system must be assigned a unique and confidential identification name or number. Cardholder data should be protected physically as well as electronically. Examples include the use of document shredders, avoidance of unnecessary paper document duplication, and locks and chains on dumpsters to discourage criminals who would otherwise rummage through the trash.
- Fifth, networks must be constantly monitored and regularly tested to ensure that all security measures and processes are in place, are functioning properly, and are kept up-do-date. For example, anti-virus and anti-spyware programs should be provided with the latest definitions and signatures. These programs should scan all exchanged data, all applications, all random-access memory (RAM) and all storage media frequently if not continuously.
- Sixth, a formal information security policy must be defined, maintained, and followed at all times and by all participating entities. Enforcement measures such as audits and penalties for non-compliance may be necessary.
PCI DSS Compliance levels
PCI compliance is divided into four levels, based on the annual number of credit or debit card transactions a business processes. The classification level determines what an enterprise needs to do to remain compliant.
- Level 1: Applies to merchants processing more than six million real-world credit or debit card transactions annually. Conducted by an authorized PCI auditor, they must undergo an internal audit once a year. In addition, once a quarter they must submit to a PCI scan by an Approved Scanning Vendor (ASV).
- Level 2: Applies to merchants processing between one and six million real-world credit or debit card transactions annually. They’re required to complete an assessment once a year using a Self-Assessment Questionnaire (SAQ). Additionally, a quarterly PCI scan may be required.
- Level 3: Applies to merchants processing between 20,000 and one million e-commerce transactions annually. They must complete a yearly assessment using the relevant SAQ. A quarterly PCI scan may also be required.
- Level 4: Applies to merchants processing fewer than 20,000 e-commerce transactions annually, or those that process up to one million real-world transactions. A yearly assessment using the relevant SAQ must be completed and a quarterly PCI scan may be required.
The 12 PCI DSS Requirements
- PCI DSS Requirement 1: Protect your system with firewalls: The first requirement of the PCI DSS is to protect your system with firewalls. Properly configured firewalls protect your card data environment. Firewalls restrict incoming and outgoing network traffic through rules and criteria configured by your organization.
- PCI DSS Requirement 2: Configure passwords and settings: You shouldn’t keep vendor-supplied defaults around. Out-of-the-box devices, such as routers or POS systems, come with factory settings like default usernames and passwords. Defaults make device installation and support easier, but they also mean that every model originates with the same username and password. Default passwords are simple to guess, and most are even published on the Internet.
- PCI DSS Requirement 3: Protect stored cardholder data: The point of the 12 requirements of PCI is to protect and secure stored cardholder data and prevent data breaches. And according to requirement 3, stored card data must be encrypted using industry-accepted algorithms (e.g., AES-256). The problem is many merchants don’t know they store unencrypted primary account numbers (PAN). Not only must card data be encrypted, the encryption keys themselves must also be protected. For example, using a solid PCI DSS encryption key management process will help keep you from storing the key in the “lock” itself.
- PCI DSS Requirement 4: Encrypt transmission of cardholder data across open, public networks: You then need to use encryption and have security policies in place when you transmit this cardholder data over open, public networks. For requirement 4, you need to know where you send cardholder data. Here are common places where primary account numbers (PAN) are sent:
- Backup servers
- Third parties that store or handle PAN
- Outsourced management of systems or infrastructure
- Corporate offices
- PCI DSS Requirement 5: Use and regularly update anti-virus software: Anti-virus software needs to be installed on all systems commonly affected by malware. Make sure anti-virus or anti-malware programs are updated on a regular basis to detect known malware. Maintaining an up-to-date anti-malware program will prevent known malware from infecting systems.
- PCI DSS Requirement 6: Regularly update and patch systems: Be vigilant and consistently update the software associated with your system. Requirement 6.2 states merchants must “install critical patches within a month of release” to maintain compliance. Don’t forget to update critical software installations like credit card payment applications and mobile devices. To stay updated, ask your software vendors to put you on their patch/upgrade notification list. Quickly implementing security updates is crucial to your security posture. Patch all critical components in the card flow pathway, including:
- Internet browsers
- Application software
- POS terminals
- Operating systems
- PCI DSS Requirement 7: Restrict access to cardholder data by business need-to-know: Configure administrator and user accounts to prevent exposure of sensitive data to those who don’t need this information. To fulfill requirement 7, you need a role-based access control (RBAC) system, which grants access to card data and systems on a need-to-know basis. PCI DSS 3.2 requires a defined and up-to-date list of the roles (employees) with access to the card data environment. On this list, you should include each role, the definition of each role, access to data resources, current privilege level, and what privilege level is necessary for each person to perform normal business responsibilities. Authorized users must fit into one of the roles you outline.
- PCI DSS Requirement 8: Assign a unique ID to each person with computer access: According to PCI DSS requirement 8, user IDs and passwords need to be sufficiently complex and unique. You should not use group or shared passwords. However, your system security should not be based solely on the complexity of a single password. No password should be considered “uncrackable,” which is why, as of February 1, 2018, all non-console administrative access (remote access) to in-scope systems requires multi-factor authentication.
- PCI DSS Requirement 9: Restrict physical access to workplace and cardholder data: Requirement 9 states that you must physically limit access to areas with cardholder data, as well as document the following:
- Who has access to secure environments and why they need this access
- What, when, where, and why devices are used
- A list of authorized device users
- Locations where the device is and is not allowed
- What applications can be accessed on the device
You will also need to implement automated lockout/timeout controls on workstations, periodically inspect all devices, and most importantly—train your staff regularly about physical security, policies and procedures, and social engineering
- PCI DSS Requirement 10: Implement logging and log management: System event logs are recorded tidbits of information regarding actions taken on computer systems like firewalls, office computers, or printers. To fulfill requirement 10, you must review logs at least daily to search for errors, anomalies, and suspicious activities that deviate from the norm. You’re also required to have a process in place to respond to these anomalies and exceptions.
- PCI DSS Requirement 11: Conduct vulnerability scans and penetration tests: Your data could be left vulnerable due to defects in web servers, web browsers, email clients, POS software, operating systems, and server interfaces. Fulfilling requirement 6 (installing security updates and patches) can help correct many of these defects and vulnerabilities before attackers have the opportunity to leverage them. But in order to be sure you’ve successfully patched these vulnerabilities, you need to be able to find them and test them. For that you need to perform regular vulnerability scanning and penetration testing. A vulnerability scan is an automated, high-level test that looks for and reports potential vulnerabilities. All external IPs and domains exposed in the CDE are required to be scanned by a PCI Approved Scanning Vendor (ASV) at least quarterly. A penetration test is an exhaustive, live examination designed to exploit weaknesses in your system. Just like a hacker, penetration testers analyze network environments, identify potential vulnerabilities, and try to exploit those vulnerabilities (or coding errors). Basically, these analysts attempt to break into your company’s network.
- PCI DSS Requirement 12: documentation and risk assessments: The final requirement for PCI compliance is to keep documentation, policies, procedures, and evidence relating to your company’s security practices. If you perform a PCI audit, you’ll quickly pick up on the fact that there’s a big emphasis on your documented security policies and procedures. During an assessment, QSAs will typically verify that specific requirements are defined in company policies and procedures. Then, they’ll follow predefined testing procedures to verify that those controls are implemented in accordance with the PCI Data Security Standard and with written company policies. You will need to include the following information in your documentation:
- Employee manuals
- Policies and procedures
- Third-party vendor agreements
- Incident response plans
The second part of requirement 12 is to perform an annual, formal risk assessment that identifies critical assets, threats, and vulnerabilities. This requirement will help you identify, prioritize, and manage your information security risks.
Security Reference Model (SRM)
Information Security Governance
Adaptive Security Architecture (ASA)
Business Model for Information Security (BMIS)
Common Data Security Architecture (CDSA)
Federal Information Security Management Act (FISMA)
Enterprise Information Security Architecture (EISA)
Fault Configuration Accounting Performance Security (FCAPS)
Information Systems Security (INFOSEC)
Information Security Management System (ISMS)
Information Technology Security Assessment