6 ms·

No vigilante justice required. Just make the companies liable for the damage they cause when their products turn into a botnet. Why can't products have a "decl

by avian 7y ago

No vigilante justice required. Just make the companies liable for the damage they cause when their products turn into a botnet. Why can't products have a "declaration of security", like they have for EMI compatibility, safety standards and other such things? Declare that the manufacturer has taken reasonable steps to make the device secure and is liable for damage if that turns out to be untrue.

kyeb 7y ago
Good luck enforcing something like that.
- avian 7y ago
  Why is enforcing this so much different than enforcing that your cheap Wi-Fi router doesn't interfere with air traffic control radar?
  - Groxx 7y ago
    Because your wifi router is limited to a minuscule physical range. The rest of the world's wifi routers don't continually threaten to interfere with your local air traffic control radar - if they did, we'd probably have much stronger controls around it than we currently have.
  - birdman3131 7y ago
    It is a prove a negative vs prove a positive. "This device cannot broadcast with enough power to interfere with radar" is provable. "This device has no security holes" is often not provable even if they try to secure it.
    - yetihehe 7y ago
      "This device uses [x,y,z] techniques for avoiding [interference/hacking]" is provable. List of required techniques should be known in advance (like ["no default password", "no raw tcp password sending", ...]). I have seen such requirements when delivering devices for some big companies which care about security of devices reselled by them, I think it was even some publicly defined standard, but can't find it now. Such things exist already, but are just not enforced like interference requirements.
    - okmokmz 7y ago
      >It is a prove a negative vs prove a positive No, it isn't >"This device has no security holes" is often not provable even if they try to secure it. That's not how security compliance is determined Just as is done with HIPAA compliance, NIST compliance, etc. there would be a framework of security controls that need to be adhered to
  - mullen 7y ago
    Because if you screw with ATC radar, people with the force of law will kick down your door and take your equipment. The FCC and FAA won't tolerate ATC radar being screwed with, no one cares about IoT hardware until it stops working.
TeMPOraL 7y ago
> No vigilante justice required. Just make the companies liable for the damage they cause when their products turn into a botnet. The hope would be that the former leads to the latter. "Making companies liable for doing a shoddy job" is rarely a thing that happens on its own, without pressure from below that's usually a reaction to incidents that hurt people.
jon-wood 7y ago
We're moving in that direction in the UK. There's no legislation around it yet, but the government recently published the snappily named Code of Practice for Consumer IoT Security[1], which if rumours I've heard are correct they've basically published saying manufacturers can either voluntarily comply, or they can deal with it become legislation in the future. When I first heard about it I was pretty dubious given government's track record on regulating technology, but its actually a really solid document, covering 13 guidelines which are specific enough to be useful, while not going deep into technical detail which will go out of date: 1. No default passwords 2. Implement a vulnerability disclosure policy 3. Keep software updated 4. Securely store credentials and security-sensitive data 5. Communicate securely 6. Minimise exposed attack surfaces 7. Ensure software integrity (this is probably my least favourite guideline, as it basically says you should check signatures on all firmware, by extension shutting down people's ability to control their own hardware with custom firmware) 8. Ensure that personal data is protected 9. Make systems resilient to outages 10. Monitor system telemetry data 11. Make it easy for consumers to delete personal data 12. Make installation and maintenance of devices easy 13. Validate input data [1] (PDF) https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/773867/Code_of_Practice_for_Consumer_IoT_Security_October_2018.pdf https://assets.publishing.service.gov.uk/government/uploads/...
- TeMPOraL 7y ago
  Oh yes. I'd push back hard on 7. Otherwise, it's a really solid list of guidelines and I love it. WRT. 7, forcing secure boot is an overkill and pretty anticonsumer, IMO. There really needs to be a provision allowing for user-initiated software changes. If you're from UK, please let them know via e-mail to: securebydesign@culture.gov.uk. I was worried about 10 (I don't really like the vendor collecting any telemetry on my IoT devices), but the actual document is more reasonable than the headline makes it sound - it's "if you're collecting telemetry - and keep in mind point 8 - then monitor it for security anomalies".
  - TeMPOraL 7y ago
    Past my edit window. I sent them the following e-mail: Hello, I recently discovered your Code of Practice for Consumer IoT Security. After reading through the entire PDF, I'd like to commend you. It's a great document, and a great initiative - nicely striding the line of being specific enough to make a difference, while not constraining manufacturers and service providers too much in technology and business model choices. It's great that such a good document is taking lead on this issue. That said, I'd like to strongly object to the point 7, "Ensure software integrity", in its current form. I strongly believe this would have a negative impact on both consumers and IoT security. As a tinkerer (or "maker") and a leader in a community of tinkerers, I value the right and ability to flash alternative software on devices I own; software both made by myself and sourced from the world of Free/Open Source developers. It's what enables people like me to derive more value from our purchases, to innovate by experimenting with them, and most importantly - to help our families, friends and random strangers with less interest in technological minutea to derive more value from their own devices, including extending their usable lifetime way past the end of manufacturer's support. Secure boot would prevent all of that, by removing the ability of end-users to modify software on devices they own. This goes against both the interests of end-users, IoT security and society at large for many reasons, including the following: - Software provided on IoT devices is typically closed-source. Homegrown/community software is almost universally open-source, which means many more skilled professionals took a look at the code to ensure it is secure against attacks and does not secretly siphon off data, personal or otherwise. - The ability to flash your own software means the IoT device lifetime is no longer determined by the lifetime of its manufacturers. When the original vendor decides to EOL the device, the community of users can still continue to provide timely security updates and feature improvements. - Extending the lifetime of devices through the ability to install custom software also means the devices take longer before they end up on a landfill, thus reducing their environmental impact. I kindly ask you to please reconsider the point 7 of your document. While its intentions are noble, its particular form is, in my opinion, counterproductive to the overall goals of the document. Please help create a future in which companies minding their users' interests can thrive, in symbiosis with a healthy community of tinkerers. Regards, Jacek Złydach
