5 Questions to Ask your IoT Vendors; But Do Not Expect an Answer.
This year shapes up to become the year that IoT exploits started to become "mainstream news." Mirai, car hacking, and ubiquitous router exploits are now being discussed outside security conferences. One question that comes up from time to time is what a "minimum standard" could look like for IoT security. Today, default passwords and basic web application security flaws are the number one issue. But we all know that as one vulnerability is being patched, two more are discovered. Asking vendors to deliver a "vulnerability free" product is not realistic. So what should we ask our vendors?
1 - For how long, after I purchase a device, should I expect security updates?
If we know that the devices we buy today are vulnerable, then we should expect the vendor to deliver patches for some years to ensure that we do not have to replace the device earlier than expected. There is always a chance that a vulnerability will not be software patchable. For example, if the device supports a certain encryption algorithm, and includes specific hardware that is optimized for this algorithms, then it will not be possible to change the algorithm if it turns out to be broken. In this case, the vendor would have to recall the devices. As part fo the "End of Life Policy," the vendor should spell out what they will do in this case. For a consumer level device, I would hope for five years of security patches after the sale of a device has stopped by the vendor (no: I am not aware of ANY consumer level vendor doing this. I asked a few, and they essentially told me that the day a device is declared "End of Life," all support stops, and you may see an announcement a few months before the fact).
2 - How will I learn about security updates?
The vendor should provide a method to receive notifications of new updates. I prefer some form of an e-mail message. But a notice in the admin interface of the device will work, or at the very least, a web page that allows me to check what the latest firmware version is of a device.
Ideally, there would be a standard web service, but I haven't seen any proposals for something like that. A simple GET request with the serial number, model number (or MAC address?) that will return the latest version of the firmware for this device would be great.
3 - Can you share a pentest report for your device?
I don't expect all the gory details. But what I want to know: Did you bother with SOME testing... The level of detail you publish, and the firm performing the pentest may be a differentiator that will make me pick you as a vendor. A pentest report may also tell me if you have some form of software security program.
4 - How can I report vulnerabilities?
You may not be the world's best hacker. You may not be even interested in doing a security test on your new routers. But others will, and they need to be able to report these vulnerabilities. A bug bounty is great, but an easy to find web page with instructions on reporting vulnerabilities (including a PGP key) will do.
5 - If you use encryption, then disclose what algorithms you use and how it is implemented
Now we get into more specific issues. But encryption is so often done wrong. What options do you support? Is MD5 the only hashing function you use? You may say "Proprietary" if you don't want to tell me. And I will run to your competitor. Does your SSL library even support TLS 1.2? Or do you think openssl 0.9.6l is fine? The reason I want to know: I want to get some assurance that you considered encryption an important enough issue to document what you are doing and how you are implementing it. You may still get it wrong. But your chances of getting it right increase if you consider it important enough.
So why just ask these five questions? Why not ask more? I consider these the minimum bar every vendor should pass. There is always more that can be done, but these five issues should be "timeless" enough where you do not have to update them every few months. I don't know of any vendor that will answer all 5. You are more likely to get an answer from vendors that focus on enterprise and industrial systems. Don't expect too much from consumer level vendors. But please comment if you know of any vendors that will answer all or some of these questions (if you are a vendor: please let me know).
Application Security: Securing Web Apps, APIs, and Microservices | Online | US Eastern | Jan 27th - Feb 1st 2025 |
Comments
IC
Anonymous
Dec 12th 2016
8 years ago
Anonymous
Dec 12th 2016
8 years ago
Anonymous
Dec 12th 2016
8 years ago
6 - Default credentials? THe correct answer is "NO". You should be forced to change the admin password on first logon, as part of the initial setup. Similarly default service credentials (like WiFi keys) should be set on initial login, with no option to accept a default value.
Anonymous
Dec 13th 2016
8 years ago
6 - Default credentials? THe correct answer is "NO". You should be forced to change the admin password on first logon, as part of the initial setup.[/quote]
I agree. Perhaps the system should generate a pseudorandom password during initial setup to lessen the likelihood the end user picks a poor password.
Anonymous
Dec 13th 2016
8 years ago
I would add to the #2 (security updates) by asking for CPE of the device, and perhaps use it to check the most recent version.
Anonymous
Dec 13th 2016
8 years ago
Anonymous
Dec 20th 2016
8 years ago