A durable IoT device could last decades, but few companies building these products will survive as long as the devices, let alone support a device they are no longer profiting from. As long as they are supporting the device with security updates, it's fine for the firmware to be proprietary. But, when they decide to cut support for the device, they should be willing to ensure that consumers who have purchased this hardware and are still using it won't become victims, and that the overall Internet community won't end up harboring botnets made of living dead ewaste.
Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
321–330 of 944 posts
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#322For Seam, we purchase, set up, and test many individual devices and systems in our lab in San Francisco. During the course of this work, we discover quite a few interesting things. When possible, we work directly with manufacturers on addressing the more concerning problems we find. We maintain an internal device database (partially available here https://www.seam.co/supported-devices-and-systems) where we keep track of our findings on devices we test & integrate. One area that I haven't seen addressed here is data-storage jurisdiction. imho, that might be one of the more concerning aspect.
happy to have a chat; my seam email is in my hn profile.
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#323With all due respect, I think the market should address this. Like UL Approval from Underwriters Laboratories, players in the market can submit their products to an organization that vets their security and sets standards about updates, product lifetimes, security incident response time commitments etc to obtain their seal of approval. Perhaps the seal has grade levels to indicate the vendor's commitment to security.…
I don't see any particular entity benefiting from security labels - it's a problem of the "commons" where you generally need government intervention of some sort of.
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#324How about requiring devices to accept alternate, Free Software firmware, from the upstream provider? At the very least, it should be possible after some time period of no updates or insecurity, but a blanket requirement is less susceptible to games. Probably the best thing to happen to wireless routers is OpenWRT and the other descendents of the WRT firmware.
As far as I remember FCC about 8 years ago didn't liked OpenWRT, and even enforced on TP Link to lock it.
http://www.taht.net/~d/fcc_saner_software_practices.pdf
Substitute IoT for router in everything we wrote there on page 12-13 and that seems to be a starting point everyone around here has come to think is necessary. I would prefer not to summarize such a large filing here.
Also Dan Geer wrote extensively on these topics at the time.
Of late I have been strongly suggesting that software be at least "built in america": https://blog.cerowrt.org/post/an_upgrade_in_place/
I care most deeply first - that the front doors to our houses, the home gateways, are properly secured, kept up to date, and have ipv6 and bufferbloat fixes on them.
IoT devices belong on their own vlan...
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#325Someone I know wrote an interesting opinion piece on this [1], which might be relevant to this discussion.
[1] https://bits-chips.nl/artikel/iot-we-need-to-get-a-grip-on-t...
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#326Earlier quoted context omitted.
Liability. Make the manufacturer liable if a known vulnerability is exploited.
I would think that tort law already achieves this - unless some law was passed that shields manufacturers from lawsuits. If that's the case, then the easy fix is removal of such shields instead of trying to create new regulations. Same applies to nearly all aspects of product liability.
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#327One thing that regulators need to be very careful about is how "security updates" are defined, and exactly what manufacturer obligations for issuing security updates should be. CVEs are a notoriously terrible representation of actual security risks, so a measure like "manufacturer must issue new releases that include any released patches for CVEs with a severity rating greater than 9" would be a clear non-starter. Th…
> There are also often practical issues related to security patching embedded devices: for example, a downstream supplier's driver can make it impossible to upgrade a kernel unless/until the supplier provides a fix. Of course, strong regulation here could help to drive bad practices like that out of the industry, but I'm not going to hold my breath on that one. The effect of regulation like this would make it harder…
I suspect not, so why not because the car is more expensive?
I would argue that the purpose of regulation is exactly to root out this sort of practice. If it was cheap and effortless to do this we likely wouldn't need regulation.
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#328Earlier quoted context omitted.
IIRC the main objection was that it could be used to do something with the radio (boost power?) that caused the device to exceed FCC limits for a consumer radio? Something along those lines?
For those out of the loop these documents have a good introduction to how free software interacts with radio regulations https://wireless.wiki.kernel.org/en/developers/regulatory/st... https://wireless.wiki.kernel.org/en/developers/regulatory TLDR manufacturers and "serious" companies won't touch anything that could potentially be configured to emit signals that your local government doesn't like. So Linux has to pre…
https://www.computerworld.com/article/2993112/vint-cerf-and-...
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#329Earlier quoted context omitted.
That's a great question. Devices that emit RF could be hijacked and turned into signal jammers. With smart jamming attacks, even low-power transmitters could potentially cause serious harmful interference to other devices. Botnets of compromised devices could be especially damaging. Since vulnerabilities are often chained by attackers, sometimes in very unexpected ways, to accomplish their final goal, we think that t…
Has there ever been an example of a consumer RF emitter being remotely hacked and turned into a jammer?
Re: Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
#330Tbh, I think this will add unnnecessary regulatory burden for start-up companies. Take for example general IoT cloud connected equipment: it will get security upgrades more often than one that is completely offline. That was a big selling point of the Meraki cloud offering that is now part of Cisco. There would be millions of unpatched networking equipment, but Meraki could force upgrades onto networks without them m…