bifrost 7y ago
Because you can't guarantee that Linux won't be a cesspool of terribleness.
boomlinde 7y ago
> No vigilante justice required. Just make the companies liable for the damage they cause when their products turn into a botnet. No airplanes required. Just make flying cars.
tremon 7y ago
The problem is, most consumers won't know if their "smart" lights are causing havoc somewhere across the Internet. If you brick the device, the consumer will notice their device stopped working, and will (hopefully) start claiming warranty. Without end-user pushback, secure IoT will remain a pipe dream.
ac29 7y ago
> Why can't products have a "declaration of security", like they have for EMI compatibility, safety standards and other such things? Because its a moving target. A light switch that isn't going to burn my house down when I buy it will still be safe in 10 or 20 years. A "secure" piece of software of even minimal complexity almost certainly has many severe bugs yet to be discovered. I worry that the effect of legislation like this would mean you could no longer buy a $25 router to hack around with or put OpenWRT on - the legal liability would make such products non-viable, leaving only expensive enterprise grade stuff for purchase. Maybe that's for the greater good in the long run, but it would still be something of a loss.

by avian 7y ago

kyeb 7y ago

Good luck enforcing something like that.

avian 7y ago
Why is enforcing this so much different than enforcing that your cheap Wi-Fi router doesn't interfere with air traffic control radar?
- Groxx 7y ago
  Because your wifi router is limited to a minuscule physical range. The rest of the world's wifi routers don't continually threaten to interfere with your local air traffic control radar - if they did, we'd probably have much stronger controls around it than we currently have.
- birdman3131 7y ago
  It is a prove a negative vs prove a positive. "This device cannot broadcast with enough power to interfere with radar" is provable. "This device has no security holes" is often not provable even if they try to secure it.
  - yetihehe 7y ago
    "This device uses [x,y,z] techniques for avoiding [interference/hacking]" is provable. List of required techniques should be known in advance (like ["no default password", "no raw tcp password sending", ...]). I have seen such requirements when delivering devices for some big companies which care about security of devices reselled by them, I think it was even some publicly defined standard, but can't find it now. Such things exist already, but are just not enforced like interference requirements.
  - okmokmz 7y ago
    >It is a prove a negative vs prove a positive No, it isn't >"This device has no security holes" is often not provable even if they try to secure it. That's not how security compliance is determined Just as is done with HIPAA compliance, NIST compliance, etc. there would be a framework of security controls that need to be adhered to
- mullen 7y ago
  Because if you screw with ATC radar, people with the force of law will kick down your door and take your equipment. The FCC and FAA won't tolerate ATC radar being screwed with, no one cares about IoT hardware until it stops working.

TeMPOraL 7y ago

> No vigilante justice required. Just make the companies liable for the damage they cause when their products turn into a botnet. The hope would be that the former leads to the latter. "Making companies liable for doing a shoddy job" is rarely a thing that happens on its own, without pressure from below that's usually a reaction to incidents that hurt people.

jon-wood 7y ago

