As the conversations surrounding the Heartbleed bug continue to multiply, and as is the case with any widespread security breach, individually, we are often left with a lingering question: Who caused this and who is responsible for fixing the problem?
The answer to this question is often quite complicated, but part of the responsibility for cleaning up the mess rests with you, the Internet user.
Let's consider the vulnerability currently on everyone's mind: Heartbleed. More than two years ago, Dr. Robin Seggelmann, a volunteer contributor, submitted code to the OpenSSL Project to implement a new feature -- one that inadvertently included a very small error that caused a huge vulnerability. On April 7, 2014 the OpenSSL Project released an update that contained a fix for this error, but it was too late: The security community was already buzzing about the new vulnerability, now commonly known as Heartbleed, which allows a hacker to read a Web server's memory. That memory could contain personal user information, login credentials and even the SSL private key of the website that could allow the hacker to create counterfeit copies of the site, enabling even more identity theft. It had somehow leaked days prior, leading many to conclude that hackers had already extensively used it. Security experts are characterizing this as one of the most serious vulnerabilities ever, potentially costing billions of dollars and taking years to fully resolve.
In cases like Heartbleed, determining fault and responsibility can be quite difficult. For example, the industry has a generally accepted expectation that the individual who wrote the code is competent enough to do so correctly, so if there are any vulnerabilities, it is the fault of that developer. But once code is written by a volunteer contributor, it must also be accepted by the open-source software project. The project generally catches major mistakes, but could easily overlook something very small like the mistake that resulted in Heartbleed. At the next step of the equation, a consumer is potentially impacted by Heartbleed (or whatever the vulnerability may be) when a company decides to implement the OpenSSL software package on its Web servers, thereby possibly exposing private information to the hackers.
Legally speaking, companies that implement open-source software (OSS) are responsible for reviewing it and ensuring that it is safe to use. Unfortunately, this is a costly and time-consuming process that is not often followed. As a practical matter, most companies expect this software to be secure upon delivery and do not believe it is necessary to conduct their own audits. When you go out to eat and order a steak, do you check the temperature or do you assume it's been cooked properly? Same principle.
Similarly, consumers expect companies to take all necessary measures to protect their private data and not expose them to these types of risks, but it is not that simple. While a consumer may technically have legal recourse when a company causes his or her private information to be exposed, this does not prevent the theft from happening, nor does it guarantee that the victim will receive compensation. Consumers must take their own steps to protect themselves and minimize the risk to their personal information. We all know the basic precautions -- use complex passwords and change them frequently, don't click on sites you don't trust and keep your anti-virus and anti-spyware software up-to-date. But there are additional proactive measures that you as an individual can take.
One key step involves doing your homework on the companies with which you choose to do business. Does the vendor you purchased that anti-virus software from have a good reputation? Does the team complete those extra security audits that too few companies bother with? These are questions you need to ask, rather than simply waiting for someone to answer unprompted. Sometimes there are even more concrete options. For example, with a threat like Heartbleed, you can simply update your browser security settings to check for SSL certificate revocation. This means that if you attempt to visit a website that is using a stolen SSL certificate, it will stop you and provide a very obvious warning. Major browsers like Google Chrome have this setting disabled by default -- do your research and find the preventative measures that are available.
At the end of the day, while developers, software projects and ultimately companies that deploy the software are responsible for creating and maintaining software that is safe to use and does not cause vulnerabilities that could be exploited by hackers, it is important for us all to recognize that it is also up to the consumer to take precautions. Go beyond the basics of creating strong passwords and not clicking on shady sites, and remember to review your browser settings and make it a priority to hold your vendors accountable. Contact your bank, brokerage, email service provider or anyone else with whom you conduct business online and ask them about their information security practices. No one is perfect, but competent companies will communicate closely with their customers, help them understand whether their information is or has been at risk and assist them in implementing best practices for their own online defense. If any information is ever stolen, it won't be those other parties feeling personally exposed -- it will be you. Do your part to keep these risks at bay by getting personally involved in your cybersecurity from day one.