Blog post

Heartbleed hit your APIs too…Manage those dependencies!

By Gary Olliffe | April 16, 2014 | 1 Comment

With all the media coverage of Heartbleed over the last few days it occurred to me that there has not been nearly enough coverage given to the impact of Heartbleed on web APIs, both from the perspective of a consumer and provider.

When it comes to Heartbleed’s impact on and web API’s I have to admit to having a little bit of an “I told you so” moment.   On March 21st 2014 I published my Gartner research document Managing Service Dependencies in the Extended Enterprise, just 16 days days before Heartbleed was first announce on April 7.   In my research I explain why and how to identify, track and manage our service dependencies in the ever more connected world of digital business.

Heartbleed is EXACTLY the kind of scenario that will leave you wishing you had a complete and consistent reference for those dependencies, whether you are a provider, consumer or both.   You need to know the services are you using, the services are you providing, who is using them, what you and the other party need to do to protect yourselves and whether it has been done.

If you weren’t already on top of managing those dependencies your Heartbleed response also gives you a great opportunity to get started.  As part of the fire fighting you will have to identify where you are providing or consuming services over SSL, the level of sensitivity, complete the patching, reset API keys, reset credentials, communicate to stakeholders, etc.   Once the situation is under control you or your team mates should have a pretty good picture of the current state and I recommend you use that to get a jump start on cataloging (or updating) your service metadata.  And if you are a Gartner for Technical Professionals subscriber there is plenty of guidance in Managing Service Dependencies in the Extended Enterprise.

By now we’ve all seen the guidance to the general public about changing passwords (once the sites have been patched), and I’ve made a concerted effort to not only reset passwords but to make them stronger and unique at the same time.  This was time consuming and laborious, but I felt better for it at the end… like having a de-clutter at home.

Do the same for you API portfolio… metaphorically box them up, categorize them, label them, and know where to find the provider or consumer. Life will be much easier the next time you need to communicate an update or issue, check on the service status or deal with a global internet security threat.

If you are still patching your API service, communicating to your consumers or chasing down API providers…good luck and when it’s over take a pause and think about how to make it easier the next time.

And if you want to hear more you can join me at Gartner Catalyst 2014 in San Diego (August 11-14) where I’ll be presenting a session called “Using Public APIs : Manage the risk to reap the reward” … see I told you so!

If you have comments or experiences to share about how you are dealing with the impact of Heartbleed on your API provision or consumption please comment below or feel free to get in touch.


Leave a Comment

1 Comment

  • Mark O'Neill says:

    Great point, and it reminds me about how people focus on the impact on Websites of DDoS attacks, but never on the impact on Web APIs (which are often affected too). I guess that apart from geeks, people still think that the Web as all about Websites, and don’t see the “dark matter” of Web APIs.

    I must admit I am from a vendor (Axway) but I believe this shows a clear need for an API Catalog to inventory APIs which are used inside and outside the organization, and an API Gateway as a control point to apply “virtual patches” to rapidly deal with issues such as Heartbleed. I’ve continued the conversation over on my blog here: