Spillover: Heartbleed’s Big Lessons, One Drop at a Time
Heart beating fast enough yet? Last week's disclosure of the Heartbleed bug caught a lot of people's attention, especially in the IT department. There's a lot we can take from this incident, even after your pulse drops back to normal.
If you’re an IT staffer, there’s a good chance you might be catching your breath right now.
That’s because last week was a bit of a wild one on the security front. I’m, of course, talking about Heartbleed, the massive bug in the OpenSSL encryption protocol that most major sites use.
(And it wasn’t the only security headache, either: The WordPress-produced Jetpack plugin, widely used by nearly all sites reliant on the CMS, had a security issue so serious that the organization updated 11 old versions of the plugin just to patch the vulnerability. That one was easier to fix.)
Now that you’re hopefully up to date and have gotten the all-clear that your SSL encryption won’t fall prey to the chain of events shown here, let’s talk about what we’ve learned from all of this—starting with that logo.
Let’s Promote Our Failures
The joke I keep coming back to when I talk about Heartbleed is one I made when I was talking to my colleague Morgan Little about the bug last week. We found the use of the logo weird, if effective. But being music fans, we both made a somewhat amusing comparison about the logo. It reminded us of the way a screamo band might promote itself back in the early 2000s. Fans of My Chemical Romance probably own closets full of shirts with logos like Heartbleed’s.
It was a simple vector graphic but easily transferrable, and—this is key—it didn’t look like something destined to be buried on a forum that only a small number of people will read. In other words, it was the opposite of most security alerts.
Maybe this led to a few snickers like the one I had with Morgan, but man, did it help people notice this bug. People with no technical knowledge of SSL actually seemed aware of what it was.
What if we promoted our security issues like that? It’d certainly ensure that more people were aware of an issue or that they wouldn’t treat it like another piece of spam blowing up their inbox.
We tend to give our good press a spit-shine and bury the bad news in a press release that few people will ever see. What if we were more than transparent when something bad happens—what if we promoted our efforts to fix the issue? It might make sure that people sufficiently care.
We Have to Stop Reusing Passwords
This one’s more for the user than the IT office, but it’s a place where your technical staff can help. The folly of the age of the web service has always been that we have far too many passwords and we never know how to remember them all.
The obvious solution here is to get rid of them entirely and replace them through secondary means, but we’re not at that point yet. As an alternative, the best thing you can do to protect your data is to limit the impact a single password can hold.
Which is why services like 1Password and LastPass, which obfuscate the passwords you have and limit the impact of a single password to a single account, are valuable. The idea is that you only need to know one password—the one that protects your password manager—and it creates new ones for all your other accounts.
Let’s put it this way: If you’re gonna have a pipe burst, it’s easier to contain when that leak affects a single faucet rather than a dozen.
IT staffs would be well advised to encourage best practices in this general direction.
Let’s Think Hard About Where Our Data Goes
When I wrote about Heartbleed last week, one of the comments I got in response got me thinking big-time.
The LoBue & Majdalany Management Group’s Michael LoBue, CAE, the executive director of the Storage Products Association, argued that this situation proves that using a third-party public cloud provider is not a replacement for securing your data locally.
“So many in association management rationalize ‘going to the cloud’ with the logic that being as safe as Dropbox, Google, Amazon is good enough,” he wrote in a comment. “Well, it might reduce finger pointing or blame when things go bad, but that has little to do right choices for the security of your organization’s data.”
I’m not going to go as far as LoBue did, and I differ with him on one major point. I think the cloud has an immense value, especially in public form, and we need to accept that security is a give-and-take in an era where everything seems to get shared freely. But I do think there’s a nugget of truth in what he wrote.
The thing is, we need to realize we’re on the hook no matter who’s hosting the files or database entries. Our org chart, even as it moves from onsite server racks to offsite phone calls with vendors, is changing. We have to have answers when services we’ve implemented (like Google Drive) or third-party vendors that run our community solutions have significant security issues. Our comfort level matters, and we should think long and hard about what data goes where.
But you know what else matters? The way we deal with issues when they arise.
Security Is Now About How We Respond
The problem with looking at a security failing like Heartbleed and saying it’s a clear reason we shouldn’t use a certain type of technology is that it sees IT’s role as only to prevent problems. Our culture is changing, and the ability to manage problems, have a strong strategy when they occur, and solve them quickly is just as important.
A good example of this is Target’s recent data breach. According to a U.S. Senate committee report, the retail giant missed clear warning signs that its system was being breached, had a vendor that was clearly not following protocol, and did not properly isolate its more secure assets from its less secure ones. Clearly, part of that was poor planning, but the company could have saved its consumers much trouble had it acted more swiftly.
Compare that to the actions of web security provider CloudFlare this month, which was so on top of things that it fixed the Heartbleed issue for its customers before it was even called Heartbleed. It even used the opportunity to encourage users to hack on its SSL certificate to see if they could break it. They did, and that’s a good thing, because CloudFlare can learn from it.
The thing is this: The world—which includes everyone from employees to end users—is pushing for more flexibility than ever. This makes things harder for technical folks, because the role of the people ensuring data security turns from being a really good locksmith to being a really good firefighter. But it’s a change that’s already here, whether we like it or not, because to shut the door too tightly threatens a wave of innovation that favors open over closed.
A good lock only gets you so far in a wide-open world.