Table of Contents
The Eight Principles
Silicon Labs wrote a document and blog post about how companies should design Internet of Things (IoT) devices. Each of the principles implies some effects on the consumer side. This document, which may be updated in the future, explores some of these effects.
Principle 1 – No Universal Passwords
Don’t set the default password to the same word on all devices.
For consumers: make sure the default password is changed.
Principle 2 – Secured Interfaces
Admin and other interfaces need to use some kind of encryption and/or other security measures.
For consumers: if the interface isn’t secured, like the web interface uses http instead of https, or the command line interface uses telnet instead of ssh… consider replacing the device. If security is an option, then bookmark the secured interfaces in your apps, so you don’t resort to using the unsecured connection.
Principle 3 – Proven Cryptography
Favor using open technology over proprietary.
Consumers: I’m wondering if this is a swipe at RSA or PPTP. Personally, I haven’t had that many mishaps using proprietary cryptography. Mainly, you need to get onto the announcement list for the product.
Principle 4 – Security by Default
Devices should be using maximum security out of box.
For consumers: you have to read up about the device’s security, and turn on the features you need to get more secured.
Principle 5 – Signed Software Updates
All update files should be signed.
For consumers: a lot of them are signed, but aren’t checked, because the admin downloads the update, and then runs it. So, favor companies that have an automatic update feature that will check the signatures.
Principle 6 – Software Updates Applied Automatically
A daemon should check for updates, and run the updates when the system isn’t busy.
For consumers: favor companies that have automatic update features in their products.
Principle 7 – Vulnerability Reporting Scheme
The manufacturer should have a way to submit error logs.
For consumers: good luck. I’m not sure many companies have this. They may accept reports by email.
Principle 8 – Security Expiration Date
The manufacturer should tell you when security expires.
For consumers: this is problem. The ones with the clearest expirations also want you to pay a licensing fee each year to get updates! Open source based systems might have some hope of getting updates after the company stops producing them. These are not going to be cheap.
My Tricks
I pretty much dislike IoT, and have done a few things to avoid headaches.
Don’t Buy It
The stuff goes obsolete real quick, and costs a lot. Use a fakey version rigged with an old laptop for a few months to see how it works. For example, I got a pretty lame security camera, and made a “recorder” from an old PC. I wrote code to knit the images into a video. Then, I tried it for a couple weeks. I found that I didn’t take the time to watch videos.
I concluded that if I got a good security camera, I wouldn’t watch the videos. I’d need a baseline video recorder setup that could record the last week or two, and write over old videos. I’d get something integrated and test if it crashed. That’s the plan, but I haven’t bothered to implement it.
Network Segmentation
If you’re really into security, you can use switches and multiple access points to create virtual LANs. See: Netgear GS108T VLANs.
Put all the IoT devices into their own VLAN. If one gets compromised, you can protect your laptop and phone devices by putting them in a different VLAN.
WiFi Router’s Node Isolation Features
Most home routers have a feature to isolate traffic on the wireless LAN so that devices cannot communicate with each other. Turn this feature on.
This doesn’t extend to Ethernet, but most IoT devices don’t use Ethernet.
Turn it Off
It’s just more stuff that sucks up power. Unless it’s doing something important, like making backups, or is a security camera, why run it?
Document It
Keep all the manuals in a box in the bookshelf or in your filing system. You can also download PDFs of the manuals.
Write a document that describes the network in detail. Documentation is a mental exercise that helps you develop a “bird’s eye view” of the network. You may spot vulnerabilities.
Label Your Wires
Put labels onto your wires and power cubes. It makes it easier to find the right cube to unplug, and also the right cube for each device once it’s packed away. I use regular tape, and bits of paper with the names written on them. You can buy special labels for numbering wires – these are useful for knowing which ethernet cable is connected to what device.
More Tips That You Probably Shouldn’t Bother Implementing
These are things I’ve done before, that are probably a waste of time.
Reduce Wifi Power
This is a tricky one, and I don’t do it that often, but you can get some Android apps that measure your WiFi strength. You want your signal to be strong inside, but weak outside. One way to achieve this is to reduce the Wifi power in the device’s settings.
Another way is to get some stuff called “landscape fabric”. It looks like chicken wire. It acts like a shield against radio waves. You can use it to create reflectors.
Alternatively, you can just put some metal object on one side of the antenna, and there’s your reflector. It weakens the signal on one side, and strengthens it on the other side.
Overall, this is not that useful, but it feels kind of “spy vs. spy”, and helps you avoid “war driving”.
Static IP Addresses for Devices
I used to be a real stickler for this – a hand-allocated local area network, with special names for all the devices, and fixed IP addresses.
I kept the IP addresses in a spreadsheet.
I’d definitely still do this for an office LAN, but I wouldn’t bother to do this for a home network anymore, except for my printers and any “servers” that ran a Linux variant with SSH turned on.
Most consumer devices use an application to configure the device. The application finds the device on the network, and some apps can bypass the IP address and find the device with a MAC address.