Comment by lacker | Hacker News Reader

Comment by lacker | Hacker News Reader

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

A bigger issue than the available of updates is whether security updates are automatic and mandatory, or optional for the user. If a security update requires some action on the user's part, most users won't want it.

The overall problem is that the main IoT security problem is botnets, not insecure devices per se. A botnet does not affect the owner of a device very much. Thus, the owner of a device usually prefers an insecure device, rather than taking some risk of the security update breaking the device.

I'm not sure what the FCC should do here. It seems reasonable to hold the manufacturers of devices responsible in some way when those devices are used in a botnet, but I'm not sure if that's within the FCC's scope.

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 might reasonably be expected to allow an attacker to take control of a device, or to do so when combined with other known or unknown vulnerabilities. Or maybe a different standard. Then when enforcement/lawsuits come around, the judge/jury/regulator has to evaluate the reasonableness of the manufacturer's actions in light of that standard. We'd love to see commentary on the record as to what the right legal standard might be.

One way to mitigate this is to require introspection into what the update is. This has two implicit requirements which are that the firmware is source-available and has reproducible builds. With those two requirements you would be able to see what is being updated, and prove that the update your device receives is actually the update the manufacturer said they created.

The second requirement is something that is really overlooked in the software supply chain, partly because of the difficulty in achieving it. But it's a goal that the proper push from regulators could help us reach.

A knock on benefit is this helps secure the update channel, which if you are requiring firmware updates you must also require a way to make sure those updates are secure (since it inherently creates more attack surface area)

> This is a general problem for law generally, one that is usually resolved by imposing a reasonableness standard.

Exactly this. Here in the UK we have "merchantable quality" as the standard for the required quality of any goods sold. How "merchantable" is defined is a matter for the courts to decide on a case-by-case basis. In practice, the courts take into account generally market expectations as well as the marketed price to determine the expected quality standard and it seems to work just fine. If my chair falls apart after a few years after ordinary use by ordinary people, then it wasn't of merchantable quality and the seller is in breach of the law.

In the case of security vulnerabilities, I think a similar approach would work well. The key thing is to ensure that sellers of IoT products cannot disclaim responsibility for security vulnerabilities altogether, which is exactly the problem today. If an IoT product can be subverted by an adversary after a few years of ordinary use by ordinary people, then the seller should be in breach of the law.

As a very broad starting point, we should be sure to address the fundamentals of security:

CIA: Confidentiality, Integrity, Availability.

This sounds like a reasonable approach (sorry for the pun). One question - reasonable to whom? (who? - english is my first language sorry).

I ask because when I was doing security research, we'd often present issues and get responses like "but who is going to think of that?" or "No one could find that", only for someone to think of or find it later and take over a system. I still occasionally hear this from software developers (even though the industry as a whole has gotten much better over the years), but quite often from people who work in "cyberphysical" systems (e.g IOT).

Part of the tension seems to come from the fact that some infosec people can be equally unreasonable, declaring something utterly useless if there's a remote theoretical chance of a problem.

Unrelated to the above:

> Maybe here, a vulnerability needs to be patched if it might reasonably be expected to allow an attacker to take control of a device...

I suspect you know this and short-cutted for conversation, or maybe these are all the same legally, but "take control of a device" isn't the only win condition - DOS, info leaks, and so on also exist. I note this because I'm kind of curious if the law considers those the same or vastly different scenarios, and if any sort of FCC regulations would include them.

A cyber vuln is a defect in a product expected to function well. In other domains (cars, apartments, pharmaceuticals), if there is a defect, the manufacturer is responsible to ensure it is fixed.

It seems pretty simple. The standard should be the same as used in other industries where vendors need to recall, repair, or refund products in case of defects.

The irony is that botnets often function as an automatic update: they break in through a vulnerability, often include a patch for said vulnerability, and then stay somewhat updated via their C&C server. Of course, this is all to prevent other botnets from coming in and stealing their devices away.

We had a WiFi camera get compromised. We put it on the internet - so it could get an update - and it got pwned before the update even finished downloading. The malware blocked the admin interface, but kept the camera feed running, presumably to minimize suspicion. As far as we can tell, the actual vuln was patched (some sort of dumb command injection in one of the many exposed endpoints), so there was also no way for us to get back in.

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.

The general rule in tort is that you need physical injury or physical destruction of property to sustain a lawsuit. There's exceptions at the edges of that, but you basically can't sue a device manufacturer for crummy security that caused you to lose money or other non-physical damages like reputational harm. The same limitation does not apply to contract law. We think that a cybersecurity label could be enforceable under contract law, as well as help bolster claims that a duty was breached in tort (when there is physical injury/damage). It would also be subject to FCC enforcement, for failing to live up to the commitments made to get the label.

I would expect some sort of license "agreement" that shields the manufacturer and resellers from all liability.

Not too many industries have such a shield. The nuclear industry comes to mind as an example of one that does.

You could regulate they have to patch any outstanding CVEs for their device/firmware but enforceability might be difficult.

Not all CVE are real vulnerabilities.

This would be an absolutely terrible standard. CVEs really, really suck. See, for example, this CVE for curl[1] that was assigned a 9.8. Or read sqlite's page on CVEs[2]. The sqlite issues alone would make this a non-starter, because you're not gonna convince everyone in every piece of software you use to update their version of sqlite.

[1] https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-eve... [2] https://www.sqlite.org/cves.html

Reply on news.ycombinator.com