The aftermath of the heart bleed bug crisis

Written by Peter Rietveld and Bram van Pelt.

A preliminary Post-Mortem of Heartbleed. A lesson in Crisis Management? Last week was Heart Bleed week. It was what experts call the biggest security breach in the last years. Both the regular and specialized press have spent a lot of time explaining what this is and how it could be fixed.

You would expect that everything on the subject is said by now; the fix is known and already applied in most cases. It was just a bothersome bug but we can get back to business as usual. Right?

No. The Heart Bleed bug reveals how we deal with this kind of crisis. With all the efforts put in structuring security over the last years the process should have been established by now. We will be exploring the handling of the crisis in this Post-mortem to see what went right and where we need to improve.

The recovery operation applied for the Heart Bleed has been extremely pragmatic, not to say, it looks a lot like chaotically applied emergency bandages. If this is not going to improve, next time we will be in the same situation again. And furthermore; this crisis is far from over.


The news of the Heart Bleed bug came at us through the mainstream press, the security press and through Twitter from all sides. That was very nice. Why did it happen like this? Because it is a critical gap in a product used on a massive scale (two-thirds of all Internet-enabled devices is said to use OpenSSL. Similar gaps also occur in less commonly used software. Indeed, there are almost no product with a use as wide as OpenSSL. If your organization depends on the mainstream media for security alerts you will miss nearly all critical defects in any software less important. or Slate magazine normally pay no attention to software bugs.  It is very likely that your organization has more than the most common used software out there. So if there is a super critical bug in it now; would you know of it? The answer is almost certainly negative.

It is somewhat of a coincidence that this bug has drawn so much attention. The very critical Pass The Hash attack discovered in 2013 affected almost certainly a larger part of the world than Heart Bleed – since it affects all networks with Microsoft products on it. But the press did not run the story – and if your business is depending on information drawn from the mainstream press, your organization missed it too.


How quick did we know the full impact of Heart Bleed when the news arrived? Have we established the full impact already?

How could you figure out on what machines the faulty software is running? OpenSSL has been tucked away in many products deep under the hood, even in products where you least expect it. OpenSSL is sometimes even embedded in hardware. Now, there is the well-known test tool but this test only tests websites. OpenSSL is not only embedded in websites, but in many other products such as VPNs, directories, mail servers, and many more. So how do you know if you’re vulnerable to Heart Bleed bug or even more important how would you know when the crisis subdued?

Of course you can wait until the vendor reports something. A survey of some major suppliers makes it clear that you must be following the staff blog to pick up onthis. At other companies you need to check the security advisories, while some vendors have nothing to offer or ask patience to find a solution. There are no standards for this type of news, so it is not easy to make a proper inventory. Moreover, you should know exactly what you have in-house and which suppliers you have to look for to fix a certain bug.

Another approach would be to start testing yourself. The test tool mentioned above is only suitable for websites, but that does not mean that it is difficult to test other systems. Indeed, it is possible to test other systems.

The Heart Bleed bug is an error in a specific SSL function. This function, the heartbeat function, has been proposed and written by Dr. Seggelmann and is intended to maintain an SSL session when the underlying protocol cannot handle sessions. Instead of ending and restarting an SSL session, the client sends out a heartbeat call. This call keeps the SSL session open so that no new ‘expensive’ SSL session should be started.