Are IoT Devices "Pollutants" to the Internet?

IoTPollutants-header.jpg

I have written a couple of times about how poorly designed IoT devices are threats to our infrastructure and “pollutants” to the Internet. I want to tie that idea back to the importance of managing open source in the IoT market.

The Mirai attacks exploited a design weakness in the targeted IoT devices. Namely, the devices did not require users to change default passwords, and the attacker(s) correctly assumed that the majority of IoT device owners would not bother to change the passwords on their own. When setting up a device, whether it’s an Internet camera, DVR, television, baby monitor, or doorbell, most people want to make sure it performs the desired functions. If changing the password isn’t a required step, it’s not going to get done.  

IoT Vendors - Next Steps?

One of the IoT vendors whose devices were targeted has issued a partial recall, and also posted updated firmware on their website.

Yeah, that will fix things…

Most users may not know that their devices are affected, and are unlikely to install patches. (When was the last time you updated your router’s firmware?) Further, most IoT consumer likely don’t understand that a device or application may include undesired features or functions that allow these types of attacks.

Software Security Awareness

In many ways, IoT device manufacturers are just as naïve as their consumers. A design flaw like this demonstrates a complete lack of awareness of software security and a complete disregard for the people, systems, and services that rely on the Internet for commerce and vital services. The inability to update these devices remotely or push fixes to consumers ensures that this will happen again as the codebase ages.

Software does not always age gracefully.  The longer a codebase lives, the more likely it is to have vulnerabilities discovered. For example, take a look at the graphic below from Black Duck’s OpenHub; it shows the number of vulnerabilities in different versions of OpenSSL.

the number of vulnerabilities in different versions of OpenSSL

As shown, components in the version 1 “family” show many more vulnerabilities reported. This is expected, since the code has been available longer. We can see how exploiting the code would become easier over time.  

By itself, this is not a problem. But what if an old version of OpenSSL was used three or four years ago in an IoT device that does not allow simple, automated updates? 

Now we have a problem.  In fact, more than one.  Since January, 2013, 96 vulnerabilities have been disclosed in OpenSSL. Sixteen of those were scored “high” or “critical” by NIST – not including Heartbleed, which only earned a CVSS score of 5.0!

Is a Cyber EPA the Next Step?

I’m not criticizing these vendors for having bugs; no software is perfect. Developers make mistakes, and researchers will find new vulnerabilities in the open source used in software. In fact, we know from our Open Source Security Analysis that 67% of the commercial applications that use open source have vulnerabilities in those components. 

Instead, I’m arguing for accountability for manufacturers producing poorly designed and executed IoT devices. Hopefully we can address this at the industry level. It would not surprise me, however, to see regulators stepping in to protect the internet environment and punish IoT polluters. Device manufacturers can help themselves by taking software security more seriously, and ensuring that software updates or patches can be applied remotely. Consumers of these products can help by following basic security best practices. 

The State of Open Source Security

0 Comments
Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.
0 Comments

MORE BY THIS AUTHOR

Examining Vulnerability Criticality When Risk Ranking Vulnerabilities

| Feb 16, 2017

Every organization starting a security testing program struggles with addressing vulnerabilities. With limited resources in virtually all organizations, prioritizing this work is a requirement. My previous post explained three steps to risk ranking your applications. This is critical because,

| MORE >

We All Share Responsibility to Secure Code

| Feb 2, 2017

It's indisputable that open source software is an essential element in application development worldwide. Its benefits in reducing dev costs, promoting innovation and accelerating time to market explain why open source often comprises more than 50% of an application's code.   There is, however, an

| MORE >

3 Things to Consider When Risk Ranking Your Applications

| Jan 25, 2017

This is the first in a series of posts about how organizations can best apply their security resources to vulnerabilities in open source components. Almost every security lead I speak to would love to have more security resources. Whether it’s people to conduct threat modeling, manual code

| MORE >