IOT Developer Security Checklist

What you seem to propose is a separate stream of updates and security fixes. For this to work the way you describe would mean the company releasing all security fixes for every revision of updates. That's a lot of work in testing, release management, and support, and I don't expect any small sized company to bother.

Actually, I don't know of any project that does this - you may get fixes for a number of supported releases, but the expectation is that you upgrade at some point, or its eol for your product.

Agree.

While I love rust and think it (should) replace C for web servers and the like, the majority of the issues with IOT devices are just basic security oversights and design errors.

You raise some very good points:

1. Secure by default should be mandatory. MS learned that one the hard way.

2. Consumer protection laws would certainly get device builders attention. I think that is required. But I doubt the current administration is included to enact such laws.

It is a shame that devices are certified by UL and FCC, but there is no security certification or even a basic audit that would catch: security backdoors, default / blank passwords, auth over http, basic XSS and CSRF vulnerabilities etc.

The bad news is that we don't know how to design a device with Linux and internet services that will be secure without updates for 5-10 years. So we either insist on updating .... or we keep some of the darn devices off the internet.

At at minimum, we should insist on having devices that don't listen on ports just waiting to be hacked. Devices should only connect out.

IoT security is a messy problem, quite frankly. Most (is it safe to say all?) of us carry around IoT devices with us every day that are based on software with documented, in-the-wild, security issues -- and the Android ones of us are the most at risk depending on the age, manufacturer and carrier of the device.

I agree with the author's original assessment -- don't make your device internet connected (or even capable of connecting to the internet), if there's not a spectacularly good reason to do so. The downside is just too big, currently. If you plan on it, you need to proceed extremely cautiously and understand that huge companies with top-tier engineers -- Google, for instance -- haven't figured it out completely, yet. While their devices are probably better secured[0] than the IoT white-label power outlet I purchased on the clearance rack at Aldi (US), they still have a long way to go. Is that feature that allows your dish washer to send you push notifications when it's completed worth the lifetime of security patching you're going to have to do (or going to fail to do at your customer's peril)?

The biggest problem with IoT as it's done, today, is a simple one of attack surface. Every device independently accesses the Internet with a poor gate-keeper -- often a consumer-grade firewall which we hope is configured to properly firewall inbound, but is probably also running an out-of-date kernel, or has some other security vulnerability[1]. For the simpler devices, I lean more toward using the 'hub/Z-Wave/Zigbee' approach. At least with a hub, I have one device that is directly on the internet, and several that can't do much beyond talking to the hub. The problem here, though, is that none of these hubs are aiming to be the "leader in security in the IoT space", (which is why my hub is a custom-configured Linux box w/Z-Wave/ZigBee dongle[2] which I can harden myself).

The problem for most IoT devices is one that I don't see an easy solution to -- a common configuration is one of a low-capability device with a general purpose operating system on it with custom software probably written by engineers in a company that is too small to afford the necessary security auditing required -- and, effectively, putting it in the worst war-zone you could put it in. And consumers pretty-much don't care (yet), they just want the feature[3].

There was also one feature I felt was missed by the author, a hard cut-off switch[4]. We put valves on water-heaters, appliances that connect to the gas line, and just about anything of circumstance that connects to electricity. If all else fails, or if I just really wanted the Thing part of the device, I can take it off of the network in a way that leaves no ability for the software powering it to bypass. In a critical situation -- one where something prevents the device from being patched and the device will be recalled, the company can send along instructions[5] along the lines of 'you can still use it while we work out the logistics of the recall, but it'll just be a Thing without any Internet).

[0] I'm thinking 'home' rather than the general Android ecosystem since a lot of Android's problems are related to the phone vendors and carriers (at least in the US).

[1] And with IPv6 rolling out from ISPs, how many of these devices will have public IPs that will be able to be discovered every time they reach out to pick up the current time. Don't think that can't happen -- I was shocked to find that my dad's PC had an IPv6 address and a quick check from the first hit on 'IPv6 Firewall Test' yielded all red. I'm not sure how many of these devices have IPv6 enabled by default, but I wouldn't be surprised if some vendors enabled it (or didn't realize it was enabled when it was).

[2] Which have their own problems -- but the worst they could do is turn my lights on and off ... at least my lightswitch won't be participating in a bot net AFAIK. I also don't own any ZigBee door locks or the like (however, I can personally attest to the low quality of the physical lock I do have after spending a Saturday on YouTube making a 'key' based on a video that showed how to break my specific, Schalage brand 'high-security' lock).

[3] I've said more than a few times that I need to attach a smart plug to my washer and dryer because the buzzer is too quiet to hear and I always forget about my clothes during a cycle. It'd be nice to get a text message. It's a stupid feature when measured against the risk (though, as mentioned, my smart plug isn't directly internet connected).

[4] 'Hard' as in a mechanical switch that actually disconnects the Wi-Fi/network module from the hardware.

[5] And the honest ones will ship with the button in the 'off' position with the 'Connecting the Device to the Internet' part of the instructions explaining what it does, how to enable connectivity, and a little bit about the risks they're entering into by choosing to connect it.

If IoT is a messy problem and Android is the device most at risk depending on the age, manufacturer and carrier of the device then where are all of the Android based IoT attacks? Android has been around for 10 years and nothing has materialized. What ever happened to the supposed armageddon like the one predicted by the technology blog pundits when Stagefright was revealed? The fact is that not 1 Stagefright exploit has ever been seen in the wild by Google's SafetyNet telemetry system. And even if an exploit does manage to bypass the Android security mitigations in place the diversity of the ecosystem makes it so that an exploit for one device isn't going to work on a device from another OEM.

The real source of all of these IoT attacks are linux based IoT devices that have been compromised by users not changing the default login credentials or attackers using one the many Linux exploits available. And I won't even get into the never ending damage inflicted by Windows. That's what you should really be worried about.

Here's a video of how Google plans to secure their Android Things IoT devices. If another company has a better plan than what they presented at I/O 2017, short of unplugging it from the Internet, then I'm not aware of it.

https://www.youtube.com/watch?v=U4QBI4PJj8Y

If you compare to the Linux ecosystem, you can see why IoT upgrades are broken. In the Linux ecosystem, software releases are typically independent from packaging, as well as from package managers and their update configurations, allowing users the freedom of being somewhere on the spectrum from completely unstable rolling release distributions to highly stable releases like Debian Stable. Software which auto-updates itself, instead of relying on the package manager to update it, is widely considered to be an anti-pattern.

IoT needs a packaging ecosystem to protect the freedom of its users, instead of allowing IoT devices to independently connect upstream to the manufacturer to get updates. Of course, auto-updates should be the default, because most users won't pay attention, but the user's freedom should be protected and preserved.