301–310 of 944 posts
Earlier quoted context omitted.
It would change, but again -- it wouldn't be appreciable. Security policy is needed that accounts for the behaviors of the vast majority of users.
Users update their phones, there's no reason they can't be educated to update their other devices
One 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…
Thought question (I’m asking, I don’t know the “answer”):
Today, many of these devices are marketed and sold by a company that has little to no involvement in the creation of the firmware or software, besides maybe sending over an image of their logo to be rolled into some turnkey “app.” Would we actually be better off if companies couldn’t really afford to basically dropship some sketchy white-label Chinese product, and instead could only sell a product here if they were confident they (acting alone) would be fully capable of supporting and updating it for a reasonable lifetime? Yes, it would raise the barrier to entry above basically the floor where it is today, but I don’t imagine there is a way to have it both ways.
I always advise my friends and relatives to NOT buy smart appliances. The doom scenario is buying a $20k furnace that becomes useless. Imagine a scenario where you need an app (that's never updated) to adjust your house temperature. Or requiring people run insecure wireless protocols to control it.
Appliances like this need to operate over an open control protocol, where the smart/internet bit is physically replaceable. Dropping $200 every 5-7 years for a new Furnace smart attachment is reasonable price, dropping $20k is not.
Thank you for engaging with the community in this way. Many years ago, in a fight to preserve individuals ability to flash their own routers, Vint Cerf, and I, and a coalition of many others, filed this report: http://www.taht.net/~d/fcc_saner_software_practices.pdf (retaining the ability to reflash our own routers, allowed my research project to continue, and the resulting algorithm, fq_codel (rfc8290), now runs on…
One 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…
Thank you for these thoughtful points. Some relevant responses from other threads: From https://news.ycombinator.com/item?id=37394188 : I think you're right that it would be difficult for the FCC to precisely define exactly when security updates are required. This is a problem in law generally, one that is usually resolved by imposing a reasonableness standard. Maybe here, a vulnerability needs to be patched if it mi…
Thanks!
I think that IOT device manufacturers should be required to support their device for some minimum period of time AND be obligated to release the full source code for the device once they decide to end support. This also requires releasing the keys to any firmware signing mechanism or publishing a firmware update that removes such checks. The core problem is that without control of the firmware, consumers don't really…
There's also the problem that electronic devices last a long time -- often much longer than any manufacturer wants to admit. Vehicles, PCs, printers, and routers can easily last 10 years. Refrigerators and HVAC units can last 20 years or more. And now we're putting "smart" stuff into electric circuits that should last the lifetime of the house. The manufacturer will probably go out of business long before those devic…
There might be a way to integrate these IoT regulations with e-waste regulations, where the liability for disposal, recycling, and cleanup is related to servicability.
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 managing the patching. The result being they would have secure products, and the non-cloud providers would have to rely on their customers to update their phone. The meraki solution was by definition a better upgrade path than the standalone solution. Why would you burden them with regulatory hoops that non-cloud devices do not require?
When you buy an IoT device, you're taking on a risk on anything not open source, and betting that a product/company will succeed. For example, I bought some cube sensors to monitor my home air quality. These sensors are now garbage because they connect to a closed cloud that has been shut down. They don't even function let alone get security upgrades.
If anything, non-cloud connected IoT devices are more likely to cause problems.
Regulation to require a certain period of security updates doesn't seem useful to me. It's very easy to send out a "security update" that doesn't actually improve security. You can send out an ad to all your users saying "You should upgrade now to our newest product!" and call it a security update. Requiring security updates may end up just requiring companies to spam their users with a certain amount of marketing ma…
Liability. Make the manufacturer liable if a known vulnerability is exploited.
With 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.…
All that being said, I have no idea how much manpower or money it would take to do audits at that scale, or even what the scale of IoT Devices vs. Medical Devices is.
With 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.…