When it comes to U.S. laws that touch technology, enforceability is a mess. Spyware, spam, fraud, misleading labels, etc. are already governed by various state and federal laws, yet enforcement efforts are whack-a-mole at best.

For IoT devices, having the proposed requirements sounds good in theory but I fear it is practically unenforceable, particularly for consumer-grade devices manufactured overseas.

However, if powerful IoT platforms are also tied into the new regs - with Google, Amazon, Apple, Microsoft, PTC, HPE, etc. required to audit supposedly qualified devices and ban those that don't meet the standards, with escalating penalties for failing to do so - that might shift the needle.

My 2 cents.

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.

That appears to me to be the wrong way to go about this, and it has specifically to do with how IoT security is a problem.

The most severe case of IoT security problems we have seen were things like mass botnets, where plenty of devices of the same type were hacked and then used for things like DoS attacks. Notable cases include the DoS attacks against Brian Krebs for some of his reporting.

The important thing to understand here is that the device owner is not the primary victim. That's a third party.

This is not about consumer choice, because consumers by and large do not care, because they are not the people being affected by this. An optional security label tries to adress it as a consumer choice problem, which it isn't.

This is really meaningful to most of us who see the regulations in our lives as something far away that we can’t influence.

Another reminder for everyone that while you likely can’t influence something like a presidential election on your own, you can influence many other spheres with your knowledge and time that are closer to home and probably affect you more immediately.

[0] https://arstechnica.com/gadgets/2022/11/eufys-no-clouds-came...

The core problem is that without control of the firmware, consumers don't really own these devices. The company can unilaterally decide one day to brick your device and force you to buy a new one. It should be obvious that this behavior is egregiously anti-consumer and anti-competitive.

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 a few billion devices) The Linux and OpenWrt development process continues innovating and is very responsive to bugs and CVEs. It is a constant irritation that many products exist downstream from that that are 5 or more years out of date, and not maintained!

Key bullets from that fcc filing are on page 12-13.

1. software stack – big fat "firmware" should not exist. Entire stack should be upgradable safely, securely and frequently during its official supported lifetime and should be open-sourced for owner's own upgrades past end of life. For this, the hardware stack needs some amount of standards compliance.

2. Vendor should clearly declare/advertise the period for which they will support the device. During this period the device vulnerabilities should make them liable. After this period, they should mandatorily open-source the device drivers and unlock the boot loaders to enable free software alternatives to work on them. For certain class of devices, there should be mandatory minimum period of support.

3. Networking capabilities should be legally standardized and verified/certified before being released to market and checked for continued compliance and fined if out of compliance.

3.1 Use of latest mainstream TLS with valid certificates should be mandated for all communication.

3.2 If there is outbound communication from the device, it should make it clear to which domains it will communicate with so that it is easy to allow only that through firewall and keep everything else locked.

3.3 IoT should not accept inbound communication without authentication.

3.4 Follow best practices w.r.t rollback resistant cryptographically verified secure and brick-safe software upgrades.

FTA:

> I assumed that device manufacturers update the software in their device about every month...he said they do it annually.

Those devices are at least _getting_ updates - there is a long tail of devices whose operational lifecycle [far] exceeds the vendor's support timeframe - in other words, they don't get patches at all N months after release.

The solution to these problems is straightforward - we've been managing it in software for a long time. EOL OSes, Long Term Support (LTS) OS releases, etc - but the device manufacturers are not as mature, and have not been making natural progress to do so.

And since this is HN - there is a startup hidden in the midst of all of this: an enterprise-grade IoT OS that "does security right." Sell to the device manufacturers, allow them to market it as "enterprise-ready" or some such. If the FCC guidelines here are approved, there will be a suddenly increased demand!

How does the FCC define a security flaw? Would updates only be distributed when there is a flaw that needs fixing?

Remote update mechanisms can themselves present security problems in some domains. Thus, some devices should only be updatable if the owner has physical access to the device. Will the manufacturer be liable for damages caused by attacks on vulnerable devices that were not sufficiently updated by their owners?

IoT is making its way into defense and enterprise environments where reliability is a matter of national security. An update nearly always results in some downtime for the device, even if it's just a couple seconds. Sometimes, it may be in the best interest of a device's owner to defer an update indefinitely, until that device's continuous operation is no longer mission-critical. Even if the owner can't control exactly what is in an update, they absolutely MUST be able to control when an update occurs.

