Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
5/30/2017
10:00 AM
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

Securing IoT Devices Requires a Change in Thinking

There's no magic bullet for IoT security, but there are ways to help detect and mitigate problems.

Predicting an Internet of Things (IoT) disaster is a bit like expecting a tragic ending in Titanic. We've seen this movie before, and we know how it ended the last time.

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.

A Few Approaches to Mitigate IoT Security Issues
The security vulnerabilities that the industry has worked to eliminate from the desktop and server have been reinvented at the application layer. And now they are being recreated in the world of IoT. There is no magic bullet for IoT security, but there are approaches that can help detect and mitigate problems.

  • Least privilege: The less a machine, a process, or a user is allowed to do, the less opportunity it has to cause damage. Compartmentalizing IoT devices and sandboxing code allows attack surfaces to be managed if not exactly minimized.
  • Least complexity: The more complex a software system is, the harder it is to test, and the more likely it is that it will go wrong. Industrial control systems are based on the model of simple devices connected to a hub where the complexity is confined.
  • Audit: Another powerful tool is audit. An antisocial habit of many IoT devices is unexpected and often undisclosed attempts to communicate with the outside world. This presents a dilemma for companies with products that include application firewall services. Is that video-conference camera trying to contact an outside Web server because it's supposed to or because it has been compromised? Even if the device thinks it's supposed to, should it be allowed?

Of course, the wise and security conscious chief information security officer might declare a moratorium on IoT devices until the industry sorts itself out and starts delivering a predictably reliable and secure product. But as with bring-your-own-device policies, Wi-Fi, and Internet connectivity itself, productivity will almost always triumph over security.

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. A typical developer may remove his or her development tools and personal accounts from the system before it ships, but this doesn't always happen.

Two things are required if IoT security is to improve:

  • A metric that allows purchasers of IoT devices to estimate the likely attack surface it presents must be developed.
  • Manufacturers must believe that the metric matters to their customers when they make purchasing decisions.

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.

Related Content:

 

Dr. Phillip Hallam-Baker is VP and principal scientist at Comodo, a global cybersecurity firm. Dr. Hallam-Baker has approximately 25 years of experience in Web security, with 12 years spent as principal scientist at VeriSign. He has worked on Web security since 1992, when he ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
How Attackers Infiltrate the Supply Chain & What to Do About It
Shay Nahari, Head of Red-Team Services at CyberArk,  7/16/2019
US Mayors Commit to Just Saying No to Ransomware
Robert Lemos, Contributing Writer,  7/16/2019
The Problem with Proprietary Testing: NSS Labs vs. CrowdStrike
Brian Monkman, Executive Director at NetSecOPEN,  7/19/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-12551
PUBLISHED: 2019-07-22
In SweetScape 010 Editor 9.0.1, improper validation of arguments in the internal implementation of the Memcpy function (provided by the scripting engine) allows an attacker to overwrite arbitrary memory, which could lead to code execution.
CVE-2019-12552
PUBLISHED: 2019-07-22
In SweetScape 010 Editor 9.0.1, an integer overflow during the initialization of variables could allow an attacker to cause a denial of service.
CVE-2019-3414
PUBLISHED: 2019-07-22
All versions up to V1.19.20.02 of ZTE OTCP product are impacted by XSS vulnerability. Due to XSS, when an attacker invokes the security management to obtain the resources of the specified operation code owned by a user, the malicious script code could be transmitted in the parameter. If the front en...
CVE-2019-10102
PUBLISHED: 2019-07-22
tcpdump.org tcpdump 4.9.2 is affected by: CWE-126: Buffer Over-read. The impact is: May expose Saved Frame Pointer, Return Address etc. on stack. The component is: line 234: "ND_PRINT((ndo, "%s", buf));", in function named "print_prefix", in "print-hncp.c". Th...
CVE-2019-10102
PUBLISHED: 2019-07-22
aubio 0.4.8 and earlier is affected by: null pointer. The impact is: crash. The component is: filterbank. The attack vector is: pass invalid arguments to new_aubio_filterbank. The fixed version is: after commit eda95c9c22b4f0b466ae94c4708765eaae6e709e.