PCI DSS version 3.1 released!

April 15, 2015, Matt Getzelman, PCI Practice Director

As expected, a “minor” revision to the PCI DSS 3.0 standard (now version 3.1) was released by the PCI SSC today to address the vulnerabilities exposed by the POODLE and BEAST browser attacks. PCI DSS 3.1 primarily addresses the insecure use of SSL as an encryption protocol within a Cardholder Data Environment (CDE). In response, the SSC has updated PCI DSS requirements 2.2.3, 2.3 and 4.1 to remove any references that cite SSL 3.0 and early versions of TLS 1.0 as examples of strong cryptography.

The SSC has released both the new 3.1 standard and an accompanying document that summarizes the changes from version 3.0 to version 3.1 on their website.  They are available here:

https://www.pcisecuritystandards.org/

Here are the key data points with regard to the SSL (and early TLS) issues:

  • SSL and early TLS cannot be used as security controls to protect payment data 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. Guidance on interim risk mitigation approaches, migration recommendations and alternative options for strong cryptographic protocols is outlined in the PCI SSC Information Supplement: Migrating from SSL and Early TLS.
  • Effective immediately, new implementations must not use SSL or early TLS.
  • Point-of-sale (POS)/Point-of-interaction (POI) terminals (devices such as magnetic card readers or chip card readers that enable a consumer to make a purchase) that can be verified as not being susceptible to all known exploits for SSL and early TLS may continue using these protocols as a security control after 30 June 2016.

In addition to the above SSL guidance, the 3.1 version of PCI DSS included some errata corrections and edits to other areas of the standard.  We have reviewed the documents and want to highlight the following key changes below.  These are the most impactful items in our opinion, but we highly suggest you download the PCI_DSS_v3-1_Summary_of_Changes document so you can review ALL changes at your convenience.  

Important Changes in PCI DSS 3.1:

  • Requirements 2.2.3, 2.3 and 4.1:  As mentioned above, all references to SSL as an example of a secure technology haven been removed. Added note that SSL and early TLS are no longer considered to be strong cryptography and cannot be used as a security control after June 30, 2016. Additional guidance has been provided in the Guidance column.
  • Requirement 3.4:  Adding a new testing procedure to enforce the “Note” that has been present in the 3.4 description.  This is in regard to additional controls are required if hashed and truncated versions of the same PAN are present in an environment.  Here is the original note from the 3.0 standard:
    • Note: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls should be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.
  • Requirement 4.2:  SMS will now be listed as an end-user technology.
  • Requirement 6.6:  A clarification has been added on the use of WAF technologies to meet this requirement.  If a WAF is used in “alert mode” as opposed to blocking mode, then the QSA must test that a timely response will occur on any alert generated by the WAF.
  • Requirement 9.9.1.b:  This requirement has been updated to clarify that both devices and device locations need to be observed.
  • Requirement 11.3.4:  An important clarification has been added.  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:  Coalfire always likes to emphasize the importance of an annual risk assessment, so we are very pleased about this clarification.  The risk assessment process must result in a formal, “documented analysis of risk”.

As I previously mentioned in a blog post from last month, the PCI SSC has allowed time for organizations to make accommodations for these updated requirements.

So what does this mean for you and your organization?

Organizations need to perform a risk analysis on the use of the SSLv3 in their environment and determine and then document plan for migrating away from this protocol as soon as possible.  Obviously there are major security and compliance implications around the use of SSLv3 and having a documented risk analysis and plan for dealing with the vulnerability is a must.  Don’t get caught without a plan!  

If you have any questions about how the PCI DSS 3.1 standard will impact your organization, please do not hesitate to reach out to us at any time.  Good luck out there!

Matt Getzelman

Author

Matt Getzelman — PCI Practice Director

Recent Posts

Post Topics

Archives

Tags