If the value of a device is tied to opening a connection to and occasionally retrieving code from a third party it is inherently insecure. All I have to do is buy the company that owns the central server (or compromise it in some other less visible way) and I now have the ability to introduce malicious code to all devices that are receiving 'security updates.' You won't be able to make a rule to prevent asset transfer (correct me if I'm wrong) so you won't be able to close this hole. And this assumes the manufacturer isn't malicious in the first place.

For people to be able to protect themselves and to protect the value of the property they have purchased (e.g. the company tanks and the central service is lost) a rule should exist mandating minimum useful functionality in a disconnected and/or self-managed environment.

As someone who writes software for IoT devices and has worked in the past on security in the IoT space this is sorely needed. By far the biggest issue in my view is that manufacturers are not motivated to take device security seriously since they are largely isolated from any fallout. Device manufacturers already have to pass certification for RF emissions and safety among other things and should have to pass certification for at least a basic security audit on the device and the services the device connects to. Even self-certification would improve the current situation.

For many device types there exists some form of open source OTA update software or a commercial offering. In the last few years there has been significant maturing of the tooling in this space but the security aspect is often left as optional even though the tooling often makes it fairly easy to add. At this point I think the industry just needs a little push to make secure OTA updates the standard.

https://news.ycombinator.com/item?id=37392676&p=2

https://news.ycombinator.com/item?id=37392676&p=3

- It is hard for manufacturers to do this with small teams. Mostly because they do not always have good CI/CD or platforms available to keep being on top of vulnerabilities and so on and so forth.

- Not all manufacturers write their own software and often contract it out to other experts in the field. This includes firmware and app developers.

- If a manufacturer goes out of business or their website is hacked or whatever, the devices are going to send information to someone else, this is a big risk.

- A lot of blast damage can be contained if home devices use local / MDNS based service discovery as opposed to Internet based services. Many services could then either choose to reply locally or sometimes relay to the Internet if users policies allow. Unless people want other people unlocking their doors through the Internet, and they explicitly say it, Internet connection can not be mandated.

- If a producer goes out of business they should be forced to give out a signed firmware that disables the key checking, then they must put up their source code for any users who wish to build and flash it themselves.

- Some of these will not be practical to get manufacturers to agree on. IP issues will arise. Following decent open protocols for firmware upgrade and sharing platform specific specs can alleviate this. One should be able to re implement open firmware for their bulbs if everything else shuts down.

I must say, we see extreme grow of cyber-crime as part of modern war. I think, in nearest future, cold war will guaranteed have huge cyber-crime part.

And, hacking of IoT devices has very significant share of cyber-crime now. For real war it is question of life and death, because hacked devices with radio emission, are used by hostile intelligence, to find targets for attacks of heavy weapon, but also, we seen cyber attacks on electric-energy infrastructure, indented to make blackout (fortunately for us, unsuccessful).

Chinese IoT devices are very special part of question, in many cases are connected to Chinese clouds, and this is also extremely dangerous, not only because potential unfriendly Chinese moves, but also because their security is not good enough, so in many cases, cyber-crime could intercept communications and interfere operation of device or even hijack control.

For example, exists smart door locks with camera and I hear hackers hacked them and used them to observe work of air defense, so enemy could tune their air attacks to make more harm.

In civilian life without war, videos from hacked door locks (or other IoT cameras) could be used for illegal surveillance, to coordinate riots, etc.

- Manufacturer voluntary guarantee of 1/3/5 years security updates with an expiration date.

- Separation of functionality and security updates.

- The ability to "turn off" connectivity and retain full local functionality.

- An industry security certification like UL.

- A single point way of identifying and validating devices.

As it is, I avoid using IoT mostly for security reasons. Having worked in security for many years I have seen the best and the worst. Having security isn't a panacea either - it needs an ongoing management & reporting infrastructure.

Just a reminder: As fun as discussing this in here with you is, the best way to influence what the FCC ends up doing is to file an official comment by September 25th at https://www.fcc.gov/ecfs/search/docket-detail/23-239 . Click to file either an ‘express’ comment (type into a textbox) or a ‘standard’ comment (upload a PDF). The FCC is required to address your arguments when it issues its final rules. All options are on the table, so don’t hold back, but do make your arguments as clear as possible so even lawyers can understand them. If you have a qualification (line of work, special degree, years of experience, etc.) that would bolster the credibility of your official comment, be sure to mention that, but the only necessary qualification is being an interested member of the public.

Finally, I'd like to extend a special thanks to dang and the rest of the HN team for their help putting this together. They have been a pleasure to work with.

