Another post in the series on “IoT Device Security Considerations and Security Layers“, this time looking at Operating Systems.

There are many Operating Systems available for use on IoT devices and there are more being developed all the time. These range from specific Operating Systems targeted at a specific IoT Chip set to ones that can be used across a number of devices. Some of the names in this field are well known by every day consumers and some not so well known but are strong in this area.

At this time there are not many standards agreed across the industry, but more group specific depending upon which platform you are developing on. The main standards that exist are around networking and connectivity. Groups and Communities currently discussing and creating IoT Standards). Some of these are around security and securing the IoT devices.

There are a number of standard practices that you can carry out to help secure your IoT device at the Operating System level:

Right Operating System

Choosing the right Operating System is key to ensuring your IoT Device will function as you require it to and support the applications you are using. You should look to only install the Operating Systems elements that are needed to reduce any future Security Issues through none used modules. Streamlining (or removing none used modules) also reduces the amount of space needed on the IoT device.

Upgrades

Upgrading to latest versions of the Operating System at regular intervals will ensure that you have the latest software and that additional space is not taken up with old patching files. This also ensures any known security holes in the Operating System are protected. This also has the added benefit of keeping up with any new features introduced into the Operating System.

Patching

Patching of both the hardware BIOS and Operating System should be considered. Ensuring that the BIOS is at the latest level makes any patching more effective as the Operating System and patches are normally created and tested on the latest hardware and releases.

Regular patching needs to be carried out in order to fix any known exploits or Security holes in the Operating System/ Some latest Operating Systems patch automatically at a regular interval which when configured allow this task to just be a monitored one to ensure devices are being updated.

Access

Only allowing the users or systems that need access to the device and removing all other accounts and access rights will secure the device. The levels of access control, user id’s and passwords will be dependent on the Operating System used. These can range from local settings to a centralised control such as Active Directory.

Below are some links to Operating Systems and their supported hardware platforms.

Brillo

• https://developers.google.com/brillo/?hl=en

Contiki

• http://www.contiki-os.org/
• http://www.contiki-os.org/hardware.html

FreeRTOS

• http://www.freertos.org/
• http://www.freertos.org/RTOS_ports.html

Linux

http://www.linux.org/

mbedOS

• https://www.mbed.com/en/development/software/mbed-os/

Microsoft

• http://www.microsoft.com/en-gb/server-cloud/internet-of-things/overview.aspx

OpenWSN

• https://openwsn.atlassian.net/wiki/pages/viewpage.action?pageId=688187
• https://openwsn.atlassian.net/wiki/display/OW/Hardware

Riot

• http://www.riot-os.org/
• http://www.riot-os.org/#usage

Tiny OS

• http://www.tinyos.net/
• http://tinyos.stanford.edu/tinyos-wiki/index.php/FAQ

Next in the blog series “IoT Device Security Considerations and Security Layers” is Sensors and Instruments.

There are many different sensor types ranging from the consumer available to those used in industry and specialised, e.g:

• Barometric Pressure sensor
• Temperature sensor
• Altitude sensor
• Colour sensor
• Accelerometer sensor
• Compass sensor
• Humidity sensor
• Proximity sensor
• Motion sensor
• Light sensor
• Roation sensor
• Water sensor
• Heat sensor

Sensors will typically be connected hard wired or remote.

Security for Wired sensors will be inherently secure as the connectivity is over a physical wire.

Where there is wireless connectivity the type of wireless used should be considered with security in mind. This is called a WSN (Wireless Sensor Network)

The list of considerations could be listed as:

• Wireless Protocol
• Authentication
• Encryption
• Pairing
• Signal strengths and limitations
• Certificates

Some good white papers that cover WSN’s and security considerations are:

• Internet of Things: Wireless Sensor Networks
• Wireless Sensor Networks and the Internet of Things: Do We Need a Complete Integration?

The next layer to cover in my blog series on IoT Device Security Considerations and Security Layers is that of Storage and Data.

Breaking IoT down to a basic form there will be two main sorts of IoT devices:

• Those with local data storage on the IoT Device
• and those without

That’s not to say that there would be a local storage system nearby such as sensors in a car having an on-board storage system for data that is then sent to a central system somewhere.

Either way, the future data economy will be huge. The IoT is predicted to create masses of data. Cisco have predicted this growing to 403 zettabytes a year by 2018.

Internet of Everything (IoE) Potential Impact on Cloud

