Shane Lewis – Information Security Manager

Usually, compliance regulations mandate the response of the market – most companies will put off their adoption of any new technologies or requirements until the last possible second. However, recent behind-the-scenes moves in the payments space may illustrate a broader trend – that companies are learning the lessons taught by the recurring headlines on payment card data breaches.

The cryptographic protocol known as Transport Layer Security (TLS) 1.0 was first defined in January 1999 and remained one of the primary methodologies, along with Secure Sockets Layer (SSL), for keeping communications between computers and networks secure. This process was used extensively in email, instant messaging, and Voice-over-IP (VoIP). And when you made a payment on a website using a HTTPS connection, TLS encryption is what made your payment transfer over the public Internet secure. TLS ensured that encrypted communications were: unreadable by third parties; that the identity of the parties can be authenticated to a known source using public key cryptography; and that the messages or communications would not be able to be altered between transmission and receipt. It is exactly the kind of technology that we should be using for sensitive payment card data, no?

Unfortunately, over the course of the last decade a number of attacks against TLS have been identified and splashed across the headlines – and rightfully so. For example, one attack, nicknamed POODLE (Padding Oracle On Downgraded Legacy Encryption) and its variants demonstrated how the SSL and early TLS protocols could be exploited to leak little packets of encrypted messages.

The Heartbleed bug (who gets to name these attacks?) demonstrated weaknesses to the SSL/TLS process in OpenSSL software that is used by a massive amount of larger software packages and services. For a number of these identified vulnerabilities in TLS 1.0, there is no patch.

Wisely, the most recent version of the Payment Card Industry Data Security Standard (PCI DSS v3.1) stated that organisations processing payments must migrate to at least TLS 1.1 encryption or preferably higher by June 2016. The PCI Security Standards Council has now moved back that deadline to June 2018.

In a turnaround that would seem rare, many companies and vendors are not waiting for the new deadline but are pushing the community to react, well in advance of the pending standards, by proactively driving customers to more secure processes.

Many would argue that the The PCI Security Standards Council pushed the date back to aid a percentage of merchant customers who use old, outdated, insecure technology, and big ecommerce companies do not want to lose out on these sales. But why should the masses suffer for the minority? In the future, merchants and service providers should start offering a sliding scale or tiered secure systems that make a customer responsible for their own actions or lack of them to upgrade their systems and protect their networks.

Semafone will withdraw support of TLS 1.0 and 1.1 at the end of June 2016 and is proactively migrating customers before then. But we are not flying alone on this. It is presumed that certain Payment Service Providers (PSP) will also soon be stopping their use of these insecure protocols, some also before June 2016.

This is a positive example of organisations becoming aware of a risk, assessing it and responding rapidly prior to any mandate or deadline. While we know that forced updates can be challenging, we will do everything in our power to help our customers make the transition now, not for the sake of compliance, but in the interest of security.

You can read more in our announcement and also get details of some of the features in our new version of our patented solution, Semafone v3.2 here.

A Rare Case of Security Over Compliance – the Start of Something More?

Did you find this article useful? Leave Feedback →

1. Very Unsatisfied2. Unsatisfied3. Neutral4. Satisfied5. Very Satisfied