“SSL, Its over!” – PCI DSS v3.1

March 04, 2017
Compliance, Consulting, Shield

Tweet

Finally, a minor version of PCI DSS 3.0 standard (now version 3.1, after the v1.2.1 many years ago), has been released by the PCI SSC to address the vulnerable SSL/early TLS protocols with addition of few clarifications of other requirements. PCI DSS v3.1 is effective immediately. PCI DSS v3.0 will be retired on 30 June 2015.

Why suddenly a v3.1 out of normal PCI SSC standard life cycle? The PCI SSC receives feedbacks from all industry experts including institutes like NIST and SANS in light of evolving technology and threats to cardholder data. Which in this case, was POODLE attack on SSL/early TLS. This one being very critical, PCI SSC has published minor version, PCI DSS v3.1 addressing mainly the insecure use of SSL as an encryption protocol within a Cardholder Data Environment (CDE).

Following are the Major Changes in PCI DSS 3.1:

Requirements 2.2.3, 2.3 and 4.1: All references to SSL as an example of a secure technology have been removed. (Explained in detail below)
Requirement 3.4: new testing procedure has been added so that “note present in req 3.4” should be enforced by all the entities.
Testing procedure- If hashed and truncated versions of the same PAN are present in the environment, examine implemented controls to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.
Requirement 4.2: Examples for end-user messaging technologies now includes SMS with existing other examples- email, instant messaging, chat, etc.
Requirement 6.6: Clarification on WAF – If a WAF is not configured in “ blocking mode/preventive mode ” , then it must generate an alert that is immediately investigated. QSA should test response mechanism of these alerts.
Requirement 11.3.4: Clarified that the intent of the penetration testing is to verify that all out-of-scope systems are segmented (isolated) from systems in the CDE
Requirement 12.2: Clarification- The risk assessment process must result in a formal, “documented analysis of risk”.

So don’t use SSL/early TLS, that’s it! That Cold! No further guidance!!??

No, For Requirements 2.2.3, 2.3 and 4.1, PCI DSS v3.1 has added following note-

SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016.
Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.
Effective immediately, new implementations must not use SSL or early TLS.
POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after June 30, 2016.

Which means if you are currently being assessed for PCI DSSv3.0 and if you want to know what more you need to mainly for PCI DSS v3.1, then you just need to maintain formal risk mitigation and migration plan for SSL and/or early TLS, which should be executed before June 30th, 2016.

So what all should this risk mitigation and migration plan contain at a minimum?

Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, type of environment
Risk-assessment results and risk-reduction controls in place
Description of processes to monitor for new vulnerabilities associated with SSL/early TLS
Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments
Overview of migration project plan including target migration completion date no later than June 30, 2016.