IoT Security – Secure by Design
Photo by Sebastian Scholz (Nuki) on Unsplash
Security of IoT Devices is a hot topic presently, legal frameworks and best practices are rapidly developing. In this series we will share some of the developing legal frameworks and standards, describing some of the practical considerations for those.
On the 27th January 2020, the UK Government announced plans to introduce laws to protect users of internet connected household items from the threat of cyber attacks.The new laws will focus on the first three recommendations from the code of practice recommended in the Secure by Design report previously published. These are:
All consumer internet-connected device passwords must be unique and not resettable to any universal factory setting
Manufacturers of consumer IoT devices must provide a public point of contact so anyone can report a vulnerability and it will be acted on in a timely manner
Manufacturers of consumer IoT devices must explicitly state the minimum length of time for which the device will receive security updates at the point of sale, either in store or online
But what does this mean for product designers and manufacturers. In the series we introduce the “Secure by Design” code of practice considering a typical IoT system architecture consisting of an end device, gateway, Wi-Fi router, mobile device and cloud application.
There are 13 recommendations in the Secure by Design guidance, but lets get started by considering those planned for new UK law.
No Default Passwords – All IoT Passwords must be unique and none resettable by a default passwords. This applies to end-devices, gateways and home WiFi routers, mobile applications and cloud services. Considering the sensor end device and the gateway then generally this can be overcoming by implementing a hardware root of trust for unique device identification and securely including this unique device on your network.
Implement a Vulnerability Disclosure Policy – requires a public point of contact allowing security researchers, users and others to report vulnerabilities. Generally it is helpful for manufacturers and service providers to set expectations in terms of response times and full disclosure of any identified vulnerability. A defacto standard of security@’domain name’ or security-alert@’domain name’ is used for reporting issues. The vulnerability disclosure policy can usually be found at https://’domain name’/security, e.g. https://hive.com/security/
Keep Software Updated – All software components in internet-connected devices should be securely updateable. Updates must be timely and not impact on the functioning of the device. An end-of-life policy must be published for end-point devices which explicitly states the minimum length of time for which a device will receive software updates and the reasons why. The need for each update should be made clear to consumers and an update should be easy to implement. For constrained devices that cannot physically be updated, the product should be isolatable and replaceable. Manufactures and product / service providers will need to carefully consider and plan:
Device deployment and lifetime management.
Replacement, for end devices that can not be updated but may in future become a source of vulnerability.
Correct device function during updates. The devices must continue to perform their main functions during and after updates.
We trust you found this article informative. At Invent Design Build we follow security best practice from the IOT Security Foundation a source of current information, training and guidance.