Securing IoT Devices Requires a Change in Thinking

#Discussion(Security) [ via IoTForIndiaGroup ]

Today, 99% of the code complexity of most IoT devices comes from the operating system core it’s built around.

Rather than build software for IoT devices as an application running on a desktop operating system, we need to start from something much smaller. Instead of taking something very complex and asking what can be removed, we should start with something as simple as possible and add the bare minimum.

[The base case for LF Edge: Building an Open Source Framework for the Edge
Watch the IoT OpenSource day coming on Dec 7 2019 ]

To understand how big the IoT security problem is, you need to go back to the 1970s when what is now called the Modbus communications protocol was introduced and utilized in industrial control systems. That same protocol is still in use today, and the code running in many of the control devices has remained unchanged. Any device connected to a Modbus chain has full control over every device in that chain. How can you call a security model weak when it is nonexistent?
At one IoT security meeting I attended recently, a speaker stressed the need to get the ability to update IoT firmware firmly established as a core security principle. However, why would manufacturers see the point in that when they haven’t updated their code in the last 30 years?
The process control world sticks to the past because the alternatives tend to be worse. When I worked in the chemical industry, the two paramount concerns were safety and keeping the plant running. These were often the same concern. A machine that might suddenly take itself offline for 10 minutes as it installed what the manufacturer considered to be an “important security update” might well take the whole plant offline for a day or more. If a furnace tripped, it might well turn a valuable process intermediary into an expensive dispose of industrial waste.

What Is the Way Forward?
For the present, and for many years to come, detection and mitigation will remain essential, but they are costly. The more attack surfaces a device has, the more expensive it is to manage. Operating systems such as Windows and Linux offer a large attack surface to the opposition because their function is to be as flexible as possible. As a result, even the Linux kernel contains 15.9 million lines of code (v3.6). Almost all of it is written in C or C++ and, thus, is vulnerable to buffer overrun attacks.
We are currently at the point of maximum IoT vulnerability. Five years ago, most embedded systems controllers were built around 8- or 16-bit CPUs, which rarely offered more than a few thousand bytes of RAM. Systems had to be simple, as programmers were forced to make every byte count. Today, a 32-bit CPU with a couple of gigabytes of memory costs only a few pennies more. The cheapest, fastest way to get an IoT device to market is to drop a full Linux distribution onto the chip and use it as the development system.

Read More..