A nine-point blueprint for better Internet of Things security
A nine-point blueprint for better Internet of Things security

Sadly there are a number of common, yet fundamental, security flaws that we see time and time again in IoT devices. These flaws, which are leaving many IoT devices wide-open to botnets, hackers and cyberattacks, pose a genuine threat to the IoT's future.

Common vulnerabilities include

  • Hard-coded passwords – Devices shipping with no password or a standard ‘admin' password that can be easily discovered and exploited.
  • Fundamentally weak security at both the software and hardware levels – Beyond the password many products are not designed with security best-practice in mind.
  • Lack of software updates – When a security exploit is discovered, updates are not always rolled out in a timely fashion. Sometimes they are not rolled out at all.
  • The scale of the opportunity – The billions of vulnerable IoT devices on the market represents an unprecedented attack vector.

A recent survey into the security habits of 2,000 UK consumers highlighted a dangerous level of consumer ignorance regarding the security precautions required to keep their IoT devices safe. Just 31 percent keep their connected devices up-to-date with the latest firmware. Nearly one in ten (eight percent) don't even know what firmware is and 47 percent don't realise their router is a connected device.

It's clear that the IoT industry needs to step up, take charge and not place the burden of security at the consumer's doors. Having closely analysed the IoT's security vulnerabilities and the failings of existing approaches I believe this nine-point blueprint will help to address the IoT's security issues for good:

1. Start at the level of the device itself

The first assumption to make when securing the IoT is that devices will be deployed in an insecure environment.

There are many points at which better security IoT security can be implemented (including, for example, at the level of the network provider). However, even networks can be bypassed (for example by a physical hack).

Ultimately IoT devices themselves must be acknowledged as the most critical point at which security should be considered, and the best route to leverage a consistent approach to device security, we believe, is through the device's OS.

2. Design the OS from the ground up for security

When security is treated as an afterthought, patching vulnerabilities becomes a never-ending battle; no sooner is one addressed, than another appears. Traditional approaches to OS design simply present too many opportunities for incursion. A radical rethink of OS architecture that regards security as the Alpha and Omega is needed.

3. Simplicity with functionality

Any IoT OS needs to be streamlined. IoT devices often have little budget in terms of CPU cycles, memory, and storage. But lowering size and increasing simplicity is about much more than getting an OS to fit/run on a device; it's also a philosophy that helps to make an OS more secure. The less complexity, the fewer points of vulnerability.

4. A centralised update mechanism

The ability to update software reliably and automatically must be central to any secure IoT OS. This is particularly true when many IoT devices will be connected and then forgotten about, or will become physically hard to access, with no UI through which to update them. By ensuring the timely delivery of authenticated updates, and providing a mechanism that helps to shield users from the negative consequences of poor applications or vendor failure, some of the biggest security issues faced by the IoT can be mitigated.

5. Automatic rollback of updates

Should a security update fail, devices need to be able to automatically roll back to the last known working configuration, thus maximising the chances that devices remain not only secure, but also functional.

6. Default ‘read only' files

If OS files are read-only and digitally signed there is a far greater opportunity to examine the integrity of each file before installation and guarantee this integrity over time. The result is a system that can be secured from startup to shutdown.

7. Self-contained and sandboxed applications

Segregating applications in their own restrictive sandboxes, by default, minimises the damage that can be done by malevolent or malfunctioning applications. By default it is thus impossible for one application to access data from another.

An extension of this idea is the ‘guilty until proven innocent' principle. A truly secure IoT OS should have all ‘allowable' behaviours and connections of each OS element and app predefined. Any behaviour stepping outside of this remit will immediately be prevented by default.

8. Familiar and common platform

The more proprietary OS variants there are in the market the more potential methods for exploitation, and the harder these exploitation methods will be to track and address. Development within a known framework and ecosystem like Linux, and according to known techniques, ensures the talents of large, pre-existing coding communities can be leveraged so, security issues can likely be addressed more quickly.

9. Security should not restrict the IoT innovation

Security measures should not involve a ‘walled garden' approach. Remaining Open Source is key to fostering the spirit of innovation at the heart of the IoT.

These nine principles are at the heart of Ubuntu Core – a fully-secured OS suitable to a wide range of IoT applications from robotics, digital signage to drones and home gateways.

Until now too many of the other solutions proposed for IoT security today involve either mitigating security issues after-the-fact, or living in a world where IoT security problems are the accepted norm. This cannot be the case!

Contributed by Thibaut Rouffineau, Head of Devices Marketing - IOT, Phone, PC at Canonical Ltd / Ubuntu

This article is a broad summary of Canonical's whitepaper — Taking charge of the IoT's security vulnerabilities — available to downloaded from here https://pages.ubuntu.com/ioTwhitepapersignup.html?cp=close

*Note: The views expressed in this blog are those of the author and do not necessarily reflect the views of SC Media or Haymarket Media.