The Internet of Things (IoT) is generally regarded as the next evolution of the internet. With it, IoT has attracted a great deal of enthusiasm and hyperbole in equal measure. There is little more that needs to be said, except perhaps that, as the hype inevitably subsides, the ‘Internet of Treats’ (for entrepreneurs) becomes the ‘Internet of Threats’ to those who use or operate such products and services that fit within the IoT’s broad definition. The many challenges of security, safety and privacy are more than a technical concern and have now made it onto boardroom agendas. Get these aspects sufficiently wrong, and it could be an extinction event for a business.

Whilst cyber security is well understood amongst IT and computing professionals, the attraction of the IoT is drawing interest from newcomers from all quarters who are significantly less familiar with contemporary best practices or even the full implications of a breach. With connectivity being a fundamental characteristic of the IoT, your insecure product may not be the ultimate target, yet it could provide the pivot point for an attack elsewhere in the system or even be used as a weapon to attack other systems – it could be recruited as a zombified thingbot.

Cyber security is also a moveable feast – what is deemed secure today may not be tomorrow, hence cyber-hygiene is critical. Vulnerabilities and hacks will evolve over time as new IoT applications emerge, grow and mature. Equally there is an increasing number of new-to-security developers who are just starting to realise the scale of threat that adding connectivity to their product brings. Introducing security vulnerabilities into a network can create unintended consequences for anybody connected to it, and therefore anybody looking to connect into the IoT has a duty of care towards others.

What we really want to create is an ‘Internet of Trust’, yet that is not the situation today as far too many companies have rushed to market with scant regard to IoT security in pursuit of quick profits. We have a lot of remedial work to undertake, and we must also ensure new products and services are designed with security in mind at the outset, as security mechanisms are harder to retrofit. For the IoT to become a reality we have to ensure systems can be resilient, we must add depth to our defences and make it ever harder for adversaries to succeed.

On that front, there is good news: whilst the IoT brings a growing attack surface, the underlying principles that inform security best practice are well established. With a necessary ‘start at the beginning and successively raise the bar’ mentality, the Internet of Things Security Foundation (IoTSF) has set about bringing a focus to matters of IoT security – and that requires more than purely technical considerations. This article is intended for the security-inexperienced and non-experts. It has been created with the help of some of IoTSF’s members and partners.

So, let’s get down to business.

KEY CONSIDERATIONS FOR INTERNET OF THINGS SECURITY

IoT elements should be designed with security as well as features in mind. By considering the answers to the following questions, developers can produce products with enhanced value, quality and usability and with better security. These products will then form part of a safe, secure, scalable, manageable and transformative IoT.

Does the data need to be private?

Many IoT devices will require the collection, analysis and transmission of potentially sensitive data. It is essential that this data is adequately protected at all times, and that the user is aware what private data is being processed. Devices should therefore:

• be designed with security in mind from the outset and be appropriate to the threat and device capability.

▪ Security architectures for devices, networks and systems should be developed at the same time as the devices themselves, rather than retrofitted at a later date.

▪ Consideration must be given to the intended use scenarios of the device and what security is appropriate.

• manage encryption keys securely. Consider the lifecycle of encryption keys, from provisioning through to decommissioning and/or revocation of the device.

• offer appropriate protection for all potential attack surfaces (for example device, network, server, cloud and so on). As well as the device itself, sensitive data may be exposed in other connected systems. Consider how the security of the data will be maintained throughout the whole network.

• ensure identifiers are removed or anonymised where necessary. Exposure of sensitive personal identifiers may allow collection analysis of private data by unauthorised devices.

• inform users what private data is required in order for the device to function. Users want to take advantage of the opportunities offered by the IoT, but also want to ensure their privacy is protected. Devices should be clear about what private data they are handling, and what the impact of denying this capability will be.

• allow users and security products to review sensitive data to verify the device is maintaining privacy. As well as ensuring privacy is maintained, this will allow users/devices to implement local security policies for handling sensitive data.

Does the data need to be trusted?

Data may need to be protected from tampering and modification in transit. This may be a malicious attacker or simply poorly configured devices mishandling data. Appropriate security considerations may include the following.

• The device or system uses a hardware-rooted trust chain. This allows the user to protect against sophisticated low-level software attacks and ensures that all software allowed to run on the device is appropriately authorised.

• Integrity of software is verified (for example, secure boot). This helps to ensure that only known software is allowed to run on the device.

• Authentication and integrity protection are applied to data. Such protections allow users to be confident that received data is correct and from the claimed source.

• Compromised or malfunctioning devices can be identified and revoked. Erroneous data from such devices may affect other functionalities of the system. Providing a way to identify these devices and then block, filter and revoke them in a secure fashion provides mitigation in this scenario.

