We all know that we need to take our online security seriously, but we rarely do anything to improve our own situations. Even when we hear about data breaches, the odds that we’ll go and change passwords are relatively slim. We might get occasional emails and updates from the sites we log into about our security, but we tend not to get worked up for anything less than proof someone has been messing around with our personal bank accounts.

But Heartbleed has been different.

From the first moment I heard about Heartbleed, everyone I know has been taking it fairly seriously. Part of that is due to the nature of this particular security breach: the amount of data that was made accessible by a vulnerability in OpenSSL is enormous. It would be easier to list which major websites weren’t affected than which were. But while the details of the Heartbleed breach are enough to get programmers and website publishers worked up, they’re probably too technical to really intrigue the average person browsing the web. So why do so many people seem to know about Heartbleed?

A Well-Branded Security Breach

Fundamentally, Heartbleed is different from security breaches that have come before. It’s been branded and marketed, something that no one has really tried to do historically. The traditional approach to announcing you’ve found a security exploit was to write out a brief description of the problem and send it around to everyone you expect the problem affected. There wasn’t exactly an incentive to take action.

For the researchers who uncover security breaches, there isn’t necessarily a clear benefit to promote their work in other ways, however: the status quo was enough to get them credit for their work and collect any financial rewards (like rewards offered by companies to researchers who found security breaches in their systems before those problems could be exploited).

Heartbleed’s branding may prove to be a turning point in what we expect from a security breach announcement.

That branding wasn’t a particularly major effort from the organization that launched Heartbleed.com. That company, Codenomicon, didn’t discover the vulnerability, but does help other organizations secure their systems against malicious attacks.

Miia Vuontisjärvi, a security analyst at Codenomicon, told TechCrunch that the site started as an internal Q&A that Codenomicon’s experts wrote in an effort to get a handle on Heartbleed’s potential impact.

“Experiencing the pain of the bug first hand we got a nagging feeling that this calls for a ‘Bugs 2.0′ approach in getting the message out in an emergency. Ossi, one of our experts came up with Heartbleed as an internal codeame and from there on thing lead to the other. The domain was available and our artist Leena Snidate did a an excellent job in putting our pain into the logo. It all went much faster than expected.

“When the vulnerability became public we realized that this is going to be a crisis communication. We said what we had to say in the Q&A with as little litter as possible. We put it available on a low latency and high bandwidth content delivery network so that it is very accessible for anyone in the need. Based on initial reactions we did some minor edits but we quickly saw the Internet community picked the issue up in an astonishing way.”

Crisis Management in Open Source

One of the most noteworthy points about Codenomicon’s efforts is that OpenSSL is an open source project; Codenomicon had the opportunity to step in because the developers behind OpenSSL are all volunteers. When software is developed by a single company as a proprietary product, there are typically more concrete procedures to handle bugs and security breaches — usually developed in order to minimize liability for the company in question. I can’t imagine an established company being able to vet and publish information about a security breach in this fashion.

But while Codenomicon stepped up and helped make information about a particular security exploit easier to understand and share, there have been plenty of problems with open source code in the past where no one took on that sort of leadership role. That’s partly because taking a leadership role in the middle of a crisis is tough; contributing to open source code bases doesn’t automatically enable you to field questions from the press, manage a user notification process, or brand an exploit so that users will upgrade their systems.

The open source community, as a whole, could benefit from establishing some best practices on how to handle this sort of flaw. At a minimum, just creating a check list that researchers can follow to make announcements more useful to the average internet user could be beneficial. While that’s not my area of expertise, there were both good and bad factors in the announcement of Heartbleed that could be used as a starting point for such a response framework:

• Advance warning: Some large companies got advance warning of Heartbleed, which allowed them to patch their system before the exploit was announced more widely. While I have no problem with offering advance warning to companies likely to be hit hard by these sorts of breaches, there’s definitely room for a more systematic approach to deciding who to contact and how to handle the question of advance warning after the fact (if only so that complaining about not getting advance warning doesn’t become more of a story than the original exploit).
• Embedded devices: As more devices are are plugged into the internet, security announcements need to at least mention what sort of systems will be affected by a given breach. It isn’t always possible to guess how a given piece of open source software may be used, but such warnings need to be offered to the greatest extent possible.
• Points of contact: When we’re dealing with a breach in open source, where everyone involved is a volunteer, choosing who will serve as a point of contact is tough. These sorts of situations can require numerous hours to resolve, let alone to handle email. But someone has to do it, even if it’s someone outside the core development team.

Some of these points could be made easier with the application of a little money. With Heartbleed as motivation, several companies are looking at the value of investing some money into the open source infrastructure that drives their business ventures. Google, Facebook, Microsoft, and many other companies are on board to support a new group called The Core Infrastructure Initiative. Hopefully, this initiative will be enough to help major open source projects handle both security and breaches more effectively in the future.

Crying ‘Security Breach’ Too Often?

Heartbleed’s branding may be new, but researchers are starting to embrace the idea. In a post on a new vulnerability, researcher Matthew Green noted:

“First, if Heartbleed taught us one thing, it’s that when it comes to TLS vulnerabilities, branding is key. Henceforth, and with apologies to Bhargavan, Delignat-Lavaud, Pironti, Langley and Ray (who actually discovered the attack), for the rest of this post I will be referring to the vulnerability simply as “3Shake”. I’ve also taken the liberty of commissioning a logo. I hope you like it.”

But we need to consider if embracing this level of branding is a good idea for all security breaches. Embracing this sort of promotion can make it harder to get people to take action in the future: just like a child crying ‘wolf’ may not get attention when it matters, an important security breach can be lost in the mix. Reserving this level of branding for the truly crucial lapses in security is necessary to ensure it still works.

Security expert Bruce Schneier put it bluntly in an interview with the Harvard Business Review: “There’s a risk that we’re going to be accused of “crying wolf.” If there isn’t blood on the streets or planes colliding in midair, people are going to wonder what all the fuss was about — like Y2K. If you slap logos on every vulnerability, people will ignore them and distrust your motives. But it’s like storms. The bad ones get names for a reason.”

It’s also worth noting that Codenomicon helps its clients handle security issues. Making those security issues easier to understand and respond to is a brilliant piece of marketing work (along with a good deed that benefits internet users as a whole). But this sort of marketing effort is easy to exploit by companies that choose to do so. Whipping up a frenzy over relatively minor security breaches might make sense for some companies’ bottom lines. That’s absolutely not the case with Heartbleed and I’m not trying to make Codenomicon’s motives sound suspect, but it is a factor to consider as we see more security vulnerabilities branded for easy consumption.

Photo Credit: Leena Snidate