We spend a lot of time dealing with the Payment Card Industry (PCI) Data Security Standard (DSS). This should come as no surprise, as for better or for worse, a lot of organizational security programs revolve around compliance with the PCI DSS. For those of you who aren’t PCI Qualified Security Assessors (QSAs), know that the PCI Council is in constant communication with QSAs and works diligently to provide us with additional guidance and direction. Of course, the PCI Council also releases information and clarification to the general public as the need arises. When there are a good deal of clarifications and changes to the DSS, the PCI Council releases a new version. This happened recently when the Council released the PCI DSS 3.1. For organizations that have been working hard to make sure they are ready for PCI 3.0 after getting used to 2.0, a release of a new incremental version may cause a bit of consternation. The PCI Council provides a summary of changes when new versions are released, and for the differences between 3.0 and 3.1 that summary can be found here: (Note that it is a PDF) https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1_Summary_of_Changes.pdf So what is new with 3.1? Or, as you may be wondering, what do I as an organization subject to the PCI DSS have to do differently to maintain compliance? The good news is that a lot of the changes are just clarifications. This is a great thing, as the more clarification that is offered in the DSS, the more consistent assessments will be and also it becomes easier for organizations to know what they should be doing. There are three types of changes as defined by the Council. The following definitions are taken verbatim from the PDF document linked above:

• Clarification: Clarifies intent of requirement. Ensures that concise wording in the standard portrays the desired intent of requirements.
• Additional guidance: Explanation, definition and/or instruction to increase understanding or provide further information or guidance on a particular topic.
• Evolving Requirement: Changes to ensure that the standards are up to date with emerging threats and changes in the market.

We will cover the clarifications and additional guidance in a future post (my apologies for the tease, I am sure you will all be on the edge of your seats waiting with rapt attention for that post.) Here we will discuss the evolving requirements. There are four evolving requirement changes from 3.0 to 3.1, and they all deal with SSL or early TLS. The PCI Council no longer considers SSL to be a secure technology and recognizes all versions of SSL as examples of weak encryption. We of course knew this was coming when POODLE hit the scene, as there is no patch that can remedy the vulnerability to POODLE. SSL and early TLS are no longer considered strong cryptography, and cannot be used as a security control after June 30, 2016. While this affects multiple DSS requirements, the edict is clear, SSL will no longer fly for anything that is in PCI scope. While the Council has future dated this requirement, you should not wait to get these insecure technologies out of your environment. The Council wants organizations to “determine available options for upgrading to a strong cryptographic protocol as soon as possible” and that is what organizations should be doing. Moving to new TLS or IPSec is essential. Just because the PCI Council is giving organizations some time to move off SSL that does not mean you should wait. If we can answer any questions about SSL or the changes from 3.0 to 3.1, please don't hesitate to get in touch with us. This article was written by Alex Hamerstone (@Infosecdoc) of TrustedSec.