PCI DSS 3.2: The Major Changes

What is PCI Compliance

It’s that time of year, when PCI Compliance evolves and we all await the inevitable PCI DSS changes.  PCI SSC has released PCI DSS version 3.2, which represents a major turning point for the 10-year-old Payment Card Industry Data Security Standard.  The major turning point?  That PCI DSS was incremented from PCI DSS 3.1 to PCI DSS 3.2, instead of the expected PCI DSS 4.0, which we’ve come to expect from the not-so-predictable standard.

You have probably noticed that there are hundreds of articles discussing the awaited PCI DSS 3.2 major changes.  You have probably also noticed that few articles have provided digestible, actionable summaries of the changes, and instead either 1) provide the information in a 5,000 word article or 2) do not provide enough actionable information to answer your questions.  Here at PCI Blog, we’ve tried to provide a high level summary of each PCI DSS 3.2 major change, with the specific requirement that we’re referencing.  This will give you and your organization’s compliance team enough information to make business decisions as well as perform additional research directly through the PCI DSS 3.2 standard.  For your reference, the full PCI DSS 3.2 standard can be found on our Documents page.

PCI DSS 3.2 Major Changes

PCI DSS 3.2 Key Dates

  • April 2016: PCI DSS 3.2 has been released, including new Self-Assessment Questionnaires (SAQs)
  • October 2016: PCI DSS 3.2 will officially take effect on 10/31/16, and all PCI DSS assessments will fall under the new PCI DSS 3.2 standard. Please note, all new requirements will be considered “best practice” until February 2018 (see below).
  • February 2018: PCI DSS 3.2 “best practices” will be considered requirements.

PCI DSS 3.2 Major Changes

  1. SSL to TLS 1.2+ Migration Dates – June 30, 2018

    1. PCI DSS 3.2 Requirement 2.2.3, 2.3, and 4.1
        1. Upgrading from SSL and early TLS to supported versions of TLS
        2. The SSL to TLS migration has been the major change of PCI DSS 3.2 that has gained the most attention.  The PCI SSC originally set June 2016 as the migration deadline, but has since pushed the deadline to June 2018.  The following PCI DSS 3.2 requirements that are affected by this change are the following:
          1. Requirement 2.2.3: “Implement additional security features for any implemented for required services, protocols or daemons that are considered to be insecure.”
          2. Requirement 2.3: “Encrypt all non-console administrative access using strong cryptography.”
        3. Requirement 4.1: “Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.”

       

  2. Multi-factor Authentication

    1. PCI DSS 3.2 Requirement 8.3, 8.3.1, and 8.3.2
        1. Enhancement of Requirement 8.3, which required two-factor authentication, to include multi-factor authentication.
        2. The major change enhances two-factor authentication to multi-factor, and requires that multi-factor authentication must be used for personnel with non-console administrator access and remote access to the cardholder data environment.

       

  3. Designated Entities Supplemental Validation (DESV)

    1. PCI DSS 3.2 – Designated Entities Supplemental Validation (DESV) Appendix
        1. Ensuring PCI DSS standards are followed through the year, and not just for an annual audit.
        2. The addition of the DESV appendix to the PCI DSS 3.2 standard is an effort by PCI SSC to enforce ongoing compliance of PCI DSS compliance throughout the year.  In other words, the PCI Council is clearly defining what it means to be “PCI compliant,” as an ongoing, real-time initiative, rather than the point-in-time, annual hurdle that many companies view the standard as.

       

  4. Increased Scrutiny for Service Providers

    1. PCI DSS 3.2 Requirement 10.8 and 10.8.1
      1. Service providers are required to detect and report on the failing of critical security control systems.
      2. This PCI DSS 3.2 change focuses on the importance of immediate notification of failure of security systems and protocols.  The longer an organization goes without notice of a potential compromise, the longer a potential hacker has to compromise said systems.
    2. PCI DSS 3.2 Requirement 11.3.4.1
      1. Penetration Testing must occur every six months
      2. This PCI DSS 3.2 change is specific to 3rd party penetration testing, and changes the PCI DSS 3.1 requirement of annual penetration testing to the new PCI DSS 3.2 standard of semi-annual penetration testing.
    3. PCI DSS 3.2 Requirement 12.11 and 12.11.1
      1. Quarterly reviews of employees/personnel and their respective access to cardholder data/cardholder data environments (CDE)
      2. This PCI DSS 3.2 changes isn’t major, as most service providers likely have these controls in place for PCI DSS 3.1.  That being said, service providers will be required to demonstrate that the specific controls that are in place quarterly.
    4. PCI DSS 3.2 Requirement 12.4.1
      1. Establishes individual as owner of PCI DSS compliance program
      2. This PCI DSS 3.2 change essentially puts into writing something that most service providers have been doing for years.  That is, the PCI DSS 3.2, 12.4.1 Requirement makes an official individual within the organization accountable and responsible for the overall PCI DSS compliance program.  This individual is also responsible for communicating directly with executive management regarding compliance with the internal PCI Compliance program.
    5. PCI DSS 3.2 Requirement 3.5.1
      1. Requirement 3.5.1 requires that service providers maintain a documented description of the types of encryption that are utilized within their environment.
      2. The purpose behind this new control is establishing internal process around the documentation of the organization’s encryption architecture.  The new 3.5.1 requirement prevents a single employee, or small group of employees, to be the only individuals within an organization who understand the organization’s encryption architecture, should an employee leave the company.

       

  5. New Standards for Viewing of Clear Text PAN Data

    1. PCI DSS 3.2 Requirement 3.3
      1. PANs must be masked to only include the first 6 and last 4 digits.  The exception to this rule must be those individuals with a “legitimate business need.”
      2. The purpose of requirement 3.3 is to force organizations to document roles and responsibilities with even more granularity by defining who within the organization has a legitimate business need to view clear-text cardholder data.  By defining this list, organizations will, ideally, take a closer look at the risk in displaying clear text data at all.  Our opinion?  PCI DSS requirement 3.3 is laying the ground work to set an Encryption At Rest standard of all PAN data for a future major change to the PCI DSS framework (albeit, not until long into the future, as this would be a major change with a significant amount of definition around CDE architecture).

 

About PCI Blog 598 Articles
PCI Blog is the most trusted PCI Compliance and IT Security blog on the web. Authored by industry experts within the payments and IT security industries, PCI Blog provides insight on the complex world behind modern compliance and security standards. As a wholly independent source of news within the payments industry, PCI Blog focuses on the ever-changing responsibilities of merchants who accept credit cards. PCI Blog also provides reviews on PCI compliance tools and enterprise security solutions to offer a fair, independent critique of product offerings within the payments industry.

2 Trackbacks / Pingbacks

  1. SSL/Early TLS to TLS 1.1 Migration Guide – PCI Blog
  2. PCI DSS 3.2: New SAQ Changes (January 2017) – PCI Blog

Leave a Reply