Questions to ask your IoT supplier

The good news is that the supplier provides firmware updates and solves the issues and that the supplier gives guidelines to implement these presentation devices in a separate network. The bad news is that still, not all is well. One of the things is that the webserver implements https, but that the certificate used is self-signed. This is causing the user to be presented with a warning that it is not known if the certificate is genuine, which is confusing for users who are told not to proceed when this happens at other websites.

In the same week, the request was made for the introduction of IP security cameras. Unsurprisingly the situation was very much alike. The internet search revealed vulnerabilities and exploits and the supplier provided firmware updates and advice on how to implement the cameras. A week later there was a request for an automatic license plate recognition system... and then a payment system...
and then VOIP-phones...

All the devices qualify as the Internet of Things (IoT) devices: IoT is an emerging concept comprising a wide ecosystem of interconnected services and devices, such as sensors, consumer products and everyday smart home objects, cars, and industrial and health components (Enisa). Their expected lifetime, in our particular case, is 5 years at a minimum. We want to make sure that the use of these devices imposes an acceptable risk during their whole lifecycle. Obviously, this requires some action from the manufacturer/supplier and we wanted to have a set of specific requirements for suppliers to use in the IoT-tenders.

I started with a set of requirements based on the common vulnerabilities found on the devices we envisioned to implement. I shared this set with some experienced security specialists to complete and then the Enisa Baseline Security Recommendations for IoT, published in November, came to my attention. This report I found very useful. Not only does it contain substantiated recommendations, but also because Enisa is independent of suppliers and does not recommend any product. This makes acceptance of the recommendations easier in a lot of cases. Another document well worth reading is the Internet of Things (IoT) Risk Manager Checklist, Salen Churi, University of Chicago. This report is about liabilities of IoT manufacturers and providers, but it addresses the same topics (e.g. duty to maintain firmware) as the Enisa report.

Although the initial client request was to deliver a set of requirements for the supplier it should be obvious that the security not only depends on the IoT devices themselves. The architecture of the system within the existing infrastructure must be secure and the operating model and governance of the complete ecosystem must be in place. Even if the IoT device is severely flawed it might be possible to implement it in a secure way, applying the right architecture. The most obvious example is the creation of a dedicated firewalled network for the IoT devices. Once implemented in a secure way, the ecosystem must stay secure; hence a strict lifecycle management must be performed. It is up to the Solution Architect to come up with an architectural design, including lifecycle support, which is sufficiently secure given the constraints. The IT security owner should accept the risks regarding the infrastructure and the business data owner should accept the risks regarding the data.

In order to be able to create such an architectural design, the architect needs information for which I created a questionnaire, also based on the Enisa report. For this blog, however, I will limit myself to the requirements for IoT devices. I hope you will find it helpful.

The supplier must

• Inform the company about published or identified security issues in their software or any component within 24 hours
• provide a workaround against security issues within 30 days
• provide a patch for security issues within 90 days
• provide security updates for his software and all components for at least 5 years
• actively monitor the security publications (e.g., mailing lists) for each component they use
• Provide an automated patch process (one cannot patch 100+ devices by hand)

The supplier shall describe at least the

• controls that have been applied to the software to ensure an appropriate level of security
• components, configuration, applied baseline, patching procedures and malware protection
• different network segments expected to securely operate the service delivered
• purpose and security measures for remote access

The device must

• have upgradable firmware
• ensure credentials are not exposed in internal or external network traffic
• store credentials salted, hashed and/or encrypted (and not in clear text)
• delete information when no longer than technically needed
• not have hardcoded credentials
• not have “hidden” services

The device should

• continue to work without network connectivity
• encrypted communication to protect confidentiality of data
• use protocols designed to ensure that, if a single device is compromised, it does not affect the whole set
• ensure only necessary ports are exposed and available

References:

https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot
https://www.aig.com/content/dam/aig/america-canada/us/documents/brochure/iot-risk-manager-checklist.pdf