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.
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/...
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".
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
More cynicism says that it will require IoT devices to be closed source in order to get a signature, and require government access and audit on running devices (to confirm integrity.) That may secretly be the backdoor clause. I'm probably wrong, but the UK government is fully committed to total surveillance, and the opposition either has no position or tacitly supports it.
If manufacturers would like to add some signature checking chip they can allready do that.
I wouldn't be too cynical, unless they make it illegal to modify the firmware.
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.
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.
No airplanes required. Just make flying cars.
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