Major technology vendors have been pressing hard on the Internet of Things (IoT), but the Heartbleed bug could bring a disconnect before the movement ever gains momentum.
About two weeks ago, Cisco, IBM, GE and AT&T launched the Industrial Internet Consortium, an open membership group that aims to break down technology silo barriers and drive better big access with improved integration between digital and physical worlds. IoT believers were rejoicing.
Heartbleed is a wakeup call. Impacting most of the Internet, Heartbleed could give hackers access to user passwords and even trick people into using fake versions of popular Web sites. Security engineers at Codenomicon who found the bug, are reporting that the vulnerability is in the OpenSSL cryptographic software library. The weakness, they said, steals typically protected by the SSL/TLS encryption used to secure the Internet.
We caught up with Ed Moyle, director of Emerging Business and Technology, ISACA, an international professional organization focused on IT governance, to get his thoughts on the IoT-Heartbleed connection. First, he told us it’s a monumental bug in that up to 66 percent of the Internet is potentially impacted, according to Netcraft data.
“One significant area that has been covered less in the industry press is the impact this issue could have outside of the population of vulnerable Web servers,” Moyle said. “Now clearly, the impact to Web servers is a big deal. But consider for a moment what else might be impacted by this. Here's a hint: it's Internet of Things Day today.”
Moyle explained that OpenSSL has a developer-friendly license, requiring only attribution for it to be linked against, copied and pasted or otherwise incorporated into a derivative software product. Of course, it’s also free. According to Moyle, all this makes it compelling for developers to use OpenSSL for anything that requires SSL functionality, including toasters to ICS systems, medical equipment, smoke detectors, remote cameras, consumer-oriented cable routers and wireless access points.
Weeds and Thorns
“The underlying reason for the wide reach of that problem is that the code for ASN1 parsing was reused and recycled so extensively in other products,” Moyle said. “Because ASN1 parsing is hard to do, finding code that does it already and incorporating it into derivate software is a huge timesaver.”
Likewise, he continued, SSL functionality is complicated to write -- it is advantageous to incorporate something that is already written, like OpenSSL, particularly when doing so doesn't incur additional cost to you or lock you in to a particular operating system platform, such as with OS-specific proprietary libraries.
From a practical standpoint, Moyle sees a few ramifications. While a Web server can be upgraded easily to use the fixed OpenSSL code, he said, an embedded system is more challenging to upgrade. Recovering from this issue, then, could literally take years. So what’s an enterprise to do?
Moyle said patching Web servers is a good place to start. Organizations that run Web sites may want to get new certificates to ensure privacy. Consumers may want to change passwords to sites they frequent online. The long-term issues associated with embedded devices and specialized systems, though, are thornier.
“One thing that could be helpful is encouraging vendors of those systems to confirm explicitly -- and in writing -- that they are not vulnerable to this if they provide SSL functionality or to provide instructions on remediation if they are,” Moyle said. “By doing this, organizations with a population of these devices can get an assurance that someone at the vendor has at least evaluated the issue and how it might impact production deployments.”
Ulf Mattsson, CTO:
Posted: 2014-04-10 @ 11:35am PT
I agree that “Heartbleed Bug Could Disconnect Internet of Things”, but protecting your Data can be even worse. Do it before it’s too late. Applications will continue to expose your data via different vulnerabilities.
The Heartbleed situation is not the first issue with faulty software implementation that makes strong protocols vulnerable to attacks.
Regardless if the lack of boundary checking in this open source code software implementation was a result of bad coding or a government backdoor, it can execute code that exploit data in memory.
What can we do?
We cannot wait for better software development practices or for upgrading the networks from IPSEC v4 to v6. No, this is like boiling the ocean.
Should we go back to a version of the protocol implementation that did not have the issues resulting in changing our applications and lengthy testing? No. We are lucky if we did not upgrade too fast to new unproven versions or fixes.
Instead we can proactively protect sensitive data, even in memory, with modern approaches.
This will help against other attacks on data. We should expect that preaches will happen to us.
Another recent example is Bitcoin, a strong protocol, but with 146 malware types that are exploiting vulnerabilities in the open source implementation that was rushed to market.
This never ending issue is not a new issue.
Another infamous situation comes to memory.
Many years ago Netscape key management for SSL, another strong protocol, had a faulty software implementation that made it vulnerable to attacks.
This is a never ending issue. So, protect the data flow with modern approaches as data tokenization.
Ulf Mattsson, CTO Protegrity