On November 1, 2016, the Payment Card Industry (“PCI”) Security Standards Council’s newest set of Data Security Standards (“DSS”) went into effect. Announced earlier this year, PCI DSS Version 3.2 has made a variety of changes applicable to both merchants that accept payment cards as well as “Service Providers,” which are defined as third-party entities that “store, process, or transmit cardholder data” or that “manage components such as routers, firewalls, databases, physical security, and/or servers” on behalf of merchants. Below, we provide a summary of some of the more significant changes that affect merchants and Service Providers.
Changes Affecting Merchants
The following are some of the more significant changes in the PCI DSS 3.2 for merchants:
- Expanded Multi-Factor Authentication Requirements (Section 8.3): Although this section on access to the Cardholder Data Environment (CDE) is not new, in Version 3.1 (which we have previously covered on this blog), this requirement stated that organizations needed to implement “two-factor authentication” for access to the CDE that originated from outside the network. In Version 3.2, the section has been revised to require “multi-factor authentication” for all “non-console” administrative access to the CDE, even when accessed by an employee from within the company’s network. This means that anyone with “administrative access” rights will need to use multi-factor authentication to access the cardholder data environment. Also notable is the shift from using the term “two-factor authentication” to “multi-factor authentication.” The guidance explains that while two-factor authentication is considered a type of multi-factor authentication, the updated standard in Version 3.2 requires that a company must use a minimum of two credentials. Additionally, the PCI Council explains that organizations must use “two separate forms of authentication,” meaning that using a single authentication method twice (e.g., using two separate passwords) would not qualify as “multi-factor authentication” under PCI DSS. The requirement to incorporate multi-factor authentication within the network is considered a “best practice” until January 31, 2018, at which time it will become a requirement.
- Change Control Processes (Section 6.4.6): Version 3.2 adds requirement 6.4.6, which requires entities to verify that PCI DSS requirements are intact following a “significant change” to the environment. The guidance provides examples of the types of things that may be required following a significant change to in-scope networks and systems, including: assessing and documenting the changes, checking configurations, updating documentation such as network diagrams, and ensuring that any new additions, such as new hardware and applications, are subject to regular security testing such as monthly vulnerability scanning. Once again, this requirement is considered a best practice until January 31, 2018, when it will become a formal requirement.
- Extended migration dates for SSL/early TLS: The PCI Council had previously removed Secure Sockets Layer (SSL) as an example of strong encryption from the PCI DSS once it had become clear that serious vulnerabilities existed in SSL and early Transport Layer Security (TLS) encryption protocols, and stated that these protocols could no longer be used as a security control after June 30, 2016. In Version 3.2, the PCI Council has delayed this deadline, extending the SSL and early TLS sunset date set in Version 3.1 to June 30, 2018. This provides organizations an additional two years to migrate away from these popular-but-outdated encryption standards. Notably, Version 3.2 requires organizations currently using these protocols to prepare a formal “Risk Mitigation and Migration Plan” in the interim. Version 3.2 also includes a migration appendix to help companies make the transition in a logical manner.
Changes Affecting Service Providers
Additionally, there are some significant changes that affect Service Providers, including:
- Executive Management Responsibility (Section 12.4.1): Executive management for Service Providers are required to “establish responsibility” for the protection of cardholder data and a PCI DSS compliance program. According to the guidance, this is intended to “ensure[] executive-level visibility into the PCI DSS compliance program.”
- Quarterly Personnel Reviews (Section 12.11): Service Providers are required to confirm that personnel are following security policies and operational procedures, including by reviewing daily logs; reviewing firewall rule-sets; applying configurations to new systems; and responding to security alerts and to changes in management processes. The intent of this requirement is to confirm that the Service Providers’ employees are following procedures as expected.
- Detecting and Reporting Failures of Critical Security Control Systems (Section 10.8): Service providers are required to implement a process designed to timely detect and report on failures of critical security control systems so that action can be taken as soon as possible before an attacker has an opportunity to steal data. The security control measures described in the requirement include firewalls, intrusion prevention systems, antivirus software, access controls, audit logging mechanisms, and segmentation controls. Section 10.8.1 goes into detail about the actions which should be taken when a failure occurs, including documenting the cause, duration, and remediation required, restoring functionality, and performing a risk assessment to prevent future occurrences.
- Penetration Testing on Segmentation Controls (Section 11.3.4.1): Another new addition in Version 3.2 requires Service Providers to conduct regular penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods. This requirement builds on the existing requirement that organizations annually demonstrate that their segmented environment was successfully isolated.
As with the changes for merchants, each of the above changes for service providers will not be formally required until January 31, 2018, and are considered best practices in the interim.
Our Take
For merchants, the changes found in Version 3.2 do not appear particularly onerous. Many are minor revisions to previous requirements and one, the SSL/early TLS phase-out, actually extends the deadline for merchants to ease the transition away from these protocols which are being used by a number of organizations. However, Version 3.2 imposes some significant new obligations on third-party Service Providers that may require significant changes in their operations. As outlined above, however, Version 3.2 has built-in a transition period that permits both merchants and Service Providers a grace period—considering many of the substantial changes “best practices” until January 31, 2018, when they come formal requirements.
According to its press release, the PCI Council intends that these changes be designed to address “growing threats to customer payment information” and to help prevent, detect, and respond to the issues seen in many of the payment card breaches affecting various companies. Based on our experience in helping organizations respond to these incidents, we believe that many of these changes do indeed address some of the key issues that lead to the exposure of payment card information. For example, with respect to the changes to Section 8.3 (Multi-Factor Authentication), the revisions are intended to reduce the chances that an unauthorized individual can gain access to the portions of a merchant’s environment that would allow them access to the cardholder data by ensuring that anyone with this level of access must first complete a minimum of two stages of authentication. Poor authentication processes frequently cause or serve as a significant contributing factor in a great number of payment card breaches, so this revision appears intended to directly address that type of vulnerability. Section 6.4.6 (Change Controls) appears to be aimed at ensuring constant maintenance of security measures in order to remain PCI DSS compliant. This requirement attempts to address the potential gap in compliance that might occur when changes to an environment are made between annual PCI DSS assessments. Absent this requirement, an organization could make changes to its payment card processing systems throughout the year that significantly change compliance status of the environment, but would not have been required to assess any compliance gaps until the next assessment was performed, potentially leaving vulnerabilities for an extended period of time.
There are two notable takeaways from the shift to Version 3.2 that do not relate to specific changes or new requirements, but rather represent potential shifts in the approach to PCI DSS compliance. First, many of the requirements and guidance appear to be intended to position the implementation and maintenance of PCI DSS compliance as an ongoing, business-as-usual process, as opposed to a specific assessment performed at a particular point in time. Although the assessments themselves continue to be done at a single point in time, it appears that the PCI Council, through revisions like those in Section 6.4.6 to Change Control Processes, seek to have organizations approach PCI DSS compliance as more of a continuous improvement process.
In addition, the timing of the release of Version 3.2 may prove to be of interest. This Version, released just a year after Version 3.1, may signal the PCI Council’s intent to shift to more frequent, smaller releases, rather than making larger changes at longer intervals. While the timing of this release alone does not necessarily signal that this shift has formally been made, it is something that merchants and Service Providers may want to keep an eye on moving forward.
