The Payment Card Industry Security Standards Council (PCI SSC) has released a new version of its data security standard for the protection of cardholder data, the Payment Card Industry Data Security Standard (PCI DSS). PCI DSS applies to all entities involved in payment card processing, including merchants, processors, acquirers, issuers, and service providers as well as all other entities that store, process, or transmit cardholder data and/or sensitive authentication data. PCI DSS is administered by the PCI SSC, which was founded by American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc.
The newly published version, PCI DSS version 3.2 (PCI DSS 3.2), contains the following three types of changes:
- Clarifications to existing requirements. An example is changing the naming convention from “two-factor authentication” to “multi-factor authentication” clarifying that a minimum of two credentials are required to authorize a person’s access to card data and systems).
- Additional guidance on certain topics. An example is the added guidance with respect to the relationship between Payment Applications Data Security Standard (PA-DSS) and PCI DSS) that as security threats are constantly evolving, applications that are no longer supported by the vendor may not offer the same level of security as supported versions.
- Evolving requirements (updated and new requirements) for administrators accessing the cardholder data environment, service providers, and the cardholder data environment, to address current threats to cardholder data. The following are the key updated and new requirements:
- Updated requirement for primary account number (PAN) masking to ensure that any display of PAN greater than the first six/last four digits of the PAN requires a legitimate business need (Section 3.3 of PCI DSS 3.2). This requirement does not supersede stricter requirements in place for displays of cardholder data (e.g., legal or payment card brand requirements for point-of-sale (POS) receipts).
- New requirement for change control processes to ensure that upon completion of a significant change, all relevant PCI DSS requirements are implemented on all new or changed systems and networks, and documentation is updated as applicable (Section 6.4.6)
- New requirement for multi-factor authentication for any personnel with non-console administrative access to the cardholder environment, so that a password alone is not enough to verify the user’s identity and grant access to sensitive information, even from within a company’s own network (Section 8.3.1 of PCI DSS 3.2). This requirement does not apply to applications or system accounts performing automated functions (e.g. machine authentication where one system is communicating with the other) and it does not apply to administrators accessing the cardholder environment directly from the console.
- The following new requirements for service providers:
- Implement a process for timely detection and reporting of failures of critical security control systems (e.g., firewalls, IDS/IPM, FIM, Anti-Virus, Physical Access Controls, Logical access controls, audit logging mechanisms, segmentation controls) and respond to failures of any critical security controls in a timely manner (Section 10.8, 10.8.1 of PCI DSS 3.2);
- Perform penetration testing on segmentation controls (if segmentation is used) at least every six (6) months and after any changes to segmentation controls/methods (Section 220.127.116.11);
- Executive management of service providers must establish responsibilities for the protection of cardholder data and a PCI DSS compliance program (Section 12.4 of PCI-DSS 3.2) that includes overall responsibility for maintaining PCI DSS compliance and defining a charter for a PCI DSS compliance program and communication to executive management; and
- Perform reviews at least quarterly to confirm that personnel are following security policies and operational procedures and maintain documentation of the quarterly review process; the reviews must cover the following processes: daily log reviews, firewall rule-set reviews, applying configuration standards new standards, responding to security alerts, and change management processes (Section 12.11 and 12.11.1 of PCI DSS 3.2).
PCI DSS 3.2 also includes two new appendices: (1) Appendix A2 which includes additional requirements for entities using Secure Socket Layer (SSL)/early Transport Layer Security (TLS) with new migration deadlines for the removal of SSL/early TLS, and (2) Appendix A3 which incorporates the Designated Entities Supplemental Validation (DESV), previously a separate document.
A summary of all the changes from PCI DSS version 3.1 (PCI DSS 3.1) to PCI DSS 3.2 can be found here. These changes were determined based on the PCI SSC’s standard update process consisting of industry feedback from the PCI SSC’s 700+ participating organizations throughout the world, data breach report findings, and changes in payment acceptance.
PCI DSS version 3.1 expires on October 31, 2016 at which time PCI DSS 3.2 must be used for PCI DSS assessments. All the new requirements under PCI DSS 3.2 are “best practices” until January 31, 2018 to permit covered organizations to implement the changes. Starting on February 1, 2018, the new requirements are effective as requirements.
Nearly 80% of businesses fail their interim PCI compliance assessment, leaving them vulnerable to cyber attacks, according to Verizon’s 2015 PCI Compliance Report. The report also showed only 29% of companies remain fully compliant with the PCI DSS standard less than a year after being awarded their compliance certificate.
Failure to properly implement changes to PCI DSS can result in fines or imposed by card brands, or even the loss of the right to process credit cards in the event of a breach.