Internet of Things (IoT) Security Checklist

The first industrial revolution was fuelled by steam. It powered factories and transport mechanisms, enabling us to move people and things further and faster than before. The Internet revolution altered how we communicate. The fuel in this case being data: either sharing knowledge or gathering it from users. With data being referred to as the new oil, the rush is to gather more data, and to work with it in smarter ways than your competition.

For many, the current revolution is the Internet of Things (IoT), still fuelled by data, but now with devices being more diverse.

About IoT

IoT is a term that encapsulates devices designed to gather data with sensors. They either react to this data locally, or transfer it for processing elsewhere. People may be users of IoT devices, or they can operate in machine-to-machine (M2M) mode where human interaction is not required.

It is easier to list some current IoT applications to get the idea across and the following categories are listed in order of personalisation for the user:

1. Wearables – Devices worn by their users, which use sensors to collect information. A typical example would be a fitness tracker that monitors GPS location and heart rate. The device would typically communicate with a server that issues personalised feedback to improve performance. These are the most personal, as they are worn by the individual.
2. Smart Home – Devices in or around your home which help to simplify your life or aim to reduce your costs. Examples in this area include systems to regulate the heating of your home by turning on the boiler as you head home, or a CCTV camera which you can remotely view on a phone or tablet. The home owner is the person who purchases it, so it is still personal to that consumer.
3. Small Office/Home Office – Devices for business purposes are arguably IoT. Items such as routers and Wi-Fi access points are embedded devices, which share similar security needs to IoT. Enabling someone to work from home is also personal to the user, even if they have less control over devices if work has sent them pre-configured.
4. Smart City – Devices owned by local government designed to make a city more efficient. Examples in this area would include updated street lights with fault detection (saving the cost of operating a phone line or man power), or smart traffic lights able to adjust flow based on real-time observations. This is the least personal because it will be bought and installed by the local authority.

Really, the ecosystem for IoT is enormous, and we could add even more categories. Would you consider a car to be an IoT device, for example? They have sensors to assist them in parking or self-driving, and many support Internet connectivity or wireless technologies. However, they are supremely more complicated than the single purpose devices listed above. We have designed this article around devices such as those that fall into the categories above.

Hopefully by listing a few example applications you can understand the concept and potential of IoT.

IoT Security

When developing the future, it is easy to focus on the core concept. To spend hours honing the features listed on the box to provide the best user experience. We understand that. However, you should not forget to provide these functions as securely as possible. The following lists the four potential risks that should be considered:

• Consumer Risks – Failure to secure your device risks the personal information of consumers, potentially leading to identity theft or embarrassment depending on the data being handled.
• Collateral Risks to Connected Network – When a consumer connects a device to their home network it is unlikely that they have considered the potential impact. If the device presents a remote admin interface to the Internet (common with CCTV and baby monitors), then it can provide a gateway for an attacker into the connected network. Once inside the firewall the attacker can pivot to unrelated devices to cause more damage.
• Collateral Risks - Automatically exploitable flaws in IoT devices have been used to create Distributed Denial of Service (DDoS) attacks against unrelated third parties. The impact here is to unknown third parties and not your users or yourself directly. However, the scale of the impact will dictate the reputational risk as media scrutiny grows.
• Reputational Risks – Failure to secure your device will likely affect the reputation of the product as well as the company who developed it. This is the direct impact to yourselves. Either a consumer or collateral risk will result in reputational damages.

The biggest news items in the IoT security space have been DDoS related. For example, the Mirai malware infected 500k IoT devices by exploiting 60 common factory default username and passwords. It then used those devices to trigger a DDoS affecting online services, including GitHub, Twitter, Reddit, Netflix, Airbnb and others.

The root cause was simple: known or guessable passwords on devices such as Internet-enabled web cameras.

One of the most significant consumer risks was posed by the now infamous My Friend Cayla doll. Cayla is designed to hold conversations with a child using voice recognition software. Researchers found that it was possible to compromise the doll to say inappropriate things. There was also controversy around privacy issues since the doll has a microphone which is always on, and voice data was being sent off to a 3^rd party which saved it for “future use”. The doll is now banned in certain countries due to these privacy concerns.

These examples demonstrate weak engineering practices and failure to consider potential impacts.

Root Causes: Categories of Risk

