By Jeff Montgomery, Principal Information Security Consultant
On the 13th of February, the PCI Standards Security Council (SSC) released an official statement confirming the impending release of a new version of the PCI DSS and PA DSS. They also released a follow up statement on the 25th of March.
What we know
As the standards have not been released we cannot say for sure what they will include, but we do know they are a direct response to vulnerabilities that were discovered in certain implementations of the Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocols last year.
If you recall, there was a large amount of publicity around two vulnerabilities in particular: Heartbleed and Poodle.
Both of these affected SSL/TLS. As the council’s statement very clearly states, we know that at the very least SSL version 3.0 will no longer be acceptable as “Strong Cryptography.” We don’t know how this will affect TLS implementations, but it is safe to say that organisations should be moving away from SSL as soon as they can.
We also know the new standards will be “effective immediately.” This can sound frightening, but it is important to note that in the PCI world this has a very particular meaning.
If you look at the both the PCI Lifecycle published on the SSC’s website and their statement mentioned above, it becomes clear that the Council will future date the new requirements in an attempt to allow organisations some flexibility in adoption.
What we don’t know
The statement from the council did not include the exact timeline that will be enforced. When new versions of the standards are released in the normal change lifecycle the council allows a full year for implementation and in some cases an additional six months for particularly difficult requirements.
Will the council allow an additional 6 months for the move away from SSL? We know the council is reaching out to the PCI community to assess the pervasiveness of the problem (hint: it is incredibly pervasive) and we can only guess that they will take this into account when setting the timeline for adoption.
We also don’t know what, if any, compensating controls would be allowed to address a failure. If it follows the normal process for compensating controls, it will need to be a discussion between an organisation, their acquiring bank and the QSA. So from an acquiring bank’s perspective, now is the time to start deciding what will be acceptable to address the risk to card holder data.
What can we do now?
If we don’t know the specific changes that are coming, can we do anything other than wait? We do know that SSL will no longer be acceptable for the transmission of card numbers or authentication credentials. So the first thing organisations should be doing now is documenting the extent of their reliance on SSL.
Locate every in-scope system that is using SSL or TLS and document what they are doing, how SSL/TLS is implemented and what versions are being used.
Next, you should start the upgrade process. The industry has largely agreed that TLS 1.2 is the way forward; however, the council has indicated that TLS 1.1 will be sufficient in at least the short term. So start upgrading where you can and document any business justification you may have for not moving to TLS 1.2.
Prioritize externally facing systems first, followed by internal systems with access to card data and then finally internal systems that are in-scope but do not directly interact with card data. Once this process is completed, you will have evidence showing a risk based and proactive approach that can be presented to the acquiring bank when/if compensating controls need to be discussed.
SSL is dead or at least will be soon. If you haven’t started putting a program in place to move away from SSL you should start immediately.
Sysnet Global Solutions’ team of specialist Cybersecurity consultants understand the importance of data protection and our staff are highly skilled in a wide range of security disciplines including PCI DSS and ISO27001.
We can also assist in designing, implementing and documenting appropriate security controls, procedures and policies, all within a holistic cybersecurity framework that takes into account all applicable standards and regulations. To learn more about our solutions or for more information about our services, please visit Risk & Assurance or email email@example.com
If you are a merchant that requires technical or PCI DSS help, please click here