IoT Security, The Bad News

A friend and colleague complains each time I post optimistically about the Internet of Things because, rightly so, he is very concerned about the lack of good security practices used by developers in the field.

His concern is quite valid. We’ve all heard about the taking over of the Jeep Cherokee through the vehicle entertainment system, activating a heart pacemaker’s cardioverter-defibrillator through the remote terminal, or using baby monitors to invade privacy.

Fortunately, all three of these cases were found by people studying IoT devices for vulnerabilities. Unfortunately, they found them and there are most likely many more out there ripe for exploiting.

Let’s place the blame where it lies: at the feet of the software engineers who design and build the systems without complete considering the security and safety aspects of the end-to-end integrated system. We can no longer rely on the old 4+1 architecture views. Today, we need to supplement those with a security view used to assess the communications paths and how to keep them secure.

For those building systems, review the vulnerabilities identified by the Open Web Application Security Project (OWASP) to start your assessments.

Sample rates and the Internet of Things

In college, most engineers learn about the Nyquist-Shannon sampling theorem. Basically, it says that capturing an analog signal in the digital world requires samples to be frequent enough to capture the changes in that analog signal. Most remember the theorem says the minimum sample rate is twice the signal’s frequency.  Some will recall the in class demonstration offered as a warning – if sine wave signal is sampled at twice the frequency, exactly at the zero cross point, the digital representation is a constant. Epic fail.

Internet of Things (IOT) developers need to be aware of Nyquist because they need to ensure that they schedule sampling frequently enough to capture signals in real time (that is, fast enough to sense a change and react to it, see my discussion of real time), but not so fast as to use all the bandwidth or to miss a signal toggle. They also need to be aware of the non-deterministic nature of the network; Internet packets do not arrive on schedule and may arrive out of sequence.

So what’s a poor IoT developer to do? First, realize that the internet is great for monitoring, but may not be appropriate for control.  Second, realize that not just any <fill in the name of your favorite language> developer is qualified to do IoT development.  Working in the real time embedded software field requires special training and experience. Third, and perhaps most important, there are plenty of us out here who have been through it before. Most are willing to help if you ask.

Internet of Things is more than One Thing

Technology and buzzwords go together like your favorite hackneyed expression.  Technology is dynamic, diverse, and complicated. Even the most technically competent have expertise in just a few areas.  Most people only learn the very basics and the buzzwords.

Such is the case with the Internet of Things (IoT).  We all understand the basic IoT concept that all kinds of devices communicate over the Internet, not just computers.  We understand that IoT enabled devices send data to other applications, and in some instances, the applications send commands and data to the devices.  That is as far as most people go.

This limited understanding of IoT can lead to some very dangerous situations.    Very simply put, if IoT devices receive commands from the application, software engineers must design the system following good real time embedded control system design and development practices.  People unfamiliar with real time embedded control systems can inadvertently create conditions that can damage equipment and hurt people.

In this series of articles, you will learn some different uses for the Internet of Things.  It covers three main use cases:

• Data collected from sensors/devices and processed by the server application (unidirectional messaging)
• Data collected from sensors and preprocessed by devices before sending it to the server application (unidirectional messaging)
• Devices controlling local machines send messages to the server application for overall command and control (bidirectional messaging)

You will see that the IoT architecture you choose differs based on the purpose of the installation.