On Friday, April 15, 2016 while a lot of you were probably getting your US income taxes done, the PCI SSC decided to release the draft of v3.2 of the PCI DSS. I know the announcement message to me from the Council ended up in my company’s spam filter, so you may want to check there if you did not receive a message. I was lucky enough for a colleague to forward his copy along to me. However to get the draft, you need access to the PCI Portal to obtain the draft PCI DSS v3.2 and the requisite change log.
These are some of the more notable changes in the new PCI DSS version.
- The draft provides an official sunset date for v3.1 of the PCI DSS. Regardless of the date in April that v3.2 is released, v3.1 will be withdrawn on 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. 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.
There are other clarifications and edits that have been made to the new version.
For all of us QSAs, we await the Reporting Template which will detail out the actual testing to be performed which will allow us to assess the real impact to the effort required to conduct an assessment. As a result, there could still be some surprises with this new version of the PCI DSS. So stay tuned.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
