The Real Wakeup Call From Heartbleed

In case you live under a rock, a serious security flaw was disclosed last week in the widely used OpenSSL library. On a threat scale of 1 to 10, well known security expert Bruce Schneier rated it an 11. Essentially, an attacker can send a "heartbeat" request that tricks the server into sending random memory contents back to the attacker. If the attacker gets lucky, that memory contains interesting secrets like passwords, session IDs, Social Security numbers, or even the server’s private SSL key.

Peeking under the covers of the software world
This is not yet another article discussing how to check yourself for Heartbleed, how to remediate it, or trying to figure out how this could have possibly happened. I’m more interested in whether we learn anything from this wakeup call, or whether we just hit the snooze button again.

There was nothing particularly special about Heartbleed. It’s just another flaw in a popular library that exposed a lot of servers to attack. Let’s take a look at how these libraries are built and ask whether they can be trusted with our finances, businesses, healthcare, defense, government, energy, travel, relationships, and even happiness.

Libraries are eating the world
In 2011, Marc Andreessen, who founded Netscape, wrote an excellent essay, "Software Is Eating the World," in which he describes how whole industries, like photography, film, marketing, and telecom are being devoured by software-based companies. I credit the widespread availability of powerful libraries with enabling developers to create incredible software much more quickly than they could on their own. In fact, new tools that provide what is known as “automated dependency resolution” allow libraries to build on other libraries, magnifying the “standing-on-the-shoulders of giants” effect.

Today, there are 648,740 different libraries in the Central Repository, a sort of open-source clearinghouse where developers can download software components for use in their applications. A typical web application or web service will typically use between a few dozen and a few hundred of these components. Remember, all of these components have the ability to do anything that the application can do. A component that is supposed to draw buttons is capable of accessing the database. A math library is capable of reading and writing files on the server. So, a vulnerability in any of these libraries can expose the entire enterprise.

The zero-assurance software supply chain
You can think of all this code as a sort of supply chain for software. Modern applications are assembled from components, custom business logic, and a lot of "glue" code. In the real world, supply chain management is used to ensure that components used in making products actually meet certain standards. They come with material data safety sheets, test results, and other ratings. This whole process is managed to ensure that the final product will work as expected and be safe to use 

But there is no assurance in today’s software supply chain. There are plenty of security features, but that’s not assurance. Assurance evidence comes from activities that tell you if the defenses are any good. Direct evidence is derived from verification or testing of the application itself. Indirect evidence tells you about the people, process, and technology that created the code. Wouldn’t it be nice if it were possible to choose components based on whether the project takes security seriously and can prove it? Today, that’s impossible. There simply is no framework for capturing and communicating assurance.

Don’t hate the playa – hate the game
It’s tempting to think that Heartbleed is an isolated incident created by a single developer mistake. In fact, Theo de Raadt, the founder of OpenBSD, writes that wrongheaded attempts to improve performance prevented standard security protections from working, and concludes that “OpenSSL is not developed by a responsible team.”

I don’t believe in blaming a team of volunteer developers who build software and give it away for free. Actually, I’d like to take this opportunity to thank the OpenSSL team for its hard work and offer my support. Our challenge is how to help all software projects to be more like OpenBSD, whose security page provides considerably more evidence than most projects.

It’s time to admit it – we have a library security problem
Please don’t misunderstand. This isn’t about open or closed source. I am a huge supporter of open-source. I’ve written it, donated my work, and run a large international open-source foundation for years. Open-source has the opportunity for a better assurance case, but it’s just not good enough to say that something is secure solely because the source is available. The fact that a bug like #heartbleed can exist for years without being discovered is all the proof you should need.

There are three serious kinds of problems with libraries that everyone should be concerned about:

Unfortunately, the information required to address the library security challenge isn’t widely available. That means architects and developers can’t make informed decisions about what components to include in applications. I think we all need to do a better job of asking software projects to provide the assurance evidence we need.

As software continues to eat the world and becomes even more critical in everyone’s lives, we will either figure out a way to generate assurance and communicate it to those who need it, or we’ll keep making bad choices and experiencing increasingly damaging breaches. The FDA "Nutrition Facts" label was initially scoffed at and took decades to become popular. What do you think? Would a “Software Facts” label catch on?