Very good article. One thing that I would add, though, is the need to particularly lock down video feeds. This is an item that many people add to increase security but neglect to adequately lock down. Not only does that make it handy for an intruder to surveil the premises, but it can also provide a convenient open window. Peeping toms no longer have to hide in the bushes outside of a physical window.
I recently upgraded my home router, and I was impressed by how locked down the new one was by default. They randomized the SSID, closed down any inbound connections by default, turned off ping response, provided a unique default password, and a number of other enhancements. It is still quite possible to override these settings, but a user that doesn't do that will be much safer by default with new equipment like this.
Thanks for the wonderful recommendations and suggestions. It is not the IoT that is the problem. The weakest link in Information security is people. As long as the average person do not know the meaning of "outbound"; or how about "HTTPS and SSL"; and what about "backdoor." Come on...Once again, wonderful suggestions.
Your home network gateway plays an important role to the security of your home network as well. Typically, my gateway doesn't listen to any port in the extenal network. If it does, I only allow connection from a specific IP address, e.g. my office gateway address. 5 tips in this article are very good. I am sure there will be more tips and in some IoT application, some tips may be found difficult to apply. Nonetheless, this article is a good starting point to develop a complete list. Security is no doubt the main concern in IoT. The sooner the list is nailed down, the better security we will earn.
If you're referring to most routers in public or in your homes, this shouldn't really be an issue. IoT devices should work just like a PC, phone, tablet etc. It should ask for an IP via dhcp just like everything else.
SSL and the related protocols are definitely a pain in the rear ... a comment that applies to security generally :)
However, at least for Wi-Fi-based products, the computational overhead of SSL is basically something you're paying for already. For instance, if your silicon is capable of joining a WPA2 network, it's capable of AES encryption. We are seeing components from several major vendors targeted at exactly this application, and they've normally got SSL, HTTPS, and so on built in at relatively decent prices, at least in volume.
If instead you are talking about Zigbee and the other 802.15.4 protocols, then yes, those chips don't normally offer SSL support (at least as far as I'm aware). But in this case, you're typically not talking about using IP on the device; instead, the gateway between 802.15.4 and IP would translate between the non-IP protocol and the IP backhaul to the cloud, and that's the point at which you'd apply SSL. (As I said in another comment, though, I'd want to think hard about the security of this configuration more generally. I'm not sure I'd trust, for instance, a Zigbee-based lock on my front door.)
Regarding the role of the gateway between the IP-based network and the 802.15.4 protocols (of which Zigbee is but one example) -- there are a whole host of issues here and probably deserving of an entire blog post. (To address Bert's comment: This configuration is common because of the very low power requirements of 802.15.4. Unfortunately, typically the IP communcations are terminated at the gateway instead of being carried all the way to the device.) Specifically regarding the security of this configuration, I think there are likely to be vulnerabilities there, at least if you assume that attackers can get reasonably close to your 802.15.4 network. Definitely something to worry about.
Regarding how you engineer things to statisfy my "outbound connections only" rule, I have another blog post addressing that: http://www.cardinalpeak.com/blog/?p=1791
My Mom the Radio Star Max MaxfieldPost a comment I've said it before and I'll say it again -- it's a funny old world when you come to think about it. Last Friday lunchtime, for example, I received an email from Tim Levell, the editor for ...
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...