As of the 30th of June 2018, the use of SSL/early TLS in PCI-DSS (Payment Card Industry Data Security Standard) card environments will no longer be accepted as a compliant protocols by the PCI security standards council and thus could render your accreditation as invalid. What does this mean for you and your managed file transfer solution?
We have attempted to answer the key questions in the build up to the deadline.
What is SSL/early TLS?
TLS (Transport Layer Security) is a cryptographic protocol used to secure a communication channel between two parties. It authenticates one or both parties and ensures the confidentiality and integrity of and documents, files or data which it transports. Developed in the 1990s, TLS has seen multiple revisions aimed at improving its security, with major revisions to SSL 3.0 in 1996, TLS 1.0 in 1990, TLS 1.1 in 2006 and TLS 1.2 in 2008.
Why is SSL/early TLS Vulnerable?
There are number of vulnerabilities in SSL and early TLS that put organisations and card data environments at risk. The infamous and widespread POODLE and BEAST exploits are some of the higher profile examples of how vulnerable and easy to exploit SSL and early TLS have become.
NIST have reported that there are no fixes or patches that will ever adequately repair SSL or early TLS and therefore its usage must come to an end. Needless to say that those who are operating in sensitive environments or transferring sensitive files, such as a card data environment, it is critically important to upgrade to a stronger and safer alternative.
How Does this Affect Managed File Transfer Solutions?
A number of our customers user managed file transfer solutions within their PCI-DSS card data environments to facilitate the secure and automated movement of files. Where managed file transfer solutions are operating in this way, you will need to ensure that your solutions is not using an SSL/early TLS.
Modern managed file transfer solutions will have either migrated away from older cryptographic protocols or provide you with a choice to cease using them. Particularly in the case of older solutions which have not been upgraded or patched, it would be wise to audit those solutions to determine if they are putting your PCI accreditation at risk.
It is also worth pointing out that even those operating managed file transfer solutions without the compliance requirements of the PCI-DSS, the vulnerabilities in the protocols still represent a risk and should be addressed.
Take a look at our definitive guide to Securely Sharing Documents and Files in a Privacy Oriented World.
What Can Organisations Do Today, to Protect Themselves?
While there is just a small amount of time left before the deadline, it is not too late to prepare and remediate.
The PCI security standards council recommends the following three steps:
- Migrate to a minimum of TLS 1.1, preferably TLS 1.2 - While it is possible to implement countermeasures against some attacks on TLS, migrating to a later version of TLS (TLS 1.2 is strongly encouraged) is the only reliable method to protect against the current protocol vulnerabilities. Check to see if your managed file transfer solution permits turning SSL and early TLS protocols off.
- Patch TLS software against implementation vulnerabilities - Implementation vulnerabilities, such as Heartbleed in OpenSSL, can pose serious risks. Keep managed file transfer solutions up-to-date to ensure it is patched against these vulnerabilities, and have countermeasures for other attacks.
- Configure TLS securely - In addition to providing support for later versions of TLS, ensure the TLS implementation is configured securely. Ensure that secure TLS cipher suites and key sizes are supported, and disable support for other cipher suites that are not necessary for interoperability. For example, disable support for weak “Export-Grade” cryptography, which was the source of the recent Logjam vulnerability.