When news of the Heartbleed exploit of OpenSSL broke, the community stepped in and provided a fix almost immediately – in fact, it was provided on or before the announcement of the exploit. Very soon after, Robert Graham documented in the Errata Security blog that over 600K servers were vulnerable to the exploit. When he checked a month later, about half that number had been updated to versions of OpenSSL that fixed the exploit, leaving about 300K servers still subject to attack. Now, more than a month later, Graham’s scan shows that almost that same number remains exposed.
Sadly, this can be the only expected outcome from the circumstances. The open source was easy to adopt and apply, and many very reasonable do so. It is integrated into commercial products & enterprise bespoke applications, is an implicit dependency of other open source products, some hardware devices, and more. In many cases, particularly bespoke applications developed by third parties or by employees long since departed, there may be only vague recollection of the fact and limited grasp of where and how it is applied. Moreover, for both commercial product companies and in-house custom development shops, applying and testing the new version of OpenSSL in integration has to compete for resources that may already be saturated with work meant to increase revenue, address customer requirements, and other issues difficult to simply shelve.We must anticipate that Heartbleed will continue to be a source of risk and pain for many years to come. The best hope may only be that all the servers affected will eventually age into obsolesce and be replaced by newer models with refreshed stacks and updated applications. As Graham says, that may take as long as ten years before we can all breathe relatively easily that the password used at that last website or the contents of the last file of PCI-regulated payment card data sent won’t end up in the hands of thieves.
OpenSSL and TLS are dominant secure communication protocols in use today. Heartbleed underscores the importance of working to balance expense and data protection. It has been the least cost model to simply apply OpenSSL to transmissions to apply protection, and it remains effective for protecting data while in transit. However, the exploit exposed data at rest while in memory on the receiving server. A defense-in-depth approach that protects any sensitive information before it is passed to transmission can protect that sensitive data even if it is sifted from the memory exposed by Heartbleed. While a small amount of extra processing and coordination would be added to workflows, the additional protection could prevent many of risks Heartbleed entails.
Learn more about low effort, cost effective opportunities for increasing the depth of your protection of sensitive data here.While there is no real lighter side to the Heartbleed exploit, John Biggs rightly remarked on April 9 it is “…The First Security Bug with a Cool Logo” in his article at TechCrunch, alluding to the almost Valentines Day heart seeming to seep blood. Now, we can go one better and note it appears to have its own theme song as well….