Jeff's Rules for Simple IoT Security

Because of the sensitivity of this post, let me reiterate – the opinions I post here are strictly my own. They do not necessarily represent those of my past, present, or future employers. Also, my opinions can and will change based on new evidence.

One of the things I’ve learned from studying Big Data and social media is that people are most likely to read these posts on Monday morning. I wrote this last night, but waited so that you are more likely to read it. Thanks for reading.

On Sunday, I posted that a key impediment to IoT being a supply of cheap, long lasting, portable power supplies. Several friends responded that the main impediment is security. Yes, security is extremely important and needs to be architected and designed into every IoT system, however, I posted my frustration trying to power an array of sensors that I want to mount at various remote locations around my home. The sensors themselves are cheap; the most expensive is less than $20. My plan was to perform control, edge analytics, and network communications via an inexpensive controller such as the Raspberry Pi Zero. Can’t be done with the current battery technology and I’m not about rip up my ceiling or run electricity where I’m trying to detect leaking water.

But since IoT security was such a hot topic yesterday, let’s talk about it. I have a few rules I follow for my projects that makes systems much safer. Notice I said “safer” not “safe.” If someone really wants to hack in, she will find a way. My goal is to make it more difficult and to limit the effects of a hack. Also notice that I say my projects. Some of these are more difficult on complex systems, which is why we need to demand that companies hire people trained and qualified to build safe systems. More on this point in a different posting.

Rule 1: Move along. Nothing to steal here

When asked why he robbed banks, Willies Sutton supposedly said because that’s where the money is (BTW: he probably did not say that). My first rule is that I keep things that people want off the IoT network. I don’t use the same network – or computers on it – for important or private information.

Rule 2: Back to the future. Rigidly defined interfaces

Some years ago, I worked on a project where we defined a generic message. It sounded like a great idea because once the communications code is written, one only needs to add a new message handler (and perhaps a parser) to extend the machine’s interface. This approach sounds creatively brilliant until one realizes that a malicious actor can easily take control of the machine (especially since the configuration and message handler code was writing in Python).

I define my APIs specifically and rigidly. I’ve given up some flexibility for increased safety. I also include state machine logic to reject commands that are inappropriate for the current state of the system. (For example – and this is not a real example – if the outside temperature below a certain temperature, the heater will not turn off.)

Rule 3: One-way communication

In the real time machine controls world, we don’t start a machine that we can’t physically see and touch. People can get hurt. I follow a similar rule for IoT. Most things connected (or anticipate connecting) to my IoT network are passive; they send data to my IoT controller, but commands do not go to them that can result in an unsafe condition. I can’t unlock my door from my cell phone, but then again, neither can you.

Rule 4: AD428B3E0F982459423 (Encryption)

Encryption is easy, especially when you control both ends of the communications, there is only one tenant, and there are a limited number of devices. Even the simplest techniques make decrypting the message difficult. Yes, if the NSA or a sophisticated bad actor wants in, it will be easy to decrypt. But see Rule 1. No one really cares about the temperature of my swimming pool but me (again, an example, not the real thing).

That's it, Four simple things I do. Do you have any other suggestions?