Is the Internet broken? According to some, it may be. A newly discovered bug dubbed Heartbleed is capturing attention. As each hour passes, more information is revealed. With the desire to provide useful insights, the tech world - and even the mainstream media - is awash with stories.
What's the deal?
Sometimes it’s hard to cut through the flood of technical information to get a solid sense of what needs to be done. The challenge is distilling down to the actions we need to take for our organizations, ourselves, and how to guide those we serve.
Rather than rehash what others have done well, here are:
- Five steps each organization needs to take (now)
- Three actions each individual (including us) needs to consider
- Insights into how we explain this to others (and the opportunity we have)
What’s at stake?
Trust.
Transport Layer Security (TLS) is broadly used to encrypt and protect information in transit. The Heartbleed bug allows an attacker to gain access to the memory, siphoning off whatever happens to be stored: usernames, passwords, credit card information, and even the private keys of the server.
The popular comic xkcd explained the bug brilliantly today (see it here).
The way we respond and communicate with people has a direct impact on trust. It's imperative we get this right.
Note: Canada shut down the tax system in response to Heartbleed. The Canadian tax deadline is April 30. That means they made a nearly impossible decision during the busiest time of the year. They even shut down additional sites/systems this morning and plan to test and verify the elements. It's a courageous decision designed to maintain trust and ensure people are not at risk.
Perhaps liability.
Especially now that US Regulators have started to warn banks. They've even suggested banks should encourage their customers to change passwords (I heard the collective groan - see below for ideas).
It's possible that organizations that fail to act may be liable in the future. It's too soon to tell, for certain. The responsible action is to follow the actions below and avoid serving as the test case.
First step: the five immediate actions to take
Use this as a checklist to make sure your team took these actions. Or share it with your executives to show them the steps you took (and why). Then use it as a guideline for how to break it down and explain this to the people we serve.
1. Check for the bug in your own systems; this is broader than web servers
The specifics of the bug impact the TLS protocol with the heartbeat extension (hence the name Heartbleed). Initial coverage and focus was on the sheer number of Internet servers using openSSL and the large potential risk this bug poses.
Introduced into the code over two years ago and somewhat difficult to detect (in many circumstances), we need to assume in most cases that any system or device running a vulnerable version of openSSL over might have been compromised.
The latest reports confirm this bug impacts hardware and software in a whole range of commercial and open source solutions, including routers, virtual servers, and popular software packages like Tor (https://blog.torproject.org/).
Anticipate more reports with more devices - including purpose built solutions and industrial control systems to be next.
Consider the elements on your network, in your systems, and part of your solutions. Recognize that sometimes the elements that rely on openSSL is not always evident. When in doubt (and it's good to be a bit doubtful), test. When testing, check interconnected systems.
2. Patch where possible.
Most Internet-facing servers are designed to be patched. And most already have patches available. However, given the growing nature of affected systems and devices, it may take a few days before patches are ready for some devices and solutions. That requires a combination of diligence and patience.
After patching, test again.
Often patches are applied without the need to restart machines and services. In this case, some reports have surfaced where people need to restart. The key is to test and verify the success of applied patches.
In the rare circumstance where patching isn't possible, gather the team to assess and plan. If you run into one of these situations, reach out for help.
3. Revoke, re-issue and re-install the SSL certificate(s)
This is key (no pun intended). This is also an area a lot of people are likely to overlook or, worse, skip because they think they weren't affected.
“If you’re not going to get a new cert, you’re missing the point of this bug,” explained Jason Soroko, Head of Malware Research, Entrust - A Datacard Company.
The fix isn’t complete until the cert is revoked and re-issued.
4. Assess the situation
In the event you captured and kept TLS logs, take time to review the logs and look for signs of compromise. If the logs aren't available, minimally assess if/how/why people need to change their passwords. Determine what, if any, other information could have been compromised or impacted.
5. Communicate clearly, and transparently, to employees, partners and consumers
Clear and transparent communication is key to trust. When explaining the situation, outline the steps you took and confirm you revoked and replaced the certificates. Explain any potential impacts. Ars Technica is an example of an excellent announcement (read it here).
We’re already seeing signs of “yup, we patched” surface. The problem is those messages fail to inspire the confidence that they revoked the old certs and issued and installed new certs.
Jason Soroko explained, “ It is highly likely that this event will lead to spoof emails claiming to come from your organization, directing your clients to fake websites in order to harvest credentials. Help educate your clients in your communication by encouraging them to physically type in the URL. At a minimum, do not hide the URL, which is what a phish email will look like.”
What’s the reasonable response?
Depends on the size of the organization and the size of your traffic. Large, heavily trafficked sites are already updated(or should be). You may fall into that category. Use this checklist to confirm and review the actions of the team.
Smaller sites may take longer to assess and act. Some sites rely on third parties and organizations to maintain their sites. It is important that they understand and follow the five steps outlined above. Based on workload and the time to get the certs revoked and reissued, it may be a few days or weeks.
Keep in mind that in all cases, it is important to review partners and interconnected systems.
Individual actions: for us and those we serve
1. Check to see if a site is vulnerable
While this is widely reported as potentially impacting two-thirds of Internet-facing servers, some sites do not rely on or use openSSL. Those sites may not be vulnerable. The majority of sites, however, do use openSSL and either need to patch it or they already did.
One way to find out is to run a test using a website or browser plugin (a quick search reveals 2-3 popular options). At this point, these checks look to see if the site uses -- and patched -- open SSL, but not necessarily if the certificate was reissued.
I chose not to share the links because in some cases, their use could be deemed illegal (read here). We’ll need to explore this more in the near future. In the meantime, an alternative for checking large/popular sites is to check one of the public lists of updated websites maintained by several tech sites.
2. Check to see if the site certificate is updated
The complete fix requires revocation and re-issue of server certificates. If a site passes the check for updating the patch, it is still importance to check for a currently re-issued cert (after April 7, 2014).
Soroko points out, “A browser user is only a button click or two away from SSL cert information, but looking at the certificate date does not guarantee safety because a user would not know if the correct patches have been applied. It is more important to rely on certificate revocation and use the publicly available vulnerability checks. (eg. https://www.ssllabs.com/ssltest/analyze.html?d=yahoo.com&hideResults=on)”
Explaining this to less technically savvy people is likely to be a challenge. Ideally, someone develops an automated method to check for the patch *and* the certificate replacement. (Update: looks like LassPass offers this checking for their users. No endorsement, but I hope others do this, too).
In the meantime, Soroko suggests checking and making sure that certificate revocation checking is turned on in whatever browser you use.
3. Change your password(s) see ideas on passwords below
Scout for phishing emails masquerading as Heartbleed password change notices. If unsure, type the URL for the site by hand.
Keep in mind that if you have shared or reused passwords across sites (and one of them was or may have been affected), then both need to change. It's a good opportunity to build, manage, and use better passwords; unique for each site.
What is the reasonable timeframe (for personal action)?
It seems reasonable to prioritize based on site, use, and purpose. Anything relied on or with financial information takes a higher priority.
In my case, I have over 600 passwords stored in my password manager. As sites apply the patch and re-issue their certificates over the next few weeks, I will slowly work through my passwords and make changes.
Explaining Heartbleed to others
Heartbleed poses a series of challenges when it comes to communicating with others. It caught frenetic mainstream attention during the early stages of assessing and understanding the impact. It gives new meaning to the phrase, “if it bleeds, it leads" if only because of the name.
Couple that with the reality that much of the advice is similar to what our colleagues have heard for the last two decades. That means just telling people to “change their passwords, avoid clicking on links, and use caution on the Internet,” is basically noise easily tuned out.
The good news is that in every organizational assessment and analysis I've completed over the last decade, the internal security team is regarded as a trusted source of information. It means we have some real opportunities here. To rethink how we approach and provide guidance. Given the hype and coverage of Heartbleed, we need to provide measured, sound advice.
Our colleagues and clients use our resources, and often use the same credentials on other sites. More than suggesting that they change passwords is the importance of explaining why the timing of the change matters.
Revisit how we explain the elements of TLS (https://), how to examine the certificates from the browser (and why they might want to). Share why it makes sense (instead of simply telling them) to manually type in the URL they want to visit if they are uncertain if the site is safe.
Invite people into the conversation and be prepared to answer questions in a way that makes sense; if you don't know the answer, offer to get back to them. Done right, this leads to a higher level of awareness (see the definition) and a step toward stronger relationships and more security-conscious actions.
The conversations and solutions we need to explore
When Heartbleed winds down, we need to collectively step back and reassess the challenges and opportunities of the industry. We need to explore the challenges we really need to solve.
It likely means discussions about:
- Trust and authenticity on the Internet
- Certification revocation
- The role and potential need to implement perfect forward secrecy
- If we need to consider promoting the wider adoption of two-factor authentication (although the first step is to get basic authentication right - read the 3 steps here)
In the meantime, focus on the five actions for each organization and three steps each of us needs to take. As this unfolds, we'll continue to look for ways to engage and advance the conversation.