PCI DSS Version 3.2 Released

Last Thursday, April 28, 2016 the PCI Security Standards Council (PCI SSC) released version 3.2 of the PCI Data Security Standard (PCI DSS). To save you the trouble of accessing the change log, we have put together some of the more notable changes in the new version.

• The official sunset date for v3.1 will be October 31, 2016. So any assessments done after that date will need to comply with and use v3.2.
   
• Two new sections to Appendix A have been added. In addition to the Appendix for shared hosting providers (now marked A.1), we get Appendices A.2 and A.3. A.2 covers SSL and early TLS for those of you that will miss the June 30, 2016 date. For those of you that thought 2018 was the deadline and missed discussions on the webinar about the SSL/early TLS deadline, while the deadline was extended to June 30, 2018, any organizations missing the June 30, 2016 date must fill out Appendix A.2. A.3 is where the Council added the designated entities supplemental validation (DESV) requirements.
   
• There are a number of new requirements for service providers that are best practices until February 1, 2018. Those new requirements include: (1) maintain a documented description of the cryptographic architecture, (2) detect and report on failures of critical security control systems, (3) perform penetration testing on segmentation controls at least every six months, (4) executive management to establish responsibilities for the protection of cardholder data and a PCI DSS compliance program, and (5) perform reviews at least quarterly, to confirm personnel are following security policies and operational procedures. I would bet that numbers three and five will likely create a lot of contention with service providers. But you have until February 1, 2018 to get those in place. However, if experience teaches us anything, service providers had better start now getting these new requirements in place and operating.
   
• All organizations picked up the following new requirements that are best practices until February 1, 2018: (1) change control processes to include verification of PCI DSS requirements impacted by a change, and (2) multi-factor authentication for all personnel with non-console administrative access to the CDE. As with the aforementioned new requirements for service providers, these will also require a lot of organizations to get started now to ensure these new requirements are in place and operating.
   
• The Council clarified requirement 8.1.5 to show that it is intended for all third parties with remote access, rather than only vendors. While most organizations understood the intent of this requirement, there were a few that played “legal eagle” and refused to require compliance for non-vendors.
   
• Requirement 6.5 has been clarified that developers must go through secure coding training at least annually. This change will likely create some consternation for some organizations that are developing their own software that is in-scope for PCI compliance.
   
• Clarified 11.5.a by removing “within the cardholder data environment” from the testing procedure for consistency with requirement, as the requirement may apply to critical systems located outside the designated CDE. This will likely expand the number of systems that require critical file monitoring.
   
• Clarified 12.8 1 by saying that the list of service providers now must include a description of the service(s) provided.
   
• Clarified 12.8.2 by adding guidance that service provider responsibility will depend on the particular service(s) being provided and the agreement between the two parties.
   
• One of my pet peeves has finally been addressed. I have always had an issue with requirement 1.1.6 and the use of the terminology “insecure protocols”. The reason is that in one way or another, all protocols have their insecurities whether they are known or not. In v3.2, the Council has finally removed the “insecure” designation as, in their words, “these may change in accordance with industry standards.” It is those small battles at times that make your day.

This is just a sample of the notable changes; there are other clarifications and edits that have been made to the new version not listed above. You can access the full document as well as the Reporting Template on the PCI SSC website.