We're moving in that direction in the UK. There's no legislation around it yet, but the government recently published the snappily named Code of Practice for Consumer IoT Security[1], which if rumours I've heard are correct they've basically published saying manufacturers can either voluntarily comply, or they can deal with it become legislation in the future. When I first heard about it I was pretty dubious given government's track record on regulating technology, but its actually a really solid document, covering 13 guidelines which are specific enough to be useful, while not going deep into technical detail which will go out of date: 1. No default passwords 2. Implement a vulnerability disclosure policy 3. Keep software updated 4. Securely store credentials and security-sensitive data 5. Communicate securely 6. Minimise exposed attack surfaces 7. Ensure software integrity (this is probably my least favourite guideline, as it basically says you should check signatures on all firmware, by extension shutting down people's ability to control their own hardware with custom firmware) 8. Ensure that personal data is protected 9. Make systems resilient to outages 10. Monitor system telemetry data 11. Make it easy for consumers to delete personal data 12. Make installation and maintenance of devices easy 13. Validate input data [1] (PDF) https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/773867/Code_of_Practice_for_Consumer_IoT_Security_October_2018.pdf https://assets.publishing.service.gov.uk/government/uploads/...

TeMPOraL 7y ago
Oh yes. I'd push back hard on 7. Otherwise, it's a really solid list of guidelines and I love it. WRT. 7, forcing secure boot is an overkill and pretty anticonsumer, IMO. There really needs to be a provision allowing for user-initiated software changes. If you're from UK, please let them know via e-mail to: securebydesign@culture.gov.uk. I was worried about 10 (I don't really like the vendor collecting any telemetry on my IoT devices), but the actual document is more reasonable than the headline makes it sound - it's "if you're collecting telemetry - and keep in mind point 8 - then monitor it for security anomalies".
- TeMPOraL 7y ago
  Past my edit window. I sent them the following e-mail: Hello, I recently discovered your Code of Practice for Consumer IoT Security. After reading through the entire PDF, I'd like to commend you. It's a great document, and a great initiative - nicely striding the line of being specific enough to make a difference, while not constraining manufacturers and service providers too much in technology and business model choices. It's great that such a good document is taking lead on this issue. That said, I'd like to strongly object to the point 7, "Ensure software integrity", in its current form. I strongly believe this would have a negative impact on both consumers and IoT security. As a tinkerer (or "maker") and a leader in a community of tinkerers, I value the right and ability to flash alternative software on devices I own; software both made by myself and sourced from the world of Free/Open Source developers. It's what enables people like me to derive more value from our purchases, to innovate by experimenting with them, and most importantly - to help our families, friends and random strangers with less interest in technological minutea to derive more value from their own devices, including extending their usable lifetime way past the end of manufacturer's support. Secure boot would prevent all of that, by removing the ability of end-users to modify software on devices they own. This goes against both the interests of end-users, IoT security and society at large for many reasons, including the following: - Software provided on IoT devices is typically closed-source. Homegrown/community software is almost universally open-source, which means many more skilled professionals took a look at the code to ensure it is secure against attacks and does not secretly siphon off data, personal or otherwise. - The ability to flash your own software means the IoT device lifetime is no longer determined by the lifetime of its manufacturers. When the original vendor decides to EOL the device, the community of users can still continue to provide timely security updates and feature improvements. - Extending the lifetime of devices through the ability to install custom software also means the devices take longer before they end up on a landfill, thus reducing their environmental impact. I kindly ask you to please reconsider the point 7 of your document. While its intentions are noble, its particular form is, in my opinion, counterproductive to the overall goals of the document. Please help create a future in which companies minding their users' interests can thrive, in symbiosis with a healthy community of tinkerers. Regards, Jacek Złydach

bifrost 7y ago

Because you can't guarantee that Linux won't be a cesspool of terribleness.

boomlinde 7y ago

> No vigilante justice required. Just make the companies liable for the damage they cause when their products turn into a botnet. No airplanes required. Just make flying cars.

tremon 7y ago

The problem is, most consumers won't know if their "smart" lights are causing havoc somewhere across the Internet. If you brick the device, the consumer will notice their device stopped working, and will (hopefully) start claiming warranty. Without end-user pushback, secure IoT will remain a pipe dream.

ac29 7y ago

> Why can't products have a "declaration of security", like they have for EMI compatibility, safety standards and other such things? Because its a moving target. A light switch that isn't going to burn my house down when I buy it will still be safe in 10 or 20 years. A "secure" piece of software of even minimal complexity almost certainly has many severe bugs yet to be discovered. I worry that the effect of legislation like this would mean you could no longer buy a $25 router to hack around with or put OpenWRT on - the legal liability would make such products non-viable, leaving only expensive enterprise grade stuff for purchase. Maybe that's for the greater good in the long run, but it would still be something of a loss.