Recently a client wanted to introduce a new type of presentation gateway. These devices provide a means of making audio-video presentations via Wi-Fi. The user logs in to a website provided by the presentation gateway instead of plugging in a video cable. It would solve the problem of having to provide all kinds of different cables to connect laptops and tablets. A quick search on the internet revealed a set of vulnerabilities complete with exploits. It had hardcoded credentials, it allowed path traversal to read all files from the web interface, it stored credentials in clear text...
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