What Changed in the New PCI DSS 3.2?

PCI DSS 3.1 is soon being superseded by the new PCI DSS 3.2. This article gives an overview of what is new and what has changed in the new version of the popular regulatory compliance requirements.

As much as those of us working in IT like to think that web application security is black and white, it's not. Instead, application security is more of an art that we must delicately dance around, continue to tweak as we go along.

A good example of the fine-tuning is the newly-released PCI DSS version 3.2. There's nothing terribly groundbreaking that we didn't already know it was a good security practice. However, PCI DSS 3.2 has been adjusted to meet the growing risks associated with payment card processors, merchants, retailers and the like. Given the considerable amount of organizations that don't have to comply with but nonetheless use PCI DSS as a prescriptive security guideline, it's worth looking into the latest changes.

PCI DSS 3.1 Will Be Retired in October 2016

PCI DSS version 3.1 is being retired on October 31, 2016. PCI DSS validations after this date must be to this new version of PCI DSS (or whatever the latest version is). So, what's new? Here are the notable changes in PCI DSS version 3.2 that impact application security and information security programs in general.

The New PCI Data Security Standard 3.2

The new and always evolving requirements make up the greatest changes – most of which do not go into effect until February 1, 2018:

  • Section 3.3 is an updated requirement that clarifies that any displays of a primary account number (PAN) greater than the first six/last four digits of the PAN requires a legitimate business need.
  • Section 3.5.1 is a new requirement for service providers only to maintain a documented description of the cryptographic architecture (algorithms, protocols, and keys) involved in their cardholder data environment (CDE).
  • Section 6.4.6 is a new requirement for change control processes to incorporate verification of other PCI DSS requirements that are impacted by a change such as network diagrams, endpoint controls, and the inclusion of new systems into the quarterly vulnerability scan process.
  • Section 8.3 has been expanded into sub-requirements to require multi-factor authentication for all personnel with non-console administrative access and all personnel with remote access to the CDE. This includes a new requirement, 3.2, that addresses multi-factor authentication for all personnel with remote access to the CDE and a new requirement 8.3.1 that addresses multi-factor authentication for all personnel with non-console administrative access to the CDE. In other words, we're going to start seeing a lot more multi-factor authentication.
  • Sections 10.8 & 10.8.1 are new requirements for service providers to detect and report on failures of critical security control systems such as firewalls, anti-virus, and audit logging mechanisms.
  • Section is a new requirement for service providers to perform penetration testing on segmentation controls at least every six months.
  • Section 12.4.1 is a new requirement for service providers whereby executive management must establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include accountability and a charter to ensure the program is communicated to management.
  • Sections 12.11 & 12.11.1 are new requirement for service providers to perform quarterly security program reviews and maintaining documentation and sign-off of those reviews.
  • New Appendix A2 that outlines additional requirements for SSL/TLS, namely:
    • After June 30, 2018, stop using SSL/early TLS as a security control and use only secure versions of the protocol (i.e. TLS v1.2).
    • Prior to June 30, 2018, existing implementations that use SSL and/or TLS 1.0 and 1.1 must have a formal Risk Mitigation and Migration Plan in place.

There's also additional clarification in PCI DSS version 3.2 that directly impacts application security programs such as:

  • Backup/recovery sites need to be considered when confirming PCI DSS scope.
  • Added Testing Procedure (11.3.4.c) to confirm penetration test is performed by a qualified internal resource or qualified external third party.
  • Training for developers must be up to date and occur at least annually.

A complete summary of all changes can be found in the document Summary of Changes from PCI DSS Version 3.1 to 3.2.

Use PCI DSS as Guidance

Whether you are an information security generalist or an application security specialist, PCI DSS version 3.2 provides that continued guidance to help ensure that you stay on track and keep cardholder data (or other information) adequately protected. In your quest for PCI compliance, don't get too far off in the weeds. The reality is that PCI DSS and other regulations are still nothing more than information security best practices – most of which have been around for decades. The hard part is not the technical issues. Instead, it is the people and processes that take so long to get right. Best of luck!



About the Author

Ferruh Mavituna - Founder, Strategic Advisor

Ferruh Mavituna is the founder and CEO of Invicti Security, a world leader in web application vulnerability scanning. His professional obsessions lie in web application security research, automated vulnerability detection, and exploitation features. He has authored several web security research papers and tools and delivers animated appearances at cybersecurity conferences and on podcasts. Exuberant at the possibilities open to organizations by the deployment of automation, Ferruh is keen to demonstrate what can be achieved in combination with Invicti’s award-winning products, Netsparker and Acunetix.