With IoT devices in both industrial and consumer sectors customers are expecting manufacturers to deliver secure products. For the benefit of consumers, the UK government has issued an IoT good practice guide, then followed up with legislation and enforcement. Therefore, it is in this context that this article presents some general security trends for IoT devices.

Secure by default

It is recognised that trying to secure a device that has not been designed to include secure features causes problems for IT professionals and end users alike. The IT department has to follow a stack of additional procedures to secure the device and then the user also needs to take extra steps too. Unfortunately, it only takes one misstep in these processes to leave the device vulnerable to a cyberattack. Hence a need for a different approach, which the National Cyber Security Centre (NCSC) calls security by default.

When a customer receives an IoT device it should have the security built-in, thereby it will not require special procedures, configurations, or additional products to make them secure.  The NCSC has set out a set of principles to underpin the Secure by Default approach, the key ones being

• security should be built into products from the beginning, security cannot be added in later;
• that security is never a goal in and of itself, it is a process – and it must continue throughout the lifetime of the product.

Very closely related to Security by Default is the need to implement Privacy by Design. A similar argument is made for data privacy, in that it is difficult to add privacy features if not designed, for example, appropriate security measures to protect sensitive data.

Having security at the hardware level is crucial and is an important element of Secure by Default. This could include hardware-based security mechanisms such as tamper-resistant chips, and memory management. Similarly, ensure that robust security measures for cloud-based IoT services are in place, for example, access controls including secure APIs, encryption, and monitoring.

IoT devices will often contain software and the development of secure code and good coding practices still need to be applied to the IoT software. Not only is the code easier to maintain but helps spot potential issues early. For example, conducting regular security audits of the code running on IoT devices to identify and address potential security flaws. More and more customers now expect that firmware and software on IoT devices are capable of performing a secure update to patch known vulnerabilities. 

Zero trust

The traditional castle security model takes a layered defence approach to network security. The layers allow for segregation of the network with each layer having control of access to the layer. In addition, each layer would have different methods of control (defence in depth), and would also monitor the network to detect and mitigate an attack.

This traditional approach is predicated on the network being secure by design and without any vulnerabilities from the beginning, this includes components and services from the supply chain. Resulting in all on-network components (within parameters) to be trusted by default. Moreover, this traditional view does not take into account insider threats.

The Zero Trust approach assumes the network is compromised and nothing can be trusted. A Zero Trust network is one in which a critical resource or set of resources along with its security parameters are put into microsegments. This allows the traffic to those resources to be assessed, based on rules, when an actor (users, IoT components or services) tries to access the resource. It is also good practice to segregate IoT devices into separate network segments to minimize the impact of a potential breach and limit lateral movement. In a Zero Trust approach, actors are given the least privilege, only able to access resources they need to perform the task given. In addition, each session is re-authenticated to ensure the actor is authorised to access the resources.

Artificial intelligence

Traditional castle defence and the Zero Trust approach both advocate some form of monitoring of the network. The different layers of security controls mitigate a vendor compromise, through detection and mitigation. The security information management (SIM) collates, stores, and analyses the logs of network activities. While, a security event management (SEM), will evaluate the logs in real-time looking for abnormal activity. In addition, security orchestration, automation and response (SOAR) can also use predefined workflows to help curtail the attack. Artificial Intelligence is being used more in implementing behavioural analytics and anomaly detection to identify unusual patterns of behaviour that may indicate a security threat. The models do take time to train and will require a good understanding of the different models to be used. In addition, it is recommended that there needs to be an expert in the loop working in collaboration with the AI, for example, to triage and contextualise alerts from the AI system.

The supply chain and software bill of materials

Increasingly attacks are coming from vulnerabilities in the services or components supplied to an organisation. Therefore, managing supply chain risk is becoming ever more of a concern. Many of the cyber frameworks, including the UK’s National Cyber Security Centre’s Cyber Assessment Framework (CAF), do include the need to ensure security in the supply chain and to guarantee good practice is undertaken by the suppliers.

Included in the CAF is the security of the data. This can include data passed as part of a service or device that may cause an adverse impact on any essential functions. The data needs to be identified and categorised, and an appropriate level of security based on the importance of the data is put in place to prevent unauthorised access, modification, or deletion of the data. It is now commonplace to encrypt sensitive data both in transit and at rest to protect it from unauthorized access. Moreover, strong authentication mechanisms, such as multi-factor authentication (MFA), are increasingly important to prevent unauthorized access to IoT devices and services.

Many IoT devices and systems will include components from different manufacturers, each with its firmware. Keeping track of which components are in which device, and then what is the version of the firmware for each component is non-trivial, but essential. One advantage of having this information is when a firmware update or a vulnerability is found in one of the components of the IoT device, then it is possible to track which devices are affected. To support this process manufacturers of components are devices are not issuing Software Bill of Materials (SBoM). An SBoM is a machine-readable list of the software used and its dependencies. The SBoM will have to provide sufficient attributes of the software to be able to uniquely identify the software. The main use case for SBoMs is interoperability and transparency across the supply chain, which supports the regular updating of firmware and software on IoT devices, especially after a vulnerability patch has been released. However, to achieve this there must be agreement within the supply chain on data formats. There are various formats and tools available to support the process.

Vulnerability disclosure

Hopefully gone are the days when manufacturers believe that their IoT devices are fault-free. While manufacturers will test to ensure an IoT device works as expected, and some would have thought through the misuse cases, users will potentially do something unexpected and find exploits in the system. Moreover, there are always people who want to see what else the device can do beyond its initial design. Yet trying to inform a manufacturer of the found vulnerability is difficult, sometimes near impossible. Vulnerabilities will be found in an IoT device making it easier for them to be reported will help the manufacturer. However, the IoTSF reports that only about a third of manufacturers have yet implemented a method to report vulnerabilities, hence it is still only a trend.

IoT security standards and certification

IoT devices are used in various industries and consumer use. Some of the industries are regulated and will have specific standards and legislation, while others guided by good practice guides. These will often give a baseline of security for IoT deployments.  Manufacturers will often seek certification because they need to comply with legislation, which their customers require them to have it, and increasingly, to help differentiate their IoT devices from others in the market. The UK’s Department for Digital, Culture, Media & Sport (DCMS) published a Code of Practice for Consumer IoT Security which led to the ESTI standard EN303645. There are certification schemes to that standard for example the IASME IoT Assured Scheme. Adopting IoT security certification programs will help consumers and businesses identify secure devices.

Conclusions

Customers are expecting that IoT devices will be secure, be it industrial or consumer IoT Devices. The threat landscape is constantly evolving, and this is reflected in the change in practice to be more proactive in designing security into an IoT device, assuming a network is not secure and managing the supply chain. These will in many cases result in a change to working practices. However, it is worth remembering that it is difficult, if not impossible, to make an IoT device secure if security was not designed for the IoT device in the first place.