PCI Council announces that new requirements will be considered “best practices” until compliance becomes mandatory on Feb.1, 2018The Payment Card Industry (PCI) Security Standards Council (PCI Council) released Version 3.2 of the PCI Data Security Standard (PCI DSS), containing several new requirements for merchants, acquirers, and other entities that accept, transmit or store cardholder data in order to protect customer payment card information. The new release focuses on mitigating current vulnerabilities identified in data breach reports, including those presented by third party service providers, authentication protocols, and outdated encryption. The changes are also intended to help companies maintain and effectively test compliance between annual PCI assessments. PCI DSS v. 3.2 Focuses on Vulnerabilities Identified in Breach Reports The PCI DSS Version 3.2 (agreement required) is now available for use, and will officially replace the current PCI DSS Version 3.1 on Oct. 31, 2016. Accordingly, all PCI DSS assessments taken on or after November 1 must evaluate compliance against Version 3.2. However, the new requirements contained in the latest version will be considered “best practices” until Feb. 1, 2018 to give entities enough time to implement necessary changes and come into compliance. Consequently, February 1, 2018 is the mandatory deadline for companies contractually required to be “PCI compliant” to review and change their security practices and procedures to ensure compliance with the new requirements and avoid fines, fees, and other assessments. What’s New in PCI DSS v.3.2? Multi-Factor Authentication Companies will soon be required to use multi-factor authentication for administrative access to the cardholder data environment. Version 3.2 includes some important changes to the present standard, including requiring multi-factor authentication for all non-console administrative access to the cardholder data environment. Multi-factor authentication requires the use of two or more credentials to authorize a person’s access to card data and systems. Different authentication factors include (i) something you know - such as a password; (ii) something you have - such as a token or device code; or (iii) something you are - such as biometric data like a fingerprint. Under the prior release, the PCI DSS only required “two-factor” authentication for any remote access into the cardholder data environment. Version 3.2 adds the requirement that all “non-console” administrative access, even when accessed by an employee from the company’s internal network, must employ multi-factor authentication. Thus, anyone that has “administrative access” rights will need to use multi-factor authentication to access the cardholder data environment. While two-factor authentication is considered a type of multi-factor authentication, the PCI Council’s standard under Version 3.2 requires that a company must use a minimum of two credentials. Additionally, the PCI Council cautions that using one authentication method twice – for instance, requiring users to provide two separate passwords – does not count as multi-factor authentication under PCI DSS. Companies should verify that their authentication protocols meet the PCI Council’s multi-factor standard. Service Provider Requirements Version 3.2 contains several new requirements for service providers, including consolidating and integrating existing criteria for additional assessments for certain service providers. Version 3.2 integrates the PCI Designated Entities Supplemental Evaluation (DESV) – previously a stand-alone document – into the PCI DSS at Appendix A3. The DESV is a set of validation requirements intended to help service providers and others address identified challenges and adopt ongoing security efforts to protect payment data. Although these supplemental validation requirements for service providers do go above and beyond the standard PCI DSS requirements, Troy Leach, PCI Security Standards Chief Technology Officer, clarifies that many are simply extensions of “existing PCI DSS requirements that should be demonstratively tested more regularly, or require more evidence that the control is in place.” Additionally, even though the DESV is now integrated into the PCI DSS, an entity is only required to be assessed under the DESV requirements if an acquirer or a payment brand specifically instructs a service provider to do so. Key requirements include measures for their own effective compliance program oversight, correct scoping of the PCI environment, and placing effective mechanisms to allow a company to detect and trigger alerts for failures in critical security controls. Since service providers are an integral part of securing cardholder data, and third parties have been identified as a weak link in data breach reports, Version 3.2 also adds a number of significant changes requiring service providers to:
- Maintain documented description of cryptographic architecture, including details of all algorithms, protocols, and keys for the protection of cardholder data (Req. 3.5.1);
- Implement processes to timely detect, report and respond to failures of critical security control systems, including, but not limited to, failures of firewalls, anti-virus, physical and logical access controls, audit logging mechanisms, and segmented controls (if used) (Req. 10.8);
- Confirm PCI DSS scope by conducting penetration testing at least every six months and after any change to segmentation controls or methods (Req. 188.8.131.52);
- Engage executive management in establishing responsibility for the protection of cardholder data and PCI DSS compliance program (Req. 12.4.1); and
- Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures, including daily log reviews; firewall rule-set reviews; applying configurations to new systems; responding to security alerts and to changes in management processes (Req. 12.11).
- SSL/early TLS sunset extended. Although previously announced, the PCI Council formally delays one significant deadline in Version 3.2 by extending the SSL and early Transport Layer Security (TLS) sunset date set by Version 3.1 from June 30, 2016, to June 30, 2018, giving an additional two years to migrate away from these popular-but-outdated encryption standards. If your company is still using these now-outdated encryption methods, you are required to prepare a formal “Risk Mitigation and Migration Plan” in the interim. However, it is recommended that your company move from these encryption protocols as soon as possible; as we have noted previously, SSL and early TLS do not meet the PCI’s mandatory requirements for strong encryption.
- “Masking” PANs. Version 3.2 clarifies the existing requirement to "mask" payment card account numbers (PANs) so as to only display, at most, the first six and the last four digits and advises companies to ensure that “only the minimum number of digits is displayed” to perform a specific business function. The prior version simply stated that personnel with a legitimate business need may see the full PAN, while Version 3.2 clarifies that there must be a legitimate business need to view PANs longer than the first six/last four digits (Req. 3.3 and related guidance).
*Originally developed in conjunction with and published by NetDiligence, an enterprise-level cyber risk assessment and data breach services company.
Please contact Amy Mushahwar with any inquiries at 202.973.4263.