3 ms·

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 impro

by lacker 3y ago

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.

asynchronous 3y ago
You could regulate they have to patch any outstanding CVEs for their device/firmware but enforceability might be difficult.
- charcircuit 3y ago
  Not all CVE are real vulnerabilities.
- tkfu 3y ago
  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-everything-that-is-wrong-with-cves/ https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-eve... [2] https://www.sqlite.org/cves.html https://www.sqlite.org/cves.html
MarcoPerazaFCC 3y ago
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.
- duped 3y ago
  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)
- rlpb 3y ago
  > 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.
2OEH8eoCRo0 3y ago
Liability. Make the manufacturer liable if a known vulnerability is exploited.
- intrasight 3y ago
  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.
  - MarcoPerazaFCC 3y ago
    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.
  - RecycledEle 3y ago
    I would expect some sort of license "agreement" that shields the manufacturer and resellers from all liability.
    - intrasight 3y ago
      Not too many industries have such a shield. The nuclear industry comes to mind as an example of one that does.
nneonneo 3y ago
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.

by lacker 3y ago

asynchronous 3y ago

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

charcircuit 3y ago
Not all CVE are real vulnerabilities.
tkfu 3y ago
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-everything-that-is-wrong-with-cves/ https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-eve... [2] https://www.sqlite.org/cves.html https://www.sqlite.org/cves.html

MarcoPerazaFCC 3y ago

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.

duped 3y ago
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)
rlpb 3y ago
> 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.

2OEH8eoCRo0 3y ago

Liability. Make the manufacturer liable if a known vulnerability is exploited.

intrasight 3y ago
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.
- MarcoPerazaFCC 3y ago
  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.
- RecycledEle 3y ago
  I would expect some sort of license "agreement" that shields the manufacturer and resellers from all liability.
  - intrasight 3y ago
    Not too many industries have such a shield. The nuclear industry comes to mind as an example of one that does.

nneonneo 3y ago

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.