Two Years After Heartbleed, What Have We Learned?

It’s the second anniversary of the disclosure of the Heartbleed

In 2014, Heartbleed enabled an attacker to access working memory space in vulnerable versions of OpenSSL software – opening up secret keys and sensitive information being transmitted in a session (such as usernames and passwords) to potential compromise. With an estimate of 66 percent of all Web servers using OpenSSL at the time, this meant that two-thirds of the Internet was affected. Organizations scrambled to patch the bug and replace SSL certificates, to remediate the vulnerability and replace potentially compromised keys.

Two years later, long after the crescendo of activity that occurred around Heartbleed, there is improved awareness and preparedness in the industry to deal with similar disclosures. And it helped drive home some important lessons.

Here are a few observations:

1. 1. The Heartbleed announcement was a defining moment in the public consciousness around vulnerabilities in open source, and the potential impacts it can have. This particular event, which forced a ‘re-key the internet’ activity, helped dispel the myth that merely making your source ‘open’ somehow made the code implicitly more secure. This event helped clarify that security in any source (let alone open) happens through diligence and discipline; the mere act of being open doesn’t actually bestow security onto the code base.
   2. With this vulnerability being in such a seminal work of open source security (OpenSSL), this event also elevated the dialog on key management and security software in general. The mere fact that something as simple as a buffer length issue could result in the exposure of private keys was earthshaking to those who held the belief that (a) vulnerabilities were hard to actually implement/launch, (b) they were only used to spread malware, and (c) they were usually the result of some extremely challenging bug. Heartbleed proved that none of that was true.
   3. Many research studies, including the recent 2016 Global Encryption Trends Study by the Ponemon Institute, have noted challenges associated with lack of skills and expertise in managing keys. See the chart below. In the months following the initial announcement of Heartbleed, it was discovered that many organizations, in their haste to obtain new SSL certificates, replayed the same certificate request they previously used to obtain their current certificate. By not going back and generating a new public/private key pair and associated certificate request, they were reusing keys which needed to be considered compromised based on the Heartbleed vulnerability!

What makes the management of keys and certificates so painful?

1. Quality of implementation of cryptography and key management can vary widely – it’s not just about encrypting, it’s about protecting the processes that do it, and protecting the keys against compromise or loss. The more obvious observation that compromised keys mean compromised data is paralleled by the fact that lost keys mean lost data – meaning that services that depend on that data can be ground to a halt. Increasingly, organizations are turning to hardware security modules (HSMs) to protect cryptographic processes, and automate the management of associated keys to conform with a defined enterprise security policy. There is undoubtedly some correlation between Heartbleed and the fact that the number one use case for HSMs as revealed in the previously mentioned 2016 Global Encryption Trends Study was SSL/TLS.

Heartbleed rocked the Internet to its core by its widespread nature and its origins in a simple low level buffer length issue. The lessons learned include not only practices around remediation, but also in the importance and value of properly implemented cryptography and full lifecycle key management to protect the foundation of trust in our connected, digital world.