Non-Techie Ways To Prevent Your Company From Suffering The Next Heartbleed Bug

Being more secure doesn’t just mean hiring more security experts. Instead, try these two approaches to development.

Non-Techie Ways To Prevent Your Company From Suffering The Next Heartbleed Bug
[Image: Flickr user snoopsmaus]

Last month, Tumblr and Pinterest users received notification emails from the respective services, asking them to change their login passwords. The now infamous security bug, Heartbleed, had just popped up on their radars, and they knew it could leave their users’ data open to theft from Internet burglars. Since then, the sites have patched up their servers, but the event has opened up a new discussion over how the wide-reaching the Heartbleed bug could have been prevented in the first place.


The most common way developers protect Internet users from data theft is by incorporating OpenSSL security technology into their sites. Troublingly, many of these sites, including Facebook, Twitter, and Instagram, use the same code for these secure connections, meaning they were all susceptible to the same security threat as Tumblr and Pinterest.

So how can technology companies prevent a Heartbleed-like loophole in the future?

What Exactly Is A Security Threat?

There are two real courses of action to preventing security loopholes from causing problems in your company.

  1. Ditch older languages. Newer coding languages (which don’t usually have OpenSSL libraries) may inherently guard against this brand of theft. A language called Jeeves, previously reported on FastCo.Exist, is an example; a closer look at the language reveals that its approach to memory allocation, as well as information flow, keeps many security errors at bay.
  2. Don’t fail to keep abreast of advances in security technology. These days, there are lots of companies producing educational content to help their users prevent security breaches. The popular CDN and security provider CloudFlare has been educating web professionals for years on how best to secure their sites and also develops its own techniques that offer an alternative to OpenSSL.

This year’s Heartbleed is not an isolated incident. There have been other types of attacks on the SSL/TLS protocol in the recent past. Last year, there was Lucky13, and Beast appeared the year before. The Heartbleed bug only affected websites whose SSL/TLS protocols were implemented in OpenSSL. The code had a two-year old gaping hole that a few Internet perpetrators figured out how to exploit this year. The hackers could have possibly downloaded private information that users gave to these websites, like passwords or banking information. The above video from Elastica gives a thorough explanation of the bug. Still, more types of web assaults occur, like the DDoS attacks that make use of huge botnets to attack a specific server. And last Thanksgiving, Target Corporation’s human errors got the best of its customers’ credit card data.

So while not every security threat is alike, but understanding how different technologies could curb potential threats should be universal.

Solution 1: Pick A Different Language

One of the issues that makes it difficult for sites to account for their data is its choice of development language on the backend. OpenSSL is written in the C language, a language which requires coders to manually manage memory allocations.


Languages with runtime programs that de-allocate and allocate memory automatically for programmers make it easier for these coders to avoid the type of mistake that led to Heartbleed in the first place. Called garbage-collected languages, most newer languages, like Java and Python, fall in this class, but C does not.

“Any language that manages memory for you makes the program much less susceptible to a bug like Heartbleed because there’s just these whole big classes of memory errors and memory vulnerabilities that don’t exist anymore,” says Jean Yang, a PhD student at MIT.

Yang and her group developed a research language called Jeeves to take garbage-collected languages one step further than just automatically managing memory for programmers. These languages typically still contain “missing active control check” errors, which could translate into a situation where a site, like Facebook, accidentally could leak some of your private pictures to the public sphere. This time, the error would arise not out of memory mismanagement but out of some other coding oversight.

Jeeves lets programmers attach a policy to a piece of data, like a private photo, so that the data is consistently protected throughout the site, regardless of incremental changes to the backend code. Now, coders are prone to letting data treatment slip since they have to manage information-flow policies by hand, reviewing every instance of sensitive values in the code. Jeeves lets the programmer declare the photo “private” once and ensures it will stay private.

The language is yet another way of alleviating manual stress on programmers when it comes to managing privacy. “What we’re trying to do is make information-flow policy languages in the same way that, you know, Java and Python and all those languages manage memory essentially do,” says Yang.

Solution 2: Take A Proactive Approach

The most comprehensive way to make sure sites stay protected from unwanted activity is to keep reviewing its existing security policy. In the days following Heartbleed, security experts recommended that companies run regular security audits. But many people do not know where to start or do not have the resources. The company CloudFlare understands this and regularly educates its customers on the best ways to keep its privacy standards, as well as SSL/TLS protocol implementations, up to date.


“We spend a lot of time thinking about SSL here at CloudFlare, or TLS. Like, a ton,” says Michelle Zatlyn, one of CloudFlare’s cofounders. “Historically, if you look at SSL on the web, I mean, so few websites use it. And it’s because it’s very hard, and usually there’s usually a performance tax when it comes to SSL.”

Apart from educating the public, CloudFlare also sells its own security product to websites, in much the same way that Amazon Web Services does, with the additional benefit that its proprietary code speeds up its clients’ sites. CloudFlare’s brand of the SSL/TLS protocol makes sure https traffic doesn’t lag too far behind http traffic in terms of speed. “We’ve spent really a lot of time hyper-optimizing every part of the handshake to make sure that’s the case,” Zatlyn says.

CloudFlare constantly updates the security protocols its clients use, and it regularly reviews the most effective cipher suites to use for the protocols. This managed approach leaves everything security-related to dedicated professionals.

Still, the most common security techniques remain open to the public and open-source. CloudFlare makes it a point to regularly contribute to the open-source community. It has contributed to the OpenSSL protocol, with an update earlier this month. And it has created a way for the open-source web server, nginx, to validate security certificates. CloudFlare contributed its patch to the nginx community earlier this year, but before then, nginx did not have a method of validating certificates from origin computers that wished to communicate with its server.

If a third-party service, like CloudFlare’s, does not fit into a site’s business model, then understanding and tweaking the existing code is worth the effort. That could mean reviewing the site’s code line-by-line or re-writing everything in a new language, like Jeeves. “Taking a language-level approach is more expressive and ultimately lets you do more things,” says Yang.

As a coda to Heartbleed, the big websites have now banded together to pour money into the OpenSSL project, in hopes that bigger funding will translate into less sloppy code. But Zatlyn would agree that their initiative is not a cure-all. Securing a website requires iteratively adding layers to the code, continually improving it. She says, “You can never think you’re 100% secure. It’s almost like a marathon.”