In a previous blog post, we talked about the infamous Heartbleed Bug and the damage it inflicted. In April 2015, as a result of Heartbleed and other discovered vulnerabilities, the Payment Card Industry Security Standards Council (PCI SSC) removed SSL and early versions of TLS as an example of strong cryptography from the PCI Data Security Standard (DSS) version 3.1.
Since first announcing a migration timeline for organizations to transition from SSL and earlier versions of TLS, PCI has extended the migration completion date to June 30, 2018. The extra time offers organizations the ability to develop and execute more secure migration plans, but PCI stresses that waiting is not recommended, as organizations using SSL and early versions of TLS are at risk of being breached.
That being said I wanted to take the opportunity to answer a few common questions about SSL and early versions of TLS.
What are SSL and TLS? What do they do?
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are often used interchangeably. For the purposes of this blog, I will refer to them together as TLS. For almost twenty years, TLS has been the secure communications protocol of choice for a large part of the Internet. TLS is a cryptographic protocol used to establish a secure communications channel between two systems. Used by banking sites, ecommerce sites, email providers, bill payment, social media platforms and more, TLS is used to protect the confidentiality and integrity of information that passes between systems and can also be used with public-key cryptography to authenticate one or both systems.
What are the challenges with older versions of SSL/TLS?
All systems and applications using SSL v3.0 or TLS v1.0 may be at risk of being exposed by different classes of vulnerabilities: protocol vulnerabilities, implementation vulnerabilities and configuration vulnerabilities. If exposed, these vulnerabilities could result in loss of confidentiality or integrity or loss of cryptographic keys themselves.
According to the PCI Council, online and ecommerce environments using SSL and early versions of TLS are most susceptible to these exploits and attacks and should be upgraded as soon as possible.
What does the PCI Council have to do with this?
We’ve talked in a previous blog post about what is means to be PCI compliant. In April 2015, the PCI Council issued PCI DSS v3.1, which established an SSL/TLS migration completion date and listed revisions for the migration. With PCI DSS v3.1, the PCI Council indicated that SSL and early versions of TLS are no longer examples of strong cryptography or secure protocols, and cannot be used as a security control after June 30, 2016. As a result, the following PCI DSS v3.1 requirements were affected:
Requirement 2.2.3
Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.
Requirement 2.3
Encrypt all non-console administrative access using strong cryptography.
Requirement 4.1
Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission
With the initial migration date of June 30, 2016, PCI indicated that all existing implementations that use SSL and early TLS must have a formal Risk Mitigation and Migration Plan in place, and that new implementations must not use SSL or TLS.
However, as of December 2015, PCI SSC extended the completion date to June 30, 2018 to give organizations more time to complete their migration.
This means that in order to be PCI compliant, all entities must migrate from SSL and TLS 1.0 to a secure version of TLS (as defined by NIST) by June 30, 2018.
What does this mean for healthcare organizations?
Healthcare organizations should migrate to a minimum of a secure version of TLS 1.1, preferably TLS 1.2, as soon as possible. Look for communication from InstaMed regarding the migration for our customers in the coming weeks. In the meantime, you can learn more about migrating from SSL and early TLS on the PCI website.