There has already been a lot of information written about the Heartbleed bug with advice to both consumers and enterprises. What it has highlighted, however, is that once perimeter defences are defeated, the internal systems where data can reside are left vulnerable and defenceless.
Whilst this bug has been identified, the fact that user information and passwords were available in clear text shows that protecting information from the inside through a layered security approach would be the sensible way forward.
Renowned security expert Bruce Schneier of Co3 Systems rates the severity of the bug 11 out of 10 and goes on to say that due to the incredible length of exposure, even if patched we must assume that all private keys have been compromised, all passwords have been stolen, and anything really is vulnerable.
The OpenSSL protocol is widely used and adopted and had presumably been vetted for bugs. Top security researchers, safe coding practices and market-leading security solutions were not able to identify and remediate this flaw for over two years. The fact that an exploitable bug in code was made possible sends a strong message to enterprises that sensitive data requires more than network-oriented defences.
Certainly, Heartbleed is one of the most serious security flaws discovered, but as we’ve seen previously with the Android Master Key vulnerability and the Target data breach, once perimeter defences are broken, the crown jewels are exposed for the taking.
The Heartbleed bug changes everything about what must be considered as viable attack scenarios for server side exploits. Specifically, server memory–scanning is possible and the internal data has now been proven vulnerable. Perimeter defence alone will only delay the next breach in which the heart of the enterprise is exposed once again.
What Can (And Should) Be Done?
The immediate actions for businesses and consumers are relatively clear. As new vulnerabilities are discovered, there is a reactive need to patch systems and update security protocols.
In the case of Heartbleed, there is overriding consensus amongst security professionals that any organisation using OpenSSL needs to revoke their current certificates and reissue new ones through their Certificate Authority. But following that, organisations should be asking “how can I make sure that a bug like this won’t leave me vulnerable in the future?”
The next steps would be to secure the data and protect it from the next memory-centric attack, preferably through data obfuscation. This can wrap sensitive data such as user credentials and IDs so that they are protected from being sniffed out in the first place.
The way the Heartbleed bug works is it enables the dumping of heap memory in 64KB chunks. The attack leaves no trace and can be done multiple times to grab a different random 64K of memory. This means that anything in the memory is vulnerable. However, with data obfuscation, it will render the contents of the memory unreadable should it fall into the wrong hands.
Similarily, durable key protection, such as white-box cryptography, can also be directly embedded into the server side code to protect enterprise server keys and certificates from compromise, so that even if server side keys were pulled down, they would not be in clear/plain text or usable .
Alongside re-generating all vulnerable OpenSSL certificates, security solutions need to be durable, resilient and renewable. Providing data obfuscation and key protection through software-based Guards (security controls) can extend the enterprise’s defence to the via the application layer where the data actually resides. There has been much said over the years about deploying a layered and holistic approach to security and Heartbleed shows how relevant and important that advice now is.