5 Questions to Ask your IoT Vendors; But Do Not Expect an Answer.

Published: 2016-12-12
Last Updated: 2016-12-12 02:39:55 UTC
by Johannes Ullrich (Version: 1)
7 comment(s)

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).

Johannes B. Ullrich, Ph.D.

7 comment(s)


IoT vendors = Hanlon's razor.

Call me a Scrooge, but for me, IoT falls into the category of "Just because you can, doesn't mean you should."
Having dealt with too many of these questions about products now, I can tell you I'll put more time and effort into good answers for those questions because they are concise, relevant, and likely to actually be read by the customer. As opposed to 300ish rows of Excel questions where they'll get quick generic answers because 99% of the time, customers don't read them anyways. I know because I'm often in hour long follow up calls which could be summarized as "Read your questionnaire or the documents we sent you to see the answer". I don't but that's a lot of time spent for no value add. That's just their checkbox they need.
2a - Given that most IoT devices are purchased by "just folks" who aren't security experts, shouldn't we expect that these devices auto-update? Devices like Asus routers are headed in the right direction with an "update now" button in the UI, but they most home users are in the UI during initial setup then never again - we should expect these devices to auto update themselves by default.

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.
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.
Great list.

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.
How about "How do I white list your device?" I look for vendors and products that are "White List Ready" so I can secure the devices even if the vendors don't. This includes IP addresses or domain names that the devices access, ports and protocols required, and some description of the expected traffic bandwidth and frequency of connections.

Diary Archives