When considering the security of your IoT device you need to be aware of the root cause of security problems, as summarised below:

• Technical Flaws – If the flaw comes from the implementation of the device then it is technical. An example in this category would be using a default or easy-to-guess password for administration.
• Privacy/Legal Flaws – If the device handles user data or the sensor can be used to breach privacy, then special consideration should be given to the legal aspect. Identify the potential of privacy breaches. Develop technical controls to guard against them when possible. But definitely consult legal advice to determine where liability for breaches will lie: will they be on the end user or you as the provider?

The checklist we have provided (linked at the end) is designed to limit your exposure to these technical flaws.

High-Level Advice

Once devices are manufactured it is costly or impossible to bolt on security. The adage stands true: “a stitch in time saves nine”. Introduce security concerns into the discussion at the design stage. Consider the two categories of risk listed above and you will be on your way towards saving pain later.

The following high-level tips should be at the front of your mind while developing your devices:

• Secure by Default – Ask yourself if configurations are secure out of the box, or if the user must do something to enable protection? As cybersecurity has evolved over the last decade, the strategy of securing out-of-the-box is preferred to relying on users. General tips would include disabling features until they are enabled and generating random per-device passwords, for example.
• Provide an Update Function – Even the best engineered solution will eventually have some functional or security bug that would require an update. To support this, design a robust update mechanism which can protect users long term.
• Assume the source code is visible – Make sure that there are no hard-coded secrets on the device which have a security impact for all devices. Attackers will have physical access to your products over many years. These are ideal conditions from which to reverse engineer. If you need hard-coded secrets then design them to be unique for each device. So that finding the default admin password within firmware will not expose all other devices. Additionally, be aware that the source for any admin interfaces is equally exposed.
• Plan for Decommissioning – IoT products are consumer electronics in most cases. Give users an easy way to remove their data from the device so that they can sell it on or dispose of it securely.

Engineering with these principals from the earliest possible starting point will put your devices on a secure footing.

Review Methodology

With the root causes and high-level principals established, we'll now outline the recommended methodology to follow:

• Device Decomposition – Break the product into a list of its interfaces. Identify every hardware and software interface which can be interacted with and create a matrix to capture each individual element. All physical interfaces – such as wired or wireless networking, USB, JTAG, Serial Interfaces – need to be listed. All software interfaces – such as HTTP, the application running over that, SNMP etc – also need to become lines within that matrix. At the end of this process you will have discovered the Attack Surface for your device.
• Review Each Interface – For each item in your matrix conduct a risk analysis. Find best practice guidelines and implement them. Update your matrix with any technical or privacy/legal concerns that you have identified or accepted during your evaluation.
• Find a Security Partner – If you lack the skills in-house to conduct your review, or if you just want third party verification, find a partner. Going to them with your matrix already created will reduce the time required to deliver, since you have already done some of the leg work.

While Secarma can play the role of security partner (and obviously we would prefer you to talk to us), this is not us demanding you line our palms with silver or the sky will fall. It is honest advice that no matter how good a security team you have involved in-house, or how well trained in security your developers and engineering team are, fresh eyes on any project will spot gaps that people involved too closely will not see.

The budget costs for third party validation of your device should be small, relative to the cost of bringing it to market. Armed with a matrix of your interfaces any provider should be able to accurately quote the effort required to give reasonable assurances. Ask for some quotes early and see what suits your budget and risk appetites. As with everything in business: quotes are free.

IoT Security Checklist

The first step is to conduct device decomposition. Analyse your product to find all interfaces and aspects and track them in a matrix. The following is a download URL to an example format:

https://github.com/SecarmaLabs/IoTChecklist/raw/master/Blank-Device_Decomposition_Matrix.xlsx

For each line in your matrix you will need to discuss any technical or privacy/legal issues which that item may pose. This is best done as a paper exercise at the design stage before developing, but it can also be conducted later.

The following link points to our baseline security checklist for all IoT devices:

https://github.com/SecarmaLabs/IoTChecklist/raw/master/Blank-IoT_CheckList.xlsx

This contains two workbooks. One which captures general risks, which are applicable to everything representing the minimum standard you should aim for. The second workbook covers the networking options for devices. The choice of networking technology varies and is arguably the largest single topic.

Want more information on IoT security? Contact our experts here.