●   Globally, the data created by IoE devices will reach 403 ZB per year (33.6 ZB per month) by 2018, up from 113.4 ZB per year (9.4 ZB per month) in 2013.

●   Globally, the data created by IoE devices will be 277 times higher than the amount of data being transmitted to data centers from end-user devices and 47 times higher than total data center traffic by 2018.

(Source Cisco)

That’s a lot of data to secure!

When looking at Storage and Data security the main consideration on securing data should be around data relevancy and what should actually be stored. This can be done locally at the IoT device with the programme/application collecting data at specific intervals or back at a collection system that applies policies to the data and filters out the relevant data, deleting the rest (Both could be done).

(Click diagram for a larger version)

Defining a Data Life Cycle is a key part to IoT Data Security.

Security of data on the device will depend upon the local security designed. There may be nothing stopping a sensor physically being stolen or tampered with, however electronically and through software other measures can be taken.

Storing data on a centralised solution and applying a level of security around that would provide a more secure environment as data transmitted could be encrypted through the network elements used.  Back end solutions will probably use standard solutions available today with well defined security standards and options available to secure data.

Where data is stored locally on the IoT device adding things like encryption at rest to data on a device may be necessary in some cases, but the flip side is an impact to the responsiveness of the device and data retrieval. This also adds to the complexity of the device and ultimately cost.

Personal security may also factor into the IoT Device solution, such as a wearable device on the wrist to record fitness data. As it is worn and secured onto the consumers wrist it may be classed as secure until the consumer went to a data point to upload their latest statistical data and analyse the results. Data is stored locally in this use case and then uploaded to a central point afterwards.

To summarise a list of considerations:

• Local or Central Storage
• Data Life Cycle
• Data relevancy
• Data retention policies
• Encryption
• Back end system data security
• Security by use (ie. wearables)

Continuing the theme of IoT Security as first discussed in my post IoT Device Security Considerations and Security Layers, the next layer to look at is the Chipset.

There are lots of different chipsets available that can be used for IoT devices such as ARM, Intel, TI, etc. There are also lots of development platforms utilising these and other chipsets such as Raspberry Pi, Beagle, MinnowBoard MAX, Contiki, TinyOS, Nano-RK, Launchpad etc that consume these chipsets.

Chipset manufacturers have already recognised the importance of having a good security layer and security features within and supported by the chipsets manufactured for the IoT.

To build on this capability some manufactures are buying security solutions to complement and enhance, whilst others are creating.

• ARM Expands IoT Security Capability with Acquisition of Sansa Security
• Intel working with McAfee

These developments by Chipset manufacturers means that IoT Security is high on their agenda and provides the industry and consumer with a large amount of choice on additional security features based on chip and that can work with the chip in form of software.

As the IoT develops so will the security enhancements and capabilities of these devices.

Following on from my post on IoT Device Security Considerations and Security Layers the subject of this blog post is to look at the Power Source layer.

Power Sources for IoT Devices will differ depending upon the type of IoT Device being used or designed and its use, however they will fall into 3 main source of power.

• Mains
• Battery
• Wireless

So how secure is a power source? There have been demonstrations on how data can be hacked through power outlets (How to use electrical outlets and cheap lasers to steal data) which have concentrated on using the fluctuations and noise in the power supply to work out what is being typed. This would effect both mains and wireless connections as these could be monitored in some way.  Battery presents a more secure method of providing a power supply.

At present any breaches using a power source are few and far between, however as the IoT connected world continues to evolve, perhaps this is one area that more security considerations are needed.

Not all IoT Devices will need mains power as there is a huge drive for wearables and mobile. The mains power would be aimed more at IoT devices within a business (such as plant machinery sensors) or a home system (turning on power or heating).

Mains also provides a medium to connect IoT devices such as Smart Meters or a Home Network over the mains using Ethernet to Power converters. IoT devices may well utilise this as a method to communicate back to a local hub, then off to a central hub via normal network connectivity.

There are already standards/rules for smart meters set out to protect devices and consumers around:

• Data Access and Privacy
• Security

(Smart meters and how they work)

Battery IoT Devices tend to be self contained for power and apart from a future change of the battery when its power expires connectivity and networking tend to be through the front end.

As the IoT advances there will be advancements in the protection for devices and in the rules that govern them. Not all devices will be equal with the same power needs, but one thing is constant. They all need power to operate in one form or another.

Some useful links:

• IEEE IoT Standards
• Groups and Communities currently discussing and creating IoT Standards