• Data is isolated from other systems or services where applicable. IoT networks may handle many different types of data. To minimise the risk of data leakage, it should be clear which systems and services have access to which types of data.

• System testing and calibration ensure data is handled correctly. Ensuring that the system handles data as designed is crucial in providing security assurance.

• Device metadata is trusted and verifiable. Trusted metadata will allow users and devices to have confidence that the device is functioning as intended and help to identify malfunctioning or compromised devices.

• Reusing existing good security architectures rather than designing brand new ones. While some security challenges for IoT are new and different, there are many that are similar to existing problems which have been studied for many years. Consider whether existing security architectures meet your needs.

Is the safe and/or timely arrival of data important?

Consider how the service would be impacted if data could be blocked or delayed.

• Data is accurately time-stamped. This allows users and devices to determine how current the data is and act accordingly.

• Integrity of data in the device, server and other parts of the system is designed in from outset. Considering any integrity requirements during the design phase will enable the system to meet such requirements without re-engineering at a later date.

• Devices should provide failure handling and status monitoring to meet availability requirements. When a device fails, it should fail into an appropriate configuration for its use.

• Users or managers should be able to monitor devices to determine their current status.

• Carriers and device managers can identify safety and timeliness needs in a secure, trusted fashion. Devices should securely communicate their requirements to allow networks to allocate resources accordingly and act appropriately when these are not being met.

• Any reliance on other systems or devices for availability is clearly detailed to the user. The user must be aware of what other systems their device has dependencies on in order to meet security requirements.

• Devices should identify themselves to a network using a secure identifier. This ensures that the network can allow efficient management and allocation of resources.

• Be clear what functionality the device is offering and what its intended use is. Make users aware of any restrictions or limitations. Some devices may appear similar, but have different assurance or reliability profiles. In order to avoid inappropriate deployments, users must be clear of what the device is intended to achieve.

Is it necessary to restrict access to or control of the device?

Prevention of unauthorised access or control is vital to secure devices. If an attacker gains control of the device, they may be able to access sensitive data or cause problems elsewhere in the network. To reduce this risk, developers should ensure the following.

• Development processes incorporate secure coding standards, penetration testing and so on. Practices such as these reduce the risks of unintentional vulnerabilities occurring in the product and help to identify and fix potential issues.

• Defences against hacking are designed in from the outset. Considering potential attacks during the design stage will ensure the device’s security functionality is built on solid foundations and reduces the risk of serious security architecture issues emerging later in development.

• Service management occurs over an authenticated channel. Only authorised entities should be able to manage IoT services.

Is it necessary to update the software on the device?

If a device is running out-of-date software, it may contain unpatched security vulnerabilities. Such vulnerabilities may allow exploitation of the device and its data by attackers.

Developers should ensure the following.

• The vendor update and management process follows best security practice. Security patches/updates should be applied in a timely fashion without impacting the functionality of the device.

• Only authenticated sources are able to provide security updates or patches. Allowing unauthenticated updates could allow attackers a way to run malicious code on the device.

• Users and managers are easily able to see a device’s patching update status. This allows verification that devices are adhering to a specified security policy and ensures that remedial action can be taken if required.

Will ownership of the device need to be managed or transferred in a secure manner?

Many IoT devices will change ownership at some point in their lifetime. To preserve the security of the device and data throughout its lifecycle, developers should:

• provide a secure method to transfer ownership of the device to another user. This will allow both the old and new users to verify that the transfer of ownership has succeeded and that any sensitive data will be handled appropriately after handover.

• be clear which system components (devices, data, network and so on) are owned by the user. Users or managers can clearly identify what their responsibilities are for ownership transfer. This will minimise the risk of security issues arising through misunderstandings of responsibilities.

• ensure that change of ownership does not impact security updates. Critical security updates must continue to be supplied, regardless of who now owns the device.

Does the data need to be audited?

IoT services may be required to meet a user audit, an enterprise audit or a regulatory audit requirement. Developers should consider providing:

• managed access to IoT data (for example at a local hub). If properly secured, this feature will build end-user trust and enable compliance with network policies (such as intrusion prevention systems). This feature may also enable innovation via integration of IoT data sources.

• policy controls to disable unwanted features. Failure to provide these may limit use in some enterprises, regions or markets.

This should give you a good overview of what needs to be thought about up-front to secure the IoT. More, in-depth materials are in the IoTSF production pipeline and these will be free to download via the IoTSF website. We aim to make these both comprehensive and simple to use as we move to continually improve the quality and drive the pervasiveness of security across the IoT.