Looking beyond Heartbleed

We can do things now to make things a little easier should we face another widespread security defect in code like OpenSSL

I have a good idea what you spent the last week and a half doing: putting out Heartbleed fires. But don't stop now! Keep that momentum going for just a bit longer. Let me explain why.

The simple explanation is that Heartbleed was a nasty one. The vulnerability was in OpenSSL, a system library that nearly every piece of networked software relied on. Not only that, but it was used on nearly every network server we might connect to. And not only that, but it had a remote exploit that could render real business-sensitive data to attackers.

In other words, Heartbleed took all the ingredients for a massive migraine and packed them into one little bug. Now, let's do just a bit of a post-mortem and see if there are some opportunities for improvement.

First of all, why is this one such a big deal? We've had other network software zero days before and we've survived those just fine. Well, for one thing, OpenSSL isn't just a piece of network software; it's a library. Any software that was statically linked with the OpenSSL library inherits all of OpenSSL's problems. Let's hear it for dependencies!

Now, in terms of putting out the fires, you should probably have a checklist. Start with fixing OpenSSL itself. Then rebuild (or otherwise update) all the software on your system that was dependent on OpenSSL. What, you don't have a list of those? Uh-oh. Then rebuild everything. Not feasible? OK, now you're getting the picture of just how big a deal Heartbleed was and is.

And that's not even where it ends. You should probably change your password on any third-party Web and mobile apps you use. In fact, many of them have probably been forcing you to do just that. Then there's the actual data that may have gotten breached on any of those systems. Are you concerned about the credit card numbers you left on those systems? You should be.

We're going to be cleaning up after Heartbleed for a long time to come. The direct and indirect impacts of this kind of bug are big, and they don't just go away by updating one piece of software like OpenSSL.

But I said we should look for things we can do to improve. What I'm talking about are things that should make things a little easier should we face another widespread security defect in code like OpenSSL.

Clearly, what made Heartbleed such a heartache for so many people is that so much software is dependent on OpenSSL. One thing I often find lacking in terms of security management is an up-to-date inventory of system dependencies. On any given mission-critical system, it's vital to know not only what software is on that system, but all of its dependencies. This should start with libraries with which the software was linked during its build, but continue on to all of the software frameworks that were used to build the software.

So what's the difference between a linked library and a software framework used to build the software? Well, a linked library is generally a compiled library that is called from other code. Those things are connected, or "linked," when the dependent software is built. A software framework, on the other hand, is typically source code that is either compiled already or byte-compiled (like Java code) from within our code. The bottom line is that the differences are subtle, but there's one practical thing that really matters. When we change framework software, we typically need to completely recompile our own software, whereas with a library, particularly a dynamically linked one, we don't necessarily need to rebuild our own dependent software.

From a change management standpoint, that's a big deal. If you don't agree, ask your software developers when last they updated any production software simply because one of the frameworks they use was updated. It almost never happens. System libraries, on the other hand, are likely to be updated whenever our servers go through upgrade cycles.

But either way, we need an up-to-date inventory of what's in our code. When a dependency is updated, we need to authoritatively know what software needs to be rebuilt. Even changing a dynamically linked library out from underneath our production software should necessitate some testing to ensure that our production software is still behaving as we expect it to.

So, from my point of view, one of the best things we can do to help us respond to similar problems as Heartbleed is to maintain an inventory of software dependencies. We should know and have a maintained list of all the dependencies of our production software.

Building that inventory and keeping it up to date is not a trivial task by any means, but it is likely to save you some heartache in the long run. Even if you're not developing your own business software, simply knowing the dependencies of your installed production software systems is worth the effort.

With more than 20 years in the information security field, Kenneth van Wyk has worked at Carnegie Mellon University's CERT/CC, the U.S. Deptartment of Defense, Para-Protect and others. He has published two books on information security and is working on a third. He is the president and principal consultant at KRvW Associates LLC in Alexandria, Va.

Read more about security in Computerworld's Security Topic Center.

Join the CSO newsletter!

Error: Please check your email address.

Tags securityencryptionMalware and Vulnerabilities

More about Carnegie Mellon University AustraliaCERT AustraliaMellonPara-ProtectTopic

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Kenneth van Wyk

Latest Videos

  • 150x50

    CSO Webinar: Will your data protection strategy be enough when disaster strikes?

    Speakers: - Paul O’Connor, Engagement leader - Performance Audit Group, Victorian Auditor-General’s Office (VAGO) - Nigel Phair, Managing Director, Centre for Internet Safety - Joshua Stenhouse, Technical Evangelist, Zerto - Anthony Caruana, CSO MC & Moderator

    Play Video

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

More videos

Blog Posts

Market Place