My Conclusion from the Heartbleed Timeline
This tweet encourages people to read the timeline related to the Heartbleed discovery and dissemination and draw your own interesting conclusions – challenge accepted!
There is plenty of fodder in there for the conspiracy theorists, but taking a step back for a second I would draw a conclusion not based on who knew what, but rather how to be one of those entities that knew early. Why take that approach?
Well, the companies that learned of this bug early (the timeline lists the ones that admit they did, there were likely others) had a significant advantage here. They were able to take the necessary steps to protect their systems while the bug was largely unknown, they could evaluate the situation calmly and without their customers/shareholders/interested parties screaming for updates, exposure assessments, time lines for fixes and the like.
As an ex-operations guy, an ex-support guy and someone that’s had to deal with this stuff before, I would definitely like to be working for one of the companies with an early heads up here rather than the ones in the dark until the public announcement.
Hence, the question I would ask is this: How do I make sure that I am on the early notification list for such issues?
Now, that may seem way too broad a question, but let’s break it down another way:
- What technologies are truly critical to my business?
- How do I ensure that I am up to date immediately regarding significant developments?
- How do I ensure I can prioritize features, get key issues for my business addressed?
Sometimes, with closed source technology, the answer is simple – you make sure you are an important customer for the owner of the technology, whether it is Microsoft, Oracle, Cisco or anyone else. This might be a matter of paying them enough money, or it could be that you make sure you are a visible and valuable partner, provide a nice reference use case etc. – basically whatever it takes to make sure that you are at the top of their list for any vital information flow or feature decision.
What about open source software though? How do you make sure you are similarly informed for the Apache HTTP web server, the HAProxy load balancer, OpenSSL, the Linux Kernel, or whatever OSS technology your business relies on?
Take a look at that timeline again, consider who learned about the issue early. I haven’t crunched the numbers, but I’d bet good money that the companies that learned early (and were not part of discovery) either have a significant number of employees contributing to OpenSSL, or they have employees that know the main contributors well (and let’s face it, most of them will be contributing to other OSS projects – geeks and nerds gossip just like everyone else).
Therefore, the conclusion I draw from the Heartbleed timeline is this:
If I am using open source software that is critical to my business, I should be employing people that actively contribute to that software, that are known to the core developers, if not core developers themselves. They will work for me, but devote a significant portion (perhaps all) of their time to the specific project(s) identified as critical.
There are many benefits to this – besides getting early notification of issues, you would have an expert on hand to answer those screaming for updates, to evaluate your exposure and perhaps even fix the issue internally before the public fix is available. You also get a respected voice in terms of setting the direction of the project, have a way to prioritize key features and more. Finally, you get the good will of the community, help make the product better for everyone, and become a possible destination for other smart contributors to work.
The key here is about actually committing resources. It’s often amazing (to me) how quickly the commitment of actual resources will focus an otherwise overly broad discussion. If you start by asking people to list all of the OSS technology that is critical to the business, you will likely end up with a massive list. Now tell them that they are going to have to commit headcount, budget to support every piece of technology on the list (and justify it) – it will likely shrink rapidly.