By February 1, 2018, all PCI security assessments will need to use version 3.2 of the PCI DSS.
From PCI DSS 3.1 to 3.2The Payment Card Industry Security Standards Council (PCI SSC) announced PCI Data Security Standard (PCI DSS) version 3.2 on April 28, 2016. This latest version adds clarification, guidance as well as some new requirements to the standard.
According to Troy Leach, the PCI SSC’s CTO, the council made these changes to the PCI DSS, “to ensure it continues to protect against old exploits that are still causing problems, addresses new exploits and provides greater clarity for implementing and maintaining PCI DSS controls.”
PCI DSS 3.1 officially retired on October 31 of 2016. Since then, version 3.2 has been considered “best practice” by the PCI SCC.
Starting February 1, 2018, the changes in version 3.2 will be effective as requirements, and all assessments will need to use the new version.
PCI DSS 3.1 to 3.2 TimelineApril 28, 2016: The PCI SCC announced the change to 3.2.
May 2016: PCI DSS 3.2 published.
October 31, 2016: PCI DSS 3.1 retired. Version 3.2 considered best practices.
January 31, 2018: Last day PCI DSS 3.1 can be used.
February 1, 2018: Changes in PCI DSS 3.2 effective as requirements.
Important Takeaways from the PCI DSS 3.2 ChangesMulti-Factor Authentication
- Previously, the PCI DSS required only untrusted, remote access into cardholder data environment to require “two-factor authentication.” They changed the name to “multi-factor authentication” to clarify that at least two factors must be used—they also extended this requirement to any personnel with administrative access into the cardholder data environment. This recently recorded webinar goes in-depth on the subject of multi-factor authentication.
- No new SAQ categories have been added, but most SAQ categories have added new requirements that reflect the new PCI DSS 3.2 requirements. Here is a summary of requirements added to the SAQs.
- The PCI SCC released this supplement in December of 2016. Its purpose is to help organizations know which of their systems should be included in their PCI scope and understand how segmentation can reduce PCI scope. One of the biggest takeaways for organizations is to make sure they also include any systems that are connected to the cardholder data environment in their PCI scope, not just systems located within the CDE.
- Starting February 1, 2018, segmentation checks (penetration tests on segmentation controls) must be performed by an organizationally independent resource (as is already required for other penetration tests). Also, service providers will be required to perform segmentation tests at least every six months and after any changes to segmentation controls/methods.
- As mentioned above, PCI DSS 3.2 requires service providers to perform segmentation checks at least every six months and after any changes. There are also a few new requirements specific to service providers in the following areas:
- Cryptographic architecture (requirement 3.5.1)
- Timely detection and reporting (requirement 10.8), (10.8.1)
- Establish responsibilities for PCI and data (12.4.1)
- Quarterly personnel Reviews (12.11, 12.11.1)
- Penetration testing (220.127.116.11)
Migration from SSL & TLS v1.0 to TLS v1.2
- While migration to TLS v1.2 (from SSL & TLS v1.0) is not required by the PCI SSC until June 30, 2018, it’s a good idea to make sure your organization makes this change in conjunction with the PCI DSS 3.2 updates.
Resources to Help You Comply with PCI DSS 3.2Since 2018 is just around the corner, we want to make sure our readers are aware of and prepared for compliance with PCI DSS 3.2. We’ve compiled some of the some of the best resources to support PCI DSS 3.2 education and compliance at your organization:
SecurityMetrics ResourcesWhitepaper: How to Become Compliant with PCI DSS 3.2
Whitepaper: PCI DSS 3.2 Segmentation Checks
Blog: PCI DSS 3.2—Changes Your Business Needs to Know
Blog: New 3.2 Requirements for Service Providers
Blog: Guide to Understanding the PCI DSS Scoping + Segmentation Supplement
PCI SCC ResourcesPDF: PCI DSS 3.2
Blog: Interview with PCI SCC CTO Troy Leach about PCI DSS 3.2
Blog: Keeping Up to Date with PCI DSS Dates
Supplement: Guidance for PCI DSS Scoping and Network Segmentation
Supplement: Penetration Testing Guidance
Compliance with PCI DSS 3.2Because PCI compliance involves many steps, details and technicalities, it’s important to start as soon as possible with any changes you need to make in order to be compliant with PCI DSS 3.2. The changes in 3.2 are intended to make organizations safer and less likely to experience a data breach. They also help clarify previous points of confusion for merchants and service providers.
More questions about PCI DSS version 3.2?