Instead of mandatory updates, there are lower hanging fruits you can win, and will have just as much, if not more positive security impact.

1. No default password, one must be set at initial configuration

2. Devices must function without public internet connection (unless it is one of the device's primary function to transmit out)

3. Devices must function without centralized host

4. Explicit disclosure of all "phone home" destination hosts, and ability to change or disable this

5. Explicit disclosure what information is transmitted out, and ability to disable this

I think the above five can be implemented relatively easily, requires no continued maintenance from the manufacturers, and improves the CIA triad of IoTs.

So I'm not sure "escalating penalties" is going to cut it. It's still whack-a-mole. You need a way to kill the mole, not just drive it to pop up a new hole.

You need a way to get to the principals. They're the mole.

You need to either make them personally liable financially, or you need to jail them. Nothing else is going to stop serial fraud-behind-a-shell-company.

I'm not sure I have an answer. But whatever answer there is needs to be applied not only to fraud telemarketers (please), but also to fraud IoT manufacturers/resellers.

Lots of people have been bitten by suddenly unsupported devices.

I think it could do some good.

As such, I look to purchase relativity open devices. But, companies want to keep trying to inject themselves as a middleman, sometimes after the fact. In that case I'm let with a device that becomes e-waste. I don't know what other actions are being taken in regards to subscriptions, but it's a problem here.

[0] https://www.home-assistant.io/

I fear it is practically unenforceable, particularly for consumer-grade devices manufactured overseas

Also a good point. The way we handle this for RF interference is to look at distributors and importers, not just manufacturers, but there will probably always be an untrustworthy product tier out there.

I lived in a house that had such secure windows. I even witnessed someone trying and failing to smash a window with a brick.

And then as a manufacturer you need to pay someone to certify that, or otherwise risk a class action lawsuit?

What about hardware that uses third party software? (Either because it's a genuine third party, eg when you put open source on your router, or because the manufacturer split into two companies to exploit a legal loophole?) Can open source software only make releases that update automatically after getting certified, or risk getting sued otherwise?

That will either make a large part of consumers paranoid or annoyed. So they will replace a TV that is in perfectly working conditions with a new TV.

Samsung, LG and the consumerist economy would love that!

This is absurd.

Even the passive basics like relying on your free email provider's filtering and running Windows Defender is going to stop a huge number of attacks.

If you're expecting perfect security, you'll be disappointed -- but we can't declare complete bankruptcy.

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 devices go out of service, and there's no guarantee that there will be anyone to push one final firmware update or release the source code in the hectic last few days of an imploding business.

Ideally the user should have to specifically consent to inbound communication on an instance-by-instance basis, even from the manufacturer. There's many cases where forced updates are triggered that change/limit functionality unexpectedly. There's numerous anecdotes of people's devices being required to update to be used while they have some pressing need to use it.

What would be meaningful is an assertion that some basic set of secure practices have been or are followed. For example, that there are no default passwords on a device, that security updates will be provided on some defined schedule, that network protocols meet some reasonable standard of security, etc.

> while you likely can’t influence something like a presidential election on your own

In fact, there is almost nothing of significance you can accomplish (or influence) on your own. We always do and always have needed to work together - and the results are astonishing: almost everything that's ever been accomplished.

Agreed. Building an automatic firmware update system from scratch would be burdensome for many IoT makers, but as it becomes necessary or encouraged, we would expect the market to provide a packaged solution/framework that manufacturers could fold into their products. It would be really helpful have to discussion of this on the record. How generalizable do you think such a solution could be? We are aware of the Uptane project, an OTA firmware update framework being jointly worked on by several car manufacturers, but would love to hear more about the feasibility of a solution for IoT devices generally, or particular classes of IoT devices.

This means that someone applying the label without meeting the standards the label indicates would be guilty of exactly the sort of fraudulent advertising you're describing, and contract and tort law are the relevant mechanisms of enforcement for this.

I'm not sure what you mean by enforcement efforts being "whack-a-mole at best", but if you're expecting some sort of preemptive regulatory barrier to be enforced by a bureaucratic agency in advance, that's just not the way this sort of thing works or is intended to work, and the FCC certainly wouldn't have the legal authority to implement such a regime.

Legal actions for fraud, false advertising, trademark infringement (in the case of trademarked standards certification badges, e.g. UL) are frequently used mechanisms for this sort of thing, and seem to work well enough to ensure that vendors are deterred from fraudulently applying certification labels to their products.

I dont want 30 semi/unmaintained apps to manage each manufacturers security settings.