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 Relevant Products/Services group that aims to break down technology silo barriers and drive better big data Relevant Products/Services access with improved integration between digital Relevant Products/Services 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 Relevant Products/Services library. The weakness, they said, steals information typically protected by the SSL/TLS encryption used to secure Relevant Products/Services the Internet.

Connecting Everything

We caught up with Ed Moyle, director of Emerging Business and Technology, ISACA Relevant Products/Services, an international professional Relevant Products/Services organization focused on IT governance Relevant Products/Services, 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 Relevant Products/Services 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.”