IoT Security Through Open Certification

The jaded nerds who’ve been around the block a few times here in San Francisco have an understandably dismissive attitude towards the use and abuse of technological buzzwords, in particular, “IoT”. It’s a bunch of embedded systems connected to the internet. Big deal. But remind them that it’s a bunch of embedded systems connected to the internet in the context of security, and the salient point is made. They quickly turn from dismissive to despondent, knowing where this is likely headed.

Obligatory Scary References and Predictions

Where is it headed? You don’t have to have prognostication to get a glimpse of the consequences of Earth being flooded with sloppily-developed firmware. The most famous case being the 2016 Mirai botnet attack. Thousands of embedded devices comprising 36 depressingly-poorly-secured IoT products with default usernames and passwords were press-ganged into “multiple major DDoS attacks in DNS services of [the] DNS service provider Dyn […] using Mirai malware installed on a large number of IoT devices. This resulted in “the inaccessibility of several high profile websites such as GitHub, Twitter, Reddit, Netflix, Airbnb and many others” (https://en.wikipedia.org/wiki/Mirai_(malware)). At volumes of 620-1024 Gbps, these attacks essentially broke the internet for many users that day.

This attack represented the lowest-hanging fruit: default usernames and passwords, internet-addressable devices. Minimal sophistication was required. More recently, someone set up ZMap to find raspberry pis with SSH on, had the default username and password, and created a worm capable of infecting millions of hosts.This probably took the author an afternoon to make.

As the number of these devices proliferate and the attacks increase in sophistication, we can also expect an increase in bad days for network admins, not to mention the hapless end user. In 2015, the FBI felt the need to issue a PSA to this effect: “The FBI is warning companies and the general public to be aware of IoT vulnerabilities cybercriminals could exploit.”

The danger is well-known and not worth belaboring for too long. The real question is: what can we do about it?

Incentives and Obstacles

The reason that many IoT products have poor security is not due to a failure of morals, bad upbringing, or stupidity, but rather, a reasonable economic calculation made by the manufacturers who are primarily concerned with marketing the device as soon as possible. Taking extra time to design, properly build and test their code only delays the timeline. Moreover, as these products are made by thousands of manufacturers, developers, and engineers around the world, a top-down regulatory approach is impractical. There are simply too many moving parts, countries, agencies, software libraries, and stacks for effective regulations to keep pace with this fast-moving target. So what can be done?

Smarter people than me say an open certification is needed to assert a minimum level of security for things connected to the internet. The system doesn’t need to be ultra-rigorous to be effective on the basic level. A simple “I’m almost certain this device is not going to get taken over and wreak havoc” stamp would be a great first step. It is also a step that many manufacturers are not taking..

Why a Certification?

A certification process can be designed collaboratively and openly, be implemented by anyone, doesn’t require action from policymakers, can have different levels of rigor, and most importantly, provides a market-based incentive to manufacturers to not make obvious and common blunders. The result is greater security and stability in this internet-connected planet. As someone who uses the internet, it is also in my personal interest to prevent devices from being susceptible to hackings. .

Setting a certification system in place is a positive and necessary measure, says respected security professionals. As consumers and institutions would prefer certified devices over unvetted devices, manufacturers would have an incentive to be certified. Additionally, governments or corporations might mandate certified devices be preferred or required.

In fact, a small number of company-sponsored certifications already have these practices in play, but as far as I can tell, they are proprietary and run by a single company. The most promising proposal comes from the Internet Society Online Trust Alliance initiative. They define a set of best practices for securing IoT devices and also take notifications and privacy into consideration. Their IoT Trust Framework provides a solid assurance that a device is trustworthy to deploy. Or at least more than any random, off-the-shelf device..

Other Options

Certification is not the only option for securing Things and embedded devices. Government policy is another possibility, although limited in its jurisdiction, scope, and ability to keep up with today’s rapidly-changing technical field. n For example,Dan Greer suggests making liability contingent on the openness of the firmware. This means that when you are more legally liable for the damage caused when using a closed-source, proprietary system, as opposed to using an open-source software.

This is both practical and reasonable, as open-source code can be audited and improved by the community, even after the original business ceases to exist. Dan Greer lays out other intelligent suggestions in his 2014 BlackHat keynote, which I highly recommend watching. One particular suggestion is his idea that devices should either be remotely-updateable (with signed updates, of course) to patch flaws in the field, or should “expire” and stop being connected to the internet after a period of time, say five years. Having insecure devices on the internet is one thing, but having un-patchable systems that stay around forever is another story. This could easily be a component in the certification.

Another more extreme approach is that some people, such as the hacker “The Janit0r”, have taken it upon themselves to release worms using similar vectors to the Mirai botnet to take over insecure IoT devices and then either brick or firewall them so they can’t be used maliciously.The Janit0r claims he has bricked over two million insecure devices so far, preventing them from being press-ganged into evil servitude. Another example is the Hajime worm. The Hajime worm has no DDoS capability and blocks ports to lock down the device instead.^[1][2]

Community and Governance

The response from assorted institutions, individuals and corporations is another reason to keep optimistic. AWS should be praised for requiring proper (mutual TLS) authentication for anyone using their IoT platform. On June 8, 2017, the US NTIA put out a RFC specifically on advancing the security for IoT devices and preventing botnets. The San Francisco Bay Area Internet Society has a new IoT Working Group to promote security and best practices for development, which I’m happy to be leading. If this is a topic you’re interested in, there are plenty of communities working to make the coming flood of Things a positive transition, rather than an internet minefield.