We've been hearing a lot about IoT security recently. The news is overwhelming us with stories about baby dolls and baby monitors that can listen in on conversations at home, not to mention surveillance cameras that provide video streams to unauthorized individuals. To better understand these events, let’s start by looking at what is IoT. According to Gartner, "IoT is the network of physical objects that contain embedded technology to communicate and sense or interact with their internal states or the external environment." Now, you can say, "well, that’s the same as a PC." However, the definition of IoT goes further. These devices have a single purpose and in many cases do not have a human interface like a PC, such as a keyboard and a screen, that help control the device.
The IoT device
An important aspect of an IoT device is that the device is controlled remotely via the network. So besides that, IoT devices collect and provide data over the Internet just as they are configured and controlled over the Internet. There are many examples of IoT devices. These include home thermostats, tracking devices for cars or pets, electronic door locks, remote-controlled lighting, home automation, etc. Let's not forget about the devices for industrial control systems, such as remote sensors, controllers, PLCs, and even robots. Are these IoT devices? Well, if they are directly or indirectly connected to the Internet, you could consider these devices as part of the IoT realm. To understand the threats to IoT and IoT devices, let's start with the device itself. An IoT device is commonly built upon a microcontroller and has dedicated software (firmware) that provides application logic. The firmware is very specific and customized for each of those devices, which is why we sometimes refer to those devices as embedded appliances. We all know that within normal IT, a PC/server might be vulnerable. If it is, an attacker could exploit it to navigate deeper into the enterprise network and potentially steal data from it. With the embedded devices that do not have an OS and or file system, the likelihood that the code will be compromised is lower than with common computers carrying an OS that can have many known vulnerabilities. But if someone has physical access to an embedded device, then there is a possibility to flash the device with altered code. Nevertheless, you could say that an embedded device is better-protected than a common PC or server.
Communication
As we stated above, an IoT device is a device that can communicate directly or indirectly with the Internet. The fact that an IoT device maintains communication over a public network is indeed a concern. You see, the most common way for controlling an IoT device and collecting data is using the pub-sub protocol (i.e. MQTT, AMQP, STOMP) against a message broker. The great advantage of a pub/sub protocol is that the IoT device is communicating to the broker to send data (publish a message with a particular topic) and to receive selective data (receiving a message by subscribing to particular topic). The communication is unidirectional to the broker. This makes it possible to put IoT devices behind firewalls and has the benefit of not requiring a fixed IP address. To control an IoT device, an application or other device can publish a message to the broker intended for a single or group of devices. Let’s explain this with a real-world example of a remote home thermostat.
The thermostat is connected to a broker on the Internet and will communicate with a broker. As the owner of the house, you can control your thermostat with your mobile phone. Your thermostat is paired with your mobile phone by the ID of your thermostat. Using the app on your phone, you can read and set the temperature in your home via the broker. To set the temperature, the app publishes a message with the requested temperature to the broker. Your thermostat will receive this message as it is published specifically for your thermostat. The thermostat is publishing the actual temperature to the broker, and the app on your mobile phone will receive the temperature as it is subscribed for messages published from your thermostat.
Now, imagine that I can pretend with my phone or any PC that I’m the one your thermostat should listen for and that I’m able to publish false data to the broker in a way that it looks that it comes from your thermostat. This is a relatively harmless threat, but what about the thousands of cars that have a device that can control them? More and more car manufacturers produce cars that are connected as soon as they leave the factory. And what about all the elevators that are connected? And smart TV’s and devices that control critical infrastructures? I think you get the picture here. If we look at the security of IoT, the first thing we need to look at is how communications are secured. You would at least expect that the communication is encrypted and use certificates for mutual authentication, as it is obvious that with unencrypted communications the device is vulnerable to a man-in-the-middle (MitM) attack. However, the reality is that many IoT devices are still lacking encryption and are using a username and password to communicate to a broker. Especially with small, low-power, low-memory microcontrollers. SSL or TLS is commonly not used because of the overhead of encryption, which includes the size of the required additional library and the CPU power required. Nowadays with fast and small TLS libraries and the lower costs of more powerful microcontrollers, it is unthinkable to not use encryption and certificate authentication. But the problem remains with all the devices in the field that are still not up-to-date. They probably will never be, as there are no means to update them easily.
Backend
As stated before, an IoT device needs to communicate with a backend in order to forward data and (if applicable) to receive data for controlling the device. There are many ways to provision what we call a broker or backend. Many software solutions are available to set up a broker, and we see more and more cloud services from Azure, Amazon, Google and dedicated IoT platform providers. As with critical websites, availability is a challenge, i.e. IoT devices that control critical infrastructure, such as sewer systems, need to be able to connect to the backend in all cases. Therefore, clustering and load balancing are imported technologies that need to be applied when setting up a broker. When developing an IoT solution, the question will be to build the backend yourself or to buy it from one of the many providers. When buying a backend, you can benefit from the high availability and the security that is already in place along with the ease of a managed service. When building your own backend, there are many security technologies involved. Besides the broker software, you need to at least provide encrypted channels, secure provisioning of IoT devices, create appropriate authentication and authorization mechanism, and protect against DoS (Denial of Service) attacks.
(Big) Data
Many IoT applications are built to collect lots of data. As the capabilities are there to continuously collect data from anywhere at any time, the analysis of that data is, in many cases, the main purpose of an IoT application. It is already mentioned that communications need to be secured/encrypted to prevent MitM attacks, but it's also important to protect private data. So, is the protection of the data different than with any other Internet application? The difference might be the technology used. We see more and more alternative ways to store the acquired IoT data like the use of NoSQL databases, such as Elasticsearch, Influx and many hosted/cloud alternatives. In comparison with relational databases that have been around for decades, the new type of databases do not have extensive security best practices based on what happened, and what we know as traditional relational databases and skills are scarce.
Does IoT require a different approach than an Internet application if it comes to security?
Probably not. But the challenge might be different in terms of the number of IoT devices that need to be controlled and secured. Throughout the development of an IoT solution, security should be a fundamental part. Security best practices should be applied to every layer of the solution: the IoT device, backend, database and control software, and human interface. Foundational controls can help in this regard, as IoT security need not be entirely different from security around normal IT or a web application. To learn how Tripwire can help your organization secure their IoT devices using foundational controls, click here. Also, you can join me and the Tripwire team on November 7 at Nordic IT Security. During the event, I will be hosting a roundtable discussion titled, “Cyber Security in the Connected World” from 11:30-12:30.
