(RNN) - The panic about the Heartbleed bug seems to have come and gone without major disruptions, but there is more to learn from the latest widespread threat to people's online security.
Much like the Y2K panic that gripped the world before the turn of the millennium, the doom and gloom, worst-case scenarios did not happen - save for the headache of changing a ton of passwords.
That didn't mean, however, the hoopla was all "sound and fury, signifying nothing."
"The reality is the reason [chaos from Y2K] didn't happen is because everybody panicked about it," said Chester Wisniewski, a security adviser from Canada-based Sophos. "If we hadn't had so much of a panic over it, it would have been a freaking nightmare. The fact that everyone panicked meant we all went out and did what we needed to do."
Nick Sullivan, head of security engineering at CloudFlare, gave similar praise to the public awareness raised about Heartbleed and the pressure it put on companies to fix what could have been a more massive problem.
However, the way information about the bug was distributed opened a discussion about how the situation was handled.
CloudFlare, one of the largest content delivery services in the world, was notified about a week before Heartbleed became public knowledge. Akamai, an equally large provider of cloud services, was also made aware in advance.
Sullivan would not reveal the identity of the person who called his team with a heads up. However, a researcher for Google named Neel Mehta and researchers from Finland-based Codenomicon are credited with making separate discoveries about vulnerabilities in OpenSSL's communication function, known as its "heartbeat." Codenomicon subsequently coined the name Heartbleed and established a website to alert the general public.
According to Sullivan, it was logistically better to provide advance notice to service providers whose reach was far greater than individual companies.
"It makes sense they could get more bang for the buck letting [Akamai] know ahead of time and letting CloudFlare know," Sullivan said. "Let one person know who's trustworthy, and at same time you get to help the largest number of people. CloudFlare has 2 million sites hosted on its servers. I have no specific knowledge as to whether or not who else was notified and why."
One of the most infamous cases of Heartbleed's exploitation against a large organization was the hack of the Canadian Revenue Agency. Like most other organizations and the rest of the general public, the CRA found out around the first week of April.
The agency lost hundreds of social insurance numbers, despite cutting services after learning of the breach.
Wisniewski questioned the way software researchers informed companies.
"That's a double-edged sword to me, in that it's great that those companies fixed their stuff before everybody found out and started attacking it, but all these things were left vulnerable," Wisniewski said. "So when we find something like this, how do you responsibly tell the world about it, try to minimize the ability for people with malicious intent to hurt people and give the good guys as much time as possible to get it cleaned up?
"I don't think there's a good answer for that, but we all have different opinions."
More than a month later, there are still some websites that have not taken action.
Major corporations running processes that rely on OpenSSL - the encryption library vulnerable to Heartbleed - have patched those weaknesses. But websites that serve a smaller amount of people may not have.
It's possible those sites are inactive or run processes that do not place people's online privacy at risk, but Sullivan said those types of loose ends are examples of internet-specific problems.
"Anytime software is involved, especially complex software, there could be a flaw or a bug," Sullivan said. "You have to make sure there are redundant protections there."
Inaction on the part of online consumers also comes into play.
A recent Harris poll conducted for identity theft company LifeLock showed almost half (47 percent) of people who know about Heartbleed still have not changed their online passwords, despite repeated warnings from industry professionals to do so.
Experts acknowledge the vulnerability in OpenSSL existed for at least two years, even though it was not discovered until late March or early April.
There were reports the National Security Agency and criminals knew about and exploited the bug for all or the majority of that time, something the NSA denied.
But since it was easy to attack the vulnerability in the OpenSSL heartbeat function anonymously, there may never be a way to know who was exploiting it and for how long.
"We don't know if the government had it and was using it to spy on people. We don't know if random criminals were using it to steal people's passwords," Wisniewski said. "We don't really know if any of that was happening. All the evidence suggests no one was using it until the day it was discovered, and then once it was discovered people tried to use it maliciously."
Part of the NSA's function is to search for and report security risks like Heartbleed, which led to speculation the agency secretly used it for its own purposes.
However, there are several corporations that have dedicated resources to doing the same thing.
Google, Microsoft and Facebook offered "bug bounties" in 2013, providing incentives for people to audit OpenSSL and similar products. All three companies use OpenSSL in their site functions.
OpenBSD Foundation, a Canadian nonprofit, is working to identify flaws in the code and rewrite it. Linux Foundation is pooling donations and programmers to look for bugs in OpenSSL.
Also, the OpenSSL Foundation tasked itself with providing financial and technical support for a program that has somewhere near a half million lines of computer code.
All those are major steps, Wisniewski said, in providing greater protection for the public at large.
"Sometimes it's better to use a screwdriver instead of a Swiss army knife," he said. "We know the more code that's in your program the more likely there's going to be a bug. Do we need 100,000 lines of code or can we get by with something that's only 3,000 lines? It's a lot easier to audit the code and find bugs in something simple."
Copyright 2014 Raycom News Network. All rights reserved.
