IOT Developer Security Checklist
simplesecurity.sensedeep.com
simplesecurity.sensedeep.com
I find this practice absolutely infuriating, and it's a big reason why I abhor the current IoT ecosystem. Sometimes I get busy and don't have time to read a changelog, and I don't want to have to do this on someone else's schedule.
There seems to be no technical way to allow manufacturers to provide transparent security updates without also allowing them to pull the rug out from under you when you least expect it. I think we need some sort of social contract for this, but unfortunately my view seems to be a minority one, given the amount of bullshit that the public seems to tolerate from self-updating devices and apps.
Some patches should be able to be made "hot", but that takes extra ram which is often squeezed to a premium in a device.
I would recommend:
- We not put devices on the internet that do not have a core, hard requirement to be on the internet. This rules out toothbrushes, toilets, pillows etc.
- Devices do not open listening ports and only connect out. This eliminates a whole class of shodan visible attacks.
- Devices give users some option of when an update is required and when the user can apply it. If the device can be managed via a HomeKit or Phone UI - these options can be made pretty usable. Alternatively a yellow light on the front of the device if suitable to indicate an update is available.
Regardless, the current path of listening devices on the internet and not being patched is untenable.
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.
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.
Maybe a good legal solution would be to allow automatic updates, but only if user is informed about changes and she can downgrade/revert at any time. Also, the stuff that Microsoft does with Win 8/10 upgrading should be punishable.
I think Android things is built around this idea, with manufacturers having no control on security updates.
For simple, standalone features, this could work well. But when your features are dependent on interacting in some way with other people's connected products, this might not work.
One solution to this problem is to institute consumer protection laws that say that consumers can return the product for a full refund if an exploitable security flaw is discovered in the device, and that products must disclose the privacy implications of using them.
Another option is to improve the software ecosystem for IoT to the point where everything is secure-by-default and you have to go out of your way to do something in an insecure manner. That will require a lot of careful API design and probably abandoning C and C++ in favor of something safer. (Rust seems like the most promising alternative at the moment.)
A useful test of whether or not we've succeeded is whether a hobbyist with basic programming knowledge can, with low effort, deploy a custom embedded device that connects to the Internet and have high confidence that it isn't a privacy threat or vulnerable to known security attacks and it will continue to be secure for the life of the product.
I think the full solution has got to be some mix of consumer protection laws and better tools for deploying secure devices. Maybe also some third-party validation organization could get involved, analogous to UL listing for electrical things.
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.
- does this really need to be online?
- really?
1. Does the zipper on the fly of
your pants need to be automated?
2. Does the zipper on the fly of
your pants ever need costly repairs?
3. Does the zipper on the fly of
your pants need regular maintenance?
4. Does the zipper on the fly of
your pants expend disposable accessories?
5. Does the zipper on the fly of
your pants need to be context aware?
6. Does the zipper on the fly of
your pants require internet connectivity?
7. Should the zipper on the fly of
your pants be controllable via cell phone app?
8. Should the zipper on the fly of
your pants monetize potential advertising space?
9. Should the zipper on the fly of
your pants collect behavioral analytics?
10. Should the zipper on the fly of
your pants enforce DRM policies?
Let's use the fridge as an example:
1,5) I don't need it to be automated, but I would love to get notification when food's about to go bad or when we are out of milk. Temperature is already automated, but we could squeeze out more efficiency if it was context aware and more intelligent (it could keep some compartments on higher temperature than others).
2,3) Appliances sometimes need maintenance anyway, but preventive maintenance would be less costly.
7) Phone apps are terrible way to control anything, to me they are just a stop-gap solution until something better comes (reliable voice control for start, then AR interfaces).
8) This would lower the cost and allow poorer households to own one; I don't mind advertising if full price gets rid of them. Kindle is great example.
9) YES! But for my benefit, and not for benefit of manufacturer and third parties. My fridge could recommend new interesting meals based on my cooking. It could also warn me about unhealthy habits and help with my diet. Over the years it could improve my quality of life without significant effort from my side.
10) No. DRM should not exist.
IOT will get much worse before it gets better. I say this from working with device builders for 2 decades. The level of attention to security is sadly lacking.
There's an old saying that "if you aren't paying for the product, you are the product". That saying might need to be updated to reflect modern times, that "if you aren't paying for the product and maybe even if you are, you are the product".
There may also be some manufacturers who put stuff on the Internet not as a deliberate effort to monetize their customer's lack of privacy, but simply because they've bought into the marketing of other device makers and are convinced that some of the features they can enable by being always connected will make their product more desirable.
In doing IOT for 2 decades, this is probably one of the biggest issues. At best, most devices have a "download firmware" option that 99% of users can't operate.
I could go on about dozens of other issues, like back-door field-service passwords, http not https, passwords in the clear, endless XSS vulnerabilities, but this is one of the biggest.
You have to resort to different fudges on different browser.
Net/Net: the http auth ui sucks, has bad usability, weak crypto, and is not robust with logout.
HTML/form based auth can be made robust and is a preferable alternative in every case.
Another problem is that during the lifespan of product, several critical exploits could be found that would compromise the security if not patched. There already efforts to defeat SSL and we may need to upgrade to more advanced protocol in near future.
One last problem is that in your case the device needs to have server address hardcoded. The company could go out of business and you would have no way to redirect it to alternate unofficial server. Therefore, firmware upgrades are pretty nice to have in IoT.
If the device does not listen, and polls regularly for updates, then that is fine ... perhaps even ideal.
IOT devices today look pretty much like any other internet device too. Linux, good CPU horsepower, ample memory and internet connection. More than a few exploits that work on enterprise servers can be adapted for IOT devices.
Add to this a lack of awareness of basic security issues among device builders and you've got a problem. That is why we are seeing so many security issues with IOT devices.
I'd hate to think users were just as guilty, after all that would implicate me, but much of the IOT functionality should be firewalled or restricted to LAN, if access via handheld is the target rather than turning the stove on while on vacation. Regarding manufacturers from the POV of a consumer, they should just build devices without malfunctions. That's not a matter of security but quality.
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.
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.
Fifty extremely experienced security engineers can come up with a pretty good IOT security infrastructure in six months.
But should EVERY company have to reinvent that wheel, somehow finding 50 extremely experienced security engineers, and making them do that?
What would work better is if the fifty extremely experienced security engineers did it once, in a way everyone can use.
I must say I do trust Google to autoupdate my Chrome (haha, as though I had a choice), and they can do anything on my computer that they want. It's not a big stretch to let them autoupdate my lightbulbs, toaster, fridge, anything else.
I think Google should get on the ball and centralize IOT security. (Uh, no, not by putting android on everything.) It would be a pretty natural fit for them and not that big of a burden.
I mean what are these small companies supposed to do? There is a natural market opening.