Here we are again, off to the races on a fresh new release of the Payment Card Industry Security Standards Council’s (PCI SSC) flagship security standard PCI-DSS v 3.2.1. Aside from an exciting new version that sounds like a countdown, there are some changes that organizations storing, processing or transmitting cardholder data need to know about. The most notable change is that the council no longer considers SSL v3 and early versions of TLS an acceptable means to protect cardholder data (CHD), system administration, or authentication credentials. Some other minor updates made were removing past dated best practice requirements and formatting changes to the reporting template.
First and foremost, SSL v3 and early versions of TLS are finally gone (well sort of)
This has been a long time coming. These old protocol versions have been patched up and put back together with duct tape and an unrelenting desire to avoid change. A great example of this reluctance to accept change is the fact that SSLv3 was deprecated by the IETF in 1999, but has just now been officially denounced by various other standards organizations such as PCI. Unfortunately, the PCI SSC does not concretely identify exactly what are considered to be “early versions of TLS”. “Early versions of TLS” is often considered to be TLS v 1.0 and 1.1, but that is not entirely accurate. TLS v1.1 as a protocol can be implemented securely, but is more susceptible to be bundled with insecure cipher suites. The Internet Assigned Numbers Authority (IANA) maintains a list of recommended cipher suites here. The primary issues with weak TLS cipher suites is the inability to provide forward secrecy and inadequate key lengths.
As discussed in a recent blog posting by the PCI SSC "What Happens After 30 June 2018?", simply using SSL v3 or early versions of TLS does not mean your organization will fail a PCI compliance assessment. To simplify the explanation of the PCI SSC, SSL or early TLS can be utilized only where not designated as a security control (which is very rare) for the protection of CHD. Conversely, if SSL or early versions of TLS are still in use as a security control the organization will need to discontinue the deprecated protocol use or implement a compensating control. If a compensating control is the route your organization chooses to take, it would be best to fully discuss the approach with your QSA as the compensating controls chosen will be wholly dependent on the environment and use case.
Removal of "best practice" requirements:
When PCI DSS v 3.0 was first introduced back in 2014, the PCI SSC set a firm date for organizations to meet the new requirements. This created a disturbance in the industry which inspired a lot of organizations to move their annual assessment into Q4 of 2014 because they were not ready to implement all of the new controls defined in PCI v3.0. Every other major update to the standard since has included a much longer time frame for requiring new controls to be in place. As a result, the council added "the best practice until February 1, 2018" verbiage to the PCI-DSS v3.2 release in April of 2016.
Speaking of changes, now that we are past February 1, 2018, the PCI SSC has removed all of the “best practice until February 1, 2018” verbiage in version 3.2.1 of the PCI standard. Additional changes were also made to the verbiage regarding the aforementioned use of SSL and early versions of TLS.
Important dates to remember for 3.2.1
- June 30, 2018
- Discontinue the use of SSL and early TLS
- PCI assessment can be conducted based on version 3.2.1 of the standard
- August 1, 2018
- Organizations using network segmentation to reduce the scope of their environment will need to have completed the first “6 month” segmentation penetration test
- January 1, 2019
- All PCI assessments, including those producing ROCs and SAQs, will need to be conducted using version 3.2.1.