The PCI Security Standards Council (PCI SSC) has now officially released PCI DSS v3.1.
This release contains some relatively minor clarifications needed after the last major release (v3.0) went into full effect January 1, 2015. The primary driver for this new release, however, is the removal of SSL and early versions of TLS as examples of secure protocols.
Here is my “CliffsNotes” version of the PCI DSS v3.1 updates…
Clarifications to a little less than 10% of the requirements. These clarifications address typographical errors, spelling out what is meant by acronyms, specifically calling out some requirements that apply only to service providers, and generally adding a few words here and there to clarify intent.
Additional Guidance for four specific requirements. This additional guidance also serves to remove ambiguity and provide clearer technical accuracy:
- 2 – Adds SMS to the list of messaging technologies that should not be used to send unprotected PANs (Primary Account Numbers);
- 2 – Notes that a vulnerability scan could include manual tools in addition to automated tools (instead of just automated tools);
- 9 – Includes additional language just for Service Providers, that the agreement they have with their clients is evidence of their commitment to maintain proper security of cardholder data; and
- Appendix C – Modifies language around how to define a compensating control, such that the example given references a more secure method for logging into servers.
Evolving Requirements to deprecate SSL and early TLS. These evolving requirements seek to eliminate SSL and early TLS (versions 1.0 and 1.1) from four specific DSS requirements:
- 2.3 – Encryption for VPNs, NetBIOS, file sharing, Telnet, FTP and similar services that are considered insecure;
- 3 – Encryption for web-based management and other remote (non-console) administrative access;
- 1 – Encryption of cardholder data during transmission over open, public networks; and
- 1.1 – Encryption for wireless networks that transmit cardholder data or connect to the cardholder data environment (CDE).
What’s the SSL/TLS timeline?
Editor’s Note 12/21/15: The PCI SSC has extended the migration completion date to 30 June 2018 for transitioning to a secure version of TLS. Learn more here.
- Merchants are prohibited from implementing new technology that relies on SSL or early TLS; and
- SSL and early TLS are no longer considered a best practice for strong encryption.
June 30, 2015:
- Anyone completing an assessment or SAQ before this date is not required to make any SSL/TLS related changes (however, I and my colleagues highly recommend that you do so!); and
- Anyone completing an assessment or SAQ after this date is required to provide an SSL mitigation plan, if they are not able to immediately discontinue its use.
June 30, 2016:
- After this date, merchants are no longer allowed to use SSL or early TLS in any way to protect payment data; but
- If your POS (Point Of Sale) or POI (Point Of Interaction) terminals still use SSL or early TLS, but you can verify they are not susceptible to known exploits for SSL and TLS, then these terminals can continue to be used after June 30, 2016. (This exception was made because it is difficult for manufacturers to upgrade systems quickly.)
What else is to come?
The following is still to come from the SSC:
- New PA-DSS (Payment Application Data Security Standard) guidelines reflecting the 3.1 changes; and
- The v3.1 SAQs (Self-Assessment Questionnaires). Merchants should continue to use the appropriate v3.0 SAQ until the v3.1 SAQs are officially released.
In the meantime, I encourage you to check out the SSC’s information supplement, Migrating from SSL and early TLS.
Update: The release of PCI DSS v3.2 is coming soon.
Check out our latest post on PCI DSS v3.2,“What’s New in PCI DSS 3.2?” to learn more.