Ask HN: I’m an FCC Commissioner proposing regulation of IoT security updates
As you know, serious vulnerabilities are common in IoT, and it often takes too long for these to be patched on end-user devices—if the manufacturer even bothers to release an update, and if the device was even designed to receive them. Companies may stop supporting a device well before consumers have stopped using it. The support period is often not communicated at the time of sale. And sometimes the end of support is not even announced, leaving even informed users unsure whether their devices are still safe.
I’ve advocated for the FCC to require device manufacturers to support their devices with security updates for a reasonable amount of time [1]. I can't bring such a proposal to a vote since I’m not the chairman of the agency. But I was able to convince my colleagues to tentatively support something a little more moderate addressing this problem.
The FCC recently issued a Notice of Proposed Rulemaking [2] for a cybersecurity labeling program for connected devices. If they meet certain criteria for the security of their product, manufacturers can put an FCC cybersecurity label on it. I fought hard for one of these criteria to be the disclosure of how long the product will receive security updates. I hope that, besides arming consumers with better information, the commitments on this label (including the support period) will be legally enforceable in contract and tort lawsuits and under other laws. You can see my full statement here [3].
But it’s too early to declare victory. Many manufacturers oppose making any commitments about security updates, even voluntary ones. These manufacturers are heavily engaged at the FCC and represented by sophisticated regulatory lawyers. The FCC and White House are not likely to take a strong stand if they only hear the device manufacturer's side of the story.
In short, they need to hear from you. You have experienced insecure protocols, exposed private keys, and other atrocious security. You have seen these problems persist despite ample warning. People ask, ‘why aren’t there rules about these things?’ This is your chance to get on the record and tell us what you think the rules should be. If infosec doesn’t make this an issue, the general public will continue falsely assuming that everything is fine. But if you get on the record and the government fails to act, the evidence of this failure will be all over the Internet forever.
If you want to influence the process, you have until September 25th, 2023 (midnight ET) to file comments in the rulemaking proceeding.[4] Filing is easy: go to https://www.fcc.gov/ecfs/search/docket-detail/23-239 and click to file either an ‘express’ comment (type into a textbox) or a ‘standard’ comment (upload a PDF). Either way, the FCC is required to consider your arguments. 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.
I’m here to listen and learn. AMA. Feel free to ask any questions about this or related issues, and I’ll answer as many as I can. I just ask that we try to stay on the topic of security. My legal advisor, Marco Peraza, a security-focused software engineer turned cybersecurity lawyer, will be answering questions too. I’m open to incorporating your ideas (and even being convinced I’m wrong), and I hope that my colleagues at the FCC are as well. Thank you!
Edit: The Q&A is over now, but please keep this great disc...
942 comments
[ 2.5 ms ] story [ 370 ms ] threadWhen 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.
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.
Fly-by-night foreign manufacturers or exporters would be difficult to prosecute. Unless the domestic importer, reseller, or transportation provider can be held liable, even class action lacks teeth.
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.
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.
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.
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 pretend it doesn't allow to do that (even though anyone with 2 braincells can patch it)
https://www.computerworld.com/article/2993112/vint-cerf-and-...
As many modifications would void the FCC certifications of the device, due to changed parameters (more power, disabled anti-interface mitigations, out-of-band channels, etc.). This was avoided by making the radio firmware separate blobs, but there was a real danger of the whole device having to have signed firmware.
These days this seems to be mostly done in wifi chip firmware (that is then signed and under lock and wrap to make it tamper proof), but back in the day it was too easy to circumvent the mechanism.
The requirement was that consumer radio transmitters could be too easily made to use frequencies and power levels that violate FCC regulations.
If a device had a transmitter where firmware could control those things, and the firmware for the device was one blob that contained everything so letting the user replace firmware meant letting the user control those restricted parameters, then the manufacturer might have to lock the firmware.
There were other possible approaches. One would be to split the firmware into two parts. One part for the radio hardware and the other for everything else. Make it so the firmware update process only allows the manufacturer to supply the first part.
The prevention all comes down to enforcement though, the law doesn't physically stop you from making a device it just means you could get in trouble for intentionally ignoring it and selling a lot of those devices.
I'm not claiming it wouldn't be an overall social good, but other areas of law and regulation don't seem to function like this (with notable exceptions like photocopying banknotes).
That is to say, it's infeasible the average someone will make a working Wi-Fi radio which uses the Japanese channel 14 (involves changing what is sent by the radio, not just raising the frequency... unless you want to accurately re-adjust the frequency inside of your smartphone too) but it is reasonable to expect the average someone might just load some open firmware from the internet which allows them to set the channel to 14.
I will say I agree it's different than a lot of regulation. On the other thing I think that has more to do with radio space itself being very different than most things (i.e. a shared public resource) than inconsistency.
I suppose you could call that accidental radio pollution, because most of the people doing it probably didn't realize that they were causing interference, but regardless it was becoming a problem.
Hence regulations to address it.
That's the world we're in now. You have a problem, you do a search online for help, and among the answers you often will find some that really should only be used by people with more experience or expertise than you but do not make that clear.
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...
Security policy is needed that accounts for the behaviors of the vast majority of users.
Apart from printers and smart TVs, less than half of US households have any of those other devices.
https://www.statista.com/statistics/1124290/smart-home-devic...
Anecdotally, most people I know who own those devices are the more technically inclined. Especially the thermostats and light bulbs. Even the doorbell surveillance networks have low penetration.
But if the aim is to stop DDOSes from botnets of poorly secured IOT devices, we need something to help the other 99% of the market.
Most folks can't or won't do lots of things in their lives (e.g. plumbing, electrical, construction, lawn services, Automotive).
The main thing blocking routers and IoT devices is the control every vendor wants to hold over their customers' devices after sale.
I'd argue that the main blocker to IoT security is the lack of culpability on the part of device manufacturers. I don't want to go so far as to suggest that companies should be wholly liable for software bugs, but vulnerabilities that are brought to the attention of the company privately or disclosed publicly absolutely should be their responsibility to address.
For you or me (or most of the folks here I suspect) we feel better if we had the ability to decide what software our fridge runs, but for 99% of people they're better off if their fridge's manufacturer provides them with regular security updates for the life of their product.
That being said, these aren't mutually exclusive. In a perfect world we'd have laws compelling fridge companies to allow 3rd party software if they don't keep their firmware up to date.
Even if I don't buy one, I dread to think of what might happen if enough fridges across the world stopped working all at once (demand for non-perishable food and fridges would skyrocket).
For the sake of consumer safety in our imperfect world, there should be a safe-mode hard switch fallback for any life-critical and/or high wattage device that gets networked.
Allowing people to install software on their hardware isn't a cure for vulnerabilities. It's a step in the right direction for sure, but it's a very small one from the perspective of something as huge as "IoT security".
imagine instead that vendors had to acknowlege the structure of their firmware, and make the (usually obvious) hardware interface documented from sale. that would automatically solve the issue of out-of-support(-by-vendor) hw.
Which is to say, you are buying a multi-year lease up front. And the manufacturer should send you a recycling return box.
This is a more honest way to sell these devices.
Consumers that would not care about length of security updates will suddenly very much care how long their “lease” is… and manufacturers would compete on the length of that lease (which is where the FCC could require security updates for the length of the lease period).
https://blog.cerowrt.org/post/an_upgrade_in_place/
Of course, manufacturers don't want that either because they make money off of planned obsolescence and consumers keeping old hardware running makes them less likely to buy old hardware.
I think (and I'm a security know-nothing, so could very well be off in the weeds), the firmware should accept updates signed with two keys. The manufacturer key, which can allow automatic updates, and a post-service key that cannot be automatic. Either a user has to initiate the firmware update manually, or consent via some other means.
This post-service firmware may very well enable a third key for automatic updates of its own, so there's just a manual step on the transition from manufacturer to some community project you support, not each revision afterwards.
Ideally, the key would also be pre-registered somewhere to ensure they can't skip out on releasing it, but I'm not sure how you do that without it potentially leaking before the device reaches end of support. I guess a code sitting in a lawyer's vault somewhere. Again, nobody is paying the lawyer to refresh his vault's firmware image after each patch, so 2nd key wins over unlock firmware again.
Why a lawyer's vault? I know lots of people would love to take ownership of the device immediately, but from the device creator's perspective, they tend not to like that... especially if a device is a source of subscription revenue. So I'm not sure how you'd get vendor buy in to early release unless it becomes mandatory... which I can't see.
In general even if I like open devices and having the option to use my own software, this is not a solution for most of the consumers.
It is not a solution even for the enthusiast that know how to flash their own firmware. Because even if they may do it a few times initially, eventually they stop doing it.
You need a system that can update automatically even when you are busy in another project.
there are a lot of open and closed firmware projects building upon openwrt
That's more than a reach of a claim. All manufacturer firmware are buggy with poor security? That's very obviously false. With closed manufacturers the history is that it's a mixed bag, not a blanket. Some are excellent, some are very poor.
Openwrt has been mediocre and all the negatives about it do not equally apply to all closed manufacturer firmware.
guess we have a difference of opinion then
If a firmware update on my smart watch bricks it, who cares? But if my entire house/office is without internet connection because of a bug in the router update, then I don't want to waste time determining if its my ISP, my physical connection, my local hardware, or the firmware update that just occurred silently. I want to send the "update" command, note that network response did not resume within 5 minutes, and revert from there.
A lot of folks tend to think of firmware updates as identical in complexity and risk to any other software update. I submit that if it can't go wrong in such a way that it requires an in-system-programmer to fix, its a software update, not a firmware update.
In that sense, I think true firmware updates (e.g. BIOS updates and the like) require a different set of regulations than your standard IoT security updates.
• It happens, especially if the update has been a "quick fix" to a security issue, that the update introduces unexpected behaviours, or incompatibilities. Supposing this was just a "security-only" update that doesn't change any features, I would approve it, and then discover it breaks something in my installation (e.g., compatibility with a specific device or software I'm using). In that case, I need to be able to rollback the update and run the previous firmware version (possibly mitigating the security issue in another way, if it's properly documented) to avoid serious issues that, depending on the device, might prevent important equipment from being operated.
• For firmware updates that include more than security fixed, approval and the possibility of rolling back is even more important. It's quite common that updates remove seldom-used features a minority of users depend on. It even happens that some features get removed and replaced by subscription-only services, which is even worse.
There's this level of management at the google/amazom/apple level, and in some cases google even lets me push firmware updates (sennheiser ambeo is an example), BUT there should be a requirement that security settings in firmware be exposed in a way that they can be manipulated in a rolled up dashboard. I shouldn't have to depend on a first party app to stay maintained to get to the settings for a device.
As others have stated, free software is one way of giving the public ability to keep things up to date but that's almost like the government saying people are allowed to clean up pollution. It doesn't put any pressure on companies to behave better.
Another issue is build-ability of open source code. If an OEM submits firmware source and keys to a third party, even regularly, who really knows whether it is actually functional and complete. Automated tests or sample hardware are possible ideas but have their own failure modes and could be difficult for to implement solely for this purpose.
Another weird idea for the above. If one requirement was deterministic builds, then in addition to source/keys, a suitable toolchain to build could also be required such that the repository stewards would only need to run exactly what the OEM provides, and if the checksums don't match then it means they are not in compliance.
These days, with nationalism and populism rampant across the world, I think we need a solution where no one country (or country's leader) can simply decide to turn off critical infrastructure for the rest of the world and/or hold the rest of the world to ransom. Then you run into questions of "do we really want (insert bad country) to be able to expose IOT source code to their evil hackers?".
This is a really difficult problem to solve, but ultimately I think ownership of the "keys" to unlock escrowed code needs to reside with (winging it here...) a body such as IEEE or ISO. Or possibly something like a global council where e.g. any 5 countries out of 7 can collaborate via a sharing of keys to release source code, but no one country is able to do so.
Could have the code run in a sandbox where people can apply “external” network traffic trying to hack it (or apply vulnerabilities), inspired by how you can run ML models on kaggle.org on Kaggle servers to validate models.
Have end-points as honney-pots, so if you can access these endpoint you prove you have compromised the code.
If there is no new code with patches the keys are released.
This way FCC/gov don’t need to maintain a technical system. Just build this once.
Verification that it is, in fact, the actual shipped source might not be trivial either.
[1] This discussion is about a federal agency providing certification of products essentially in the form of a stamp (on a device, website, etc.). Nothing is stopping a vendor from committing to and offering the same thing but without government involvement. This could easily be a selling point for the paranoid. Something something blockchain and smart contracts...
[2] Even though we're discussing IoT devices, it's not necessary that they be capable of updating over the air 24/7. Creative engineers could probably devise a method to prevent complete remote takeover by anyone holding the keys– physical switches, additional authentication required during the support period, etc.
[3] Personally, I think the federal government getting access to keys for any IoT device made/sold in the US is the only part of this idea that could already be happening. They can knock on doors or mail subpoenas, plant moles, etc. I would be much more comfortable with a technical solution on the physical device than any presumption of privacy in the current state.
Either the escrow would have to apply to all software on the device, regardless of whether owned by the OEM or third parties, or OEMs would be required to vouch for all the included software.
I'd prefer the former myself: multiple software and patent assets can be combined, but on support EOL, all those become public domain.
Build / release / update toolchains must also be included.
However, it's very hard to police: what if the company only provides a header file or so? Or the basic OS but not the UI?
Moreover, what counts as "support"? There have been cases where companies refuse to consider remote code execution a "security issue". What's to prevent token updates that let the company claim a product is supported while it's riddled with holes?
I could also see companies fighting teeth and nails against this if their devices share a common software base. But hey, you have your support incentive right there!
Furthermore, if the concern is national security, then I think some of the onus should be on the corporate consumers of such devices. Holding them responsible for doing due diligence on their vendors seems easier to regulate and enforce than trying to regulate supply side.
Of course, this leaves the general population without a clear solution to updates if the process of updating using alternate channels has any amount of friction whatsoever. I'm clueless as to what to do about that. Regulating it entrenches established companies. Not regulating it maintains the status quo.
Anecdotally, it feels like software has gotten far more secure in the past decade without regulation but security theater and concerns around national security have grown considerably faster. This isn't easy to measure of course, but that's how I see it.
[1] https://tasmota.github.io/docs/
The idea of a random human being forced to keep writing software via the threat of being sued is incompatible with human freedom and in that context would be far worse than the problem it "fixes".
Please let customers opt out of your proposed protection, if they want to.
(And it sounds like that's already the status quo. So perhaps you could use your time to figure out where you can cut obsolete and cumbersome regulations instead of adding more mandatory bureaucracy that customers evidently don't want enough to pay for voluntarily?)
There might be an argument to be made about negative externalities. The economic standard answer is either let the Coase Theorem sort it out, or to tax the externalities. Not to ban what you don't like.
https://en.wikipedia.org/wiki/Coase_theorem
OP is. Or rather, he wants to make it impossible to opt out. At least that's how I interpret these two paragraphs:
> The FCC recently issued a Notice of Proposed Rulemaking [2] for a cybersecurity labeling program for connected devices. If they meet certain criteria for the security of their product, manufacturers can put an FCC cybersecurity label on it. I fought hard for one of these criteria to be the disclosure of how long the product will receive security updates. I hope that, besides arming consumers with better information, the commitments on this label (including the support period) will be legally enforceable in contract and tort lawsuits and under other laws. You can see my full statement here [3].
> But it’s too early to declare victory. Many manufacturers oppose making any commitments about security updates, even voluntary ones. These manufacturers are heavily engaged at the FCC and represented by sophisticated regulatory lawyers. The FCC and White House are not likely to take a strong stand if they only hear the device manufacturer's side of the story.
If they meet certain criteria for the security of their product, manufacturers can put an FCC cybersecurity label on it.
So if they don't, they can't put the label. That's all.
But you are saying already that manufacturers don't really want to commit to anything? What makes you think the sticker would change that?
(In principle, I'm all for manufacturers offering more warranties. But when it comes to spending money, privately I almost never opt for the enterprise grad hardware that does come with warranties like long term guaranteed support.
Instead I rely on reputation, eg that Google will keep providing security updates for their Pixel phones for a few years as they have done in the past, even if there's no legal obligation for them.
And I wouldn't want any regulation to take that choice away from me. I'm glad to have escaped the EU where appliances are more expensive, partially because manufacturers are forced to include a two year warranty with each device.)
It's a pretty reasonable first step. No manufacturer is being punished, there's no warranty requirement, and the gov isn't taking away choice. Instead the FCC gives manufacturers a way to reliably signal to consumers that their product meets a security standard. Google can do that because they're Google and have a reputation - this approach would let joe-schmo IOT device manufacturer do the same.
But that kind of reputation borrowing/lending already regularly happens with private entities. Both companies and foundations etc.
If customers want it, there is a way: use contract law to commit the manufacturer.
That's already the norm for enterprise grade equipment. Companies often pay more for their hardware to get guaranteed long term support.
So the market is willing and able to provide this kind of service, when people vote with their wallets.
> The free market hasn’t figured it out, as evidenced by the decade of half-working devices consumers are left with.
The free market hasn't provided me with a flying car either. But that doesn't mean the market has failed. And I don't think using bureaucracy to ban any company that doesn't want to sell me a flying car would be an improvement on the status quo.
(To be more explicit: many people, including me, think a flying car would be fun. But we don't want it badly enough to be willing to pay what it would take. And that's why suppliers only offer normal cars, not the flying kind.)
And I can't buy a phone with the contract terms I want, they simply don't exist and can't exist unless the government forces companies to offer such terms. (They exist if you're buying thousands, maybe, but I just want one for personal use.)
Contract law can't force companies (nor consumers) to enter into contracts they don't want to be in. That's the whole point.
Have a look at eg https://www.apple.com/sg/support/professional/enterprise/ or the equivalent for Dell or Microsoft etc. All those companies already have programs where you can give them money in return for long term support and contractually guaranteed updates etc. I'm sure you can find similar programs for IoT suppliers.
Some people decide to pay for those programmes, many people don't. I don't see why we should force everyone into buying the equivalent of extended warranties, that they evidently don't want. This kind of stuff isn't free for companies to provide, you know.
Give it a try and report back.
That's fine. They have just as much freedom as you do.
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/
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 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.
Lots of people have been bitten by suddenly unsupported devices.
I think it could do some good.
In some sense, cars are better examples for responsible ownership, because almost every state requires you possess insurance to drive it. The price of an insurance premium is (supposed to be) commensurate with the risk of driving it, and insurance premium rates do influence the market for vehicles.
That's fine. But economic theory also gives you standard answers for externalities:
Don't ban the behaviour you dislike. Either let people sort it out themselves (like the Coase Theorem https://en.wikipedia.org/wiki/Coase_theorem describes), or at most tax the offending behaviour.
OP says, amongst other things:
> I’ve advocated for the FCC to require device manufacturers to support their devices with security updates for a reasonable amount of time [1].
So the offending behaviour in this case would be for a manufacturer not to provide security updates.
But it also will be a consumer problem, if they cannot access important services anymore, because their IP has been blacklisted, because their toaster participated in too many DDOS or spam attacks.
While it is unlawful to knowingly or intentionally participate in a DDoS, what I'm talking about is the potential of also "criminalizing" (in the sense of a speeding ticket, not jail time - an infraction, not a misdemeanor or felony) using a vulnerable device that is then hijacked by an attacker.
Like you, I don't think it's a realistic outcome; I'm merely brainstorming how one could make this a consumer problem through economics.
so, labeling requirements are one thing, but requiring that the information is straight forward and leaves no options for misleading would be great. I just don't think there's ever going to be a way from preventing someone from finding loopholes.
https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.02042022-2.... https://www.nist.gov/itl/executive-order-14028-improving-nat...
They're in FN 20 of the linked proposal for rulemaking (which is 48 dense pages and which I don't expect anyone here to have had a chance to read yet.)
If you find yourself skeptical about the NIST proposals, please feel free to comment on the record!
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!
Hmm. In the grocery store, where this idea comes from and has the most persuasive history in govt. regulation, where manufacturers own the front of the package and regulators own the back, what is the healthiest food?
The produce and meat. Which has no nutritional label.
There's no such thing as a secure IoT device. There's absolutely no such thing as a secure connected device that is also cheap.
If you build your computer from commodity parts, it tends to be the longest lasting and most secure. It is usually the most expensive.
Anyway, what would the label for a PlayStation 5 and an iPhone 15 look like? Miles long.
Then, for the consumer buying the cheapest smart plugs off Amazon? Like one paragraph the vendor copied and pasted from the Internet, along with all the other legal shit they deal with.
Whom should be regulated? I guess Amazon and Walmart, the retailers, they are the real gatekeepers. That's what the EU does! Which doesn't fly here. The Waltons live here, not in the EU.
So while the device owner may not be the primary victim, they can definitely still be heavily affected.
Thanks for engaging, where the rubber meets the road!
Hopefully, you are also looking into other venues, as well.
HN has a great group of folks that represent some of the most cutting-edge tech, but IT runs on Java 8[0].
[0] https://news.ycombinator.com/item?id=19877916
https://www.dhs.gov/news/2023/08/11/secretary-mayorkas-deliv...
https://www.politico.com/news/2023/08/11/def-con-hackers-spa...
https://arstechnica.com/information-technology/2023/05/white...
I would suggest to my peers, that the links you gave are "official channels," and are probably what you really want, as opposed to a rather rambling thread of comments.
But for me, you just get a rambling comment.
I made my career on devices. In particular digital scanners and cameras.
I worked for a company that was about as tinfoil as you could get, and they supported devices long past their sell-by date.
But I also know that my company was an outlier. They sold premium equipment, at a premium price. They were an "old-fashioned" Japanese corporation, and had a basic mindset of keeping the customer's workflow in the center of the screen.
I think IoT security is a huge issue, and I think that the solution could be that there are standard, open-source, open-license, free-to-use packages; maybe written in languages like C, that could be offered to the industry. These could enforce low-level compliance with security standards.
Oh, and keep the TLAs out of it. They would really like to put a bit of "extra spice" in something like that.
That said, I know that it will never happen. There's a gazillion issues.
I sort of want both. Official commentary moves the needle, but selfishly, I love the thread comments. People tell you what they really think, and sometimes go into a lot of detail as to why. It's an education for me.
I think IoT security is a huge issue, and I think that the solution could be that there are standard, open-source, open-license, free-to-use packages; maybe written in languages like C, that could be offered to the industry. These could enforce low-level compliance with security standards.
"Universal basic security" would probably be a major field of policy approach if we found ourselves with some huge disaster requiring a regulatory response. It's at least worth thinking about now, even if it goes beyond the scope of what the immediate regs can do.
People like Michal Zalewski, https://twitter.com/lcamtuf, could point you to the best of that.
I think this definition would apply to stuff like phones and cars, right? If so that's great.
I think the broader definition would probably just fall back to the FTC, and as far as consumer protection goes I think they've been asleep at the switch for decades.
Well, I stand by my position that the other is also a problem, but maybe this rulemaking isn't an approach that can cover that.
Don't get me wrong, this is still worth doing...
I guess I am not surprised there are security issues with these devices, because I think of most of them as coming from small companies, and wonder what the impact would be on the IoT space if only large players can work through more regulation.
That said, I can't decide if I am more concerned about my Wyze camera sending data where I don't want it to, than my water heater leaking it's current temperature (implicating whether I am home or not).
Is there any thought given to cloud based devices becoming paperweight when companies behind them just stop supporting it or turn off the API? I'd like some "assurances" in place that if the company either goes out of business or decides to sunset the service, it would be required to open source (or at least make available for download). If memory services, that happened to some Nest models a while back.
I lived in a house that had such secure windows. I even witnessed someone trying and failing to smash a window with a brick.
it seems like a bad analogy on the GP's part
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.
For what it's worth, I'm not disagreeing with your points about needing drastic, systemic improvements in how we handle security.
«A ragtag bunch of amateur hackers, many of them teenagers with little technical training, have been so adept at breaching large targets, including Microsoft, Okta, Nvidia, and Globant, that the federal government is studying their methods to get a better grounding in cybersecurity.»
My opinion is that we fail completely to build secure systems in a forward thinking way and the fact that we manage to stop threat actors that exploit holes that are already known to us is insignificant.
[0]: https://arstechnica.com/security/2023/08/homeland-security-d...
Modern phones and other appliances have (or are) computers to which it is nigh impossible to operate as root. You might say you have to pwn them even if you supposedly own them ;)
That reminds me of:
> With sufficient thrust, pigs fly just fine.
https://www.rfc-editor.org/rfc/rfc1925
Possibly another important would be NHTSA gathers and publishes numbers on accidents. Having some regularly published numbers would certainly shine more light and is probably lowest hurdle to cross from a political standpoint.
In a free society, why would we ask government (lowercase g) for a window certification sticker? Should government also provide condom anti-breakage stickers? If we want this, maybe UL can set the standard and ask for volunteer testers to affirm the condom or window anti-breakage quality.
Or maybe we can put the Bell System back together and let them regulate what devices may connect to the network. That led to expensive monthly handset charges.
The condom comment is absolutely ridiculous because there are loads of regulations regarding condoms from the FDA. Unsurprisingly you aren't allowed to sell condoms that are likely to break.
Reasons I think we might want some government certification that has real teeth include: the freedom to protect and control our own digital data. A statistically high rate of surveillance and cyber crime with no tools to prevent it impedes the very freedom you’re defending. Absolute freedom for all cannot exist. You can’t be free to keep your money & privacy while I’m free to take it. Real certifications with enforcement teeth wouldn’t solve all problems, but it might make an actual dent. It would be nice to have national security and privacy standards, make purchasing decisions easier (actually sane), prevent some of the crime before it happens, and reduce the crime and surveillance that we know exists. That’s just from a consumer point of view. I’m sure there are many many companies and organizations who would love to be able to have some level of trust in their equipment purchasing without expensive vetting (or far more realistically for most orgs, little to no vetting at all, just hope).
Didn’t the government break the Bell system apart in the first place? When did they get back together and upcharge handsets? I don’t know what you’re referring to. Are you saying that what was needed after the Bell breakup is stronger regulatory oversight with bigger teeth?
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.
I think a lot of places got duped into thinking their internet connected stuff was an upgrade but in my opinion it’s a major downgrade. A device should do what other non-IoT devices do without being online, and internet capabilities should only be a value-add. A toaster should make toast without being online.
An insecure e-stationary bike should just become a stationary bike rather than a 100-pound pile of trash.
Thanks!
Another great step would be a guarantee of making the firmware Open Source after no more than a certain amount of time, and having that guarantee known at compile time. Effectively, that means the device will always be supportable.
So, as I work in this space, there needs to be realistic guidelines on this, does a security flaw need to have a CVE ? Do they need to fix every CVE ? What is the timeframe requirement ?
This kind of thing keeps me up at night.
It's not inconceivable that this could be a requirement for getting a label (or some tier of label.) It depends how the advocacy comes out on the record.
Whatever you require them to disclose after X years, it must be escrowed with a trusted third party in advance.
"Smart" commercial office space has a bit of a head start in this area, and the specifiers have now had some time to find their feet.
Some prominent IoT device manufacturers have had written into the specifications for their own buildings that, for example, the end user (read: them) shall be able to manage the certificates on the devices, and so on and so forth.
A couple that come to mind would make for nice blueprints for consumer protections if you can cut through the prescriptive talk about preferred tech.
In which case all information required to create and load custom firmware should be released to the public. This information should be placed in escrow, in case the company ceases to exist. The same rule should apply to backend services, in case of a device being depended on such a service to operate.
> security updates for a reasonable amount of time
Which is 25 year or more for some classes of devices. Phone have already reached a point where they should be required to come with 10 years of security updates. I'd expect light switches to get at the very least 20 years of security updates.
Generally I believe that governments are being WAY to lenient towards manufactures of any type of electronics when it comes to updates. It's bad for security, the environment and the causes consumers to make bad investments. The companies making these devices have long since proven that they DO NOT CARE and shouldn't be trusted to deal with the issues themselves.
No offense intended, but I would be worried about this more than I would be worried about the current state of the IoT world. A blanket requirement would punish hobbyists and small companies prototyping new technologies. But big players could spend relatively minor technical and legal resources for publishing regular "security updates" without trying to find and close the biggest security holes.
I would prefer that FCC works to inform: maintain an up-to-date database of issues (reported by both the manufacturers and by third-parties), impacts and recommended fixes for those that have a fix. My 2c.
The current framework is 100% voluntary for what amounts to a marketing label. There are non-FCC government databases for issue reporting, and a commitment to reporting to such DBs could be part of what earns you a higher label. Would be great to see commentary on this point from the tech public.
How would that help 99.99% of consumers? They are not going to look in databases, understand the issue, and apply fixes.
1. Your argument for why it's under the FCC's jurisdiction doesn't seem all that strong. In your linked speech, you argue it's important because the FCC has the ability to regulate signals interference, and insecure devices could be turned into jammers. Has this ever actually happened? If not, is this not rather a large stretch of the FCC's mandate? Perhaps this sort of effort belongs in a different part of the government, or in an international standards agreement (possibly non-governmental).
2. What's the definition of security you're using? Security problems always exist in the context of a threat model, so having a label would imply standardizing a threat model. For example, smartphone security systems were originally designed to block malware, but over time have been stretched to try and solve often vaguely specified privacy goals towards non-malicious software too. If someone commits to supporting security updates for five or ten years at risk of government censure, then the definition of security is going to become a battlefield because whoever wins gets to control all the software that's got this label.
3. Modern security is layered via defense-in-depth strategies. If there's a bug in an inner layer but it's not exploitable due to mitigations or sandboxes (software firewalls) in outer layers, is that a mandatory security update or not? It could be argued either way because the device is not technically hackable still, simply the armor became weaker. Today this is left to the best judgement of engineers, who must balance efforts to patch theoretical vulns in old devices with work to e.g. build new defenses for newer devices. If it becomes mandatory, then paradoxically, new devices may become less secure than they otherwise could have been because all the effort is going into patching old devices.
4. Imagine a company commits to security updates for all devices for 10 years, but after 5 gets into financial difficulties. Maybe due to competitors who didn't make that expensive commitment. One quick way to dig themselves out of this hole is to push a 'security update' that drastically restricts the device's functionality e.g. prevents it from installing new apps released after a certain date. This can be indeed argued to make the device more secure, and you can argue that there's no expectation that the device will always be able to install new apps anyway, so no end-user expectations or promises have been violated. How would you stop this kind of perverse incentive?
Has that been true in practice? I can think of plenty of horrible products, in IT, on the market. In terms of security (including privacy), the market has done nothing for IT consumers. And what about the people who already bought the lemons, before the market learned of it? Also, what if the lemon doesn't affect me but affects others (such as through DDoS)?
I prefer to keep it as simple as possible, but no simpler.
Security is awful, however, and I don't think that's hyperbole. Almost every consumer I know, including people in IT, have given up on privacy and security (i.e., confidentiality and integrity).
One manufacturer can't force you to buy stuff you don't want, nor ban you from buying from a different manufacturer that does what you want.
(In contrast with the FCC, which has a lot of power over you, by banning you from buying what you want.)
Why would one want specifically to buy a product not conforming to the choice described in the first-level comment?
If it's useful enough, and the existing manufacturers leave significant customer needs unfilled, competing suppliers can step in.
> Why would one want specifically to buy a product not conforming to the choice described in the first-level comment?
All kinds of reasons. It might be cheaper, for example.
"Leaks your personal data to unknown servers" Or "Manufacturer typically does not support their products beyond 2 years after which critical features and functions may stop working"
Less snarky: if other people still want to buy certain products, manufacturers will provide. But that's not a bad thing. Different folks have different preferences.
You are being willfully ignorant of the power dynamics and information disparity that exist between manufacturers and consumers. The whole point of the label is to better inform consumers.
If you are willing to pay, manufacturers are happy to comply with a lot of weird requests.
I like the spirit of this, but one problem with this is that the software stack is likely not FLOSS, and the manufacturers don't own all the software.
A second problem is that lot of the software for production IoT-devices doesn't live in the device.
Third, there are safety concerns with a lot of devices that you'd need legal productions for.
Finally, the best IoT devices use a zero-trust architecture. You'd need to support a variation of this pattern to allow users to modify the devices.
The answer we're probably going to go with is that the device is 'leased' to the customer. It's part of their subscription.
This solves a ton of problems about FLOSS and support of the same. It's now a closed device, and you have no rights to the code inside. If we go out of business, you have a brick that you don't have to pay for anymore.
1000% wrong answer, unless you straight up front sell a service with an installer making a site visit to deploy chattels of service.
such as satellite television, or DSL internet.
when you swap handfulls over the counter before any contractual agreements i.e. clickthrough TOS , you are selling a hardware, that means user ownership.
We do need to establish common sense liability if it's not already there. If you modify your circular saw to remove the guard and injure yourself, that's your fault. If you modify some software to run outside of safe design parameters and it malfunctions/injures you, that's your fault.
I don't see why zero-trust is incompatible with user-modified devices. In fact it's in line with the spirit of zero-trust: don't assume just because something is able to talk to one of your servers (e.g. because it's on your VPN/LAN) that it's friendly. People should already always be assuming customer-owned hardware will potentially be completely controlled by a malicious actor and acting accordingly.
30 years of support expectations immediately makes the cost of any device go up to hedge against the risk of fines during the entire 30 years. It also makes it harder to disrupt an industry with hardware at its core.
I don't have a single computing device that has lasted longer than 10 years. Reasonably speaking, either performance or features start to make the device largely obsolete and unusable.
I think a better way to propose this would be the expectation that when a product is EOL, it should be supportable by the buyer for a certain period. This requires figuring out the right period of support. I'd propose something that scales period based on cost or device class. A $1200 phone should be usable for 10 years while a $10 disposable glucose sensor with a battery should not.
I happen to know, having been with a Ford unit at the time, that the Ford EEC-IV engine control unit in 1980s Ford cars and trucks was designed for a 30 year lifetime. Many are still working.
The average age of light vehicles in the US is 12.2 years.
This is more in NHTSA's wheelhouse, though.
Are you just buying cheap junk? An i7-3770 PC - a good example of an 11 year old PC, and one I happen to use every day - can be quite usable today.
A few additional thoughts:
- Perhaps hardware design/specs should be released as well?
- A government body should probably host this information after EOL.
Additionally, this cannot be an excuse to charge subscriptions or force lease agreements into the fine print for items consumers buy outright.
By volume and impact, what devices have IoT vulnerabilities? If from large mfrs, you might expect some measure of support as that would be somewhat in their best interest, if only to preserve their brand image. My concern would be low quality, usually cheaper, whack-a-mole mfrs that come and go on Amazon, eBay, etc. Even if they release a product that would fall under these guidelines, how are you going to go after a ghost?
Also, what happens when an IoT mfr is acquired, does the acquirer assume all the IoT risks as well?
Great points. From one perspective, we can't afford to do this stuff; from another, we can't afford not to. If connectivity makes your life a little easier for little risk, that's one thing; if your dishwasher steals your identity and sells it online, that's another.
My concern would be low quality, usually cheaper, whack-a-mole mfrs that come and go on Amazon, eBay, etc. Even if they release a product that would fall under these guidelines, how are you going to go after a ghost?
Another great point, but that's a snapshot of the market as it is now. We expect certain standards from some things but not others, depending on how much you depend on them, how much is at risk, and what the costs would be. Right now, under the proposal, a company is 100% free to say "I will support this for 0 days and you expect it to ship broken from the factory" -- it's just that they actually have to say that out loud.
Also, what happens when an IoT mfr is acquired, does the acquirer assume all the IoT risks as well?
I expect this to be a hot topic on the record. We'll see what technologists, manufacturers, consumer advocates, etc. say and try to come up with a proposal addressing stated concerns.
Most other liabilities are inherited during an acquisition. I don't see a good reason for this to be an exception.
It would encourage acquirer's to do much more strict due diligence in this regard, which will have a natural pressure to clean up the behavior of manufacturer's that plan to seek a future exit.
Any exception to liability here seems like a get out of jail free card, for all new manufacturers seeking an exit to behave extremely badly. It also opens the door to corporate shell games, where as soon as a liability is discovered it gets acquired by a thin parent entity to dissolve that liability. I'll leave a comment to that effect as well, but it absolutely seems like this liability should survive an acquisition.
Having worked in the space I came to the conclusion the only viable secure future is to adopt star topology local networks where local traffic for all devices goes into a single secure regularly updated broker device that then decides what to do with it. Any access out to the Internet or between devices needs to be mediated. The part that will annoy a lot of people is that broker device probably needs to be able to read all of it. Therefore rather than just regulation I would talk to the WiFi alliance in particular about possibly expanding the scope of what it means to be a WiFi router.
The problem is actors like Google really want such a thing to be just in the cloud "for convenience", by which they mean monitoring everything that ever happens.
The only corporate actors I encountered that understood this were the Taiwanese OEMs, who are remarkably on point and blunt behind closed doors, but they are basically powerless to do anything about it.
Edit to add: if there is one thing the FCC could do immediately it would be to ban the covert deployment of cellular modems in other devices and to force giant warning labels for such things and require they be user removable.
Fascinating! Could you elaborate?
The absolutely huge thing is they want to live in a world of standard interchangeable pieces. They despise custom solutions to problems unless totally necessary or they are enormously better than the alternatives.
They will flat out tell you that they are essentially waiting for an industry standard solution to problem X to appear, and until it does these ad hoc solutions suck.
If you want IoT security you don’t need to regulate it, you “just” need to create a no-brainer to adopt industry standard model for device operation that these people can drop in place. (I hate MQTT, but think something in that ballpark with the right security model* would be a good starting point). This is a hard enough ask as is, but is made harder by the big software giants all trying to come up with schemes that put them in the middle all the time.
As an aside I also encountered a non Taiwanese executive espousing the view (with respect to slurping up network topologies via multicast) that he hates it, but as long as it isn’t illegal they have to do it. I don’t believe the law would help as you will always have bad actors and people using aliexpress - it needs to be technically impossible, hence the star networks.
Edit to add: * and provisioning process. Were it up to me I'd have something like NFC based key exchange between broker and device during setup as part of the standard.
Yes, yours is (IMHO) the only possible way out, still there are things that simply should be not allowed or be only optional, as I see it the "mistake" is confounding the "Internet" in IoT with the "Cloud".