Realistically, IoT devices are and will continue to be made by small development teams under considerable time pressure with little motivation to care about security over the life of the product.
One solution to this problem is to institute consumer protection laws that say that consumers can return the product for a full refund if an exploitable security flaw is discovered in the device, and that products must disclose the privacy implications of using them.
Another option is to improve the software ecosystem for IoT to the point where everything is secure-by-default and you have to go out of your way to do something in an insecure manner. That will require a lot of careful API design and probably abandoning C and C++ in favor of something safer. (Rust seems like the most promising alternative at the moment.)
A useful test of whether or not we've succeeded is whether a hobbyist with basic programming knowledge can, with low effort, deploy a custom embedded device that connects to the Internet and have high confidence that it isn't a privacy threat or vulnerable to known security attacks and it will continue to be secure for the life of the product.
I think the full solution has got to be some mix of consumer protection laws and better tools for deploying secure devices. Maybe also some third-party validation organization could get involved, analogous to UL listing for electrical things.
While I love rust and think it (should) replace C for web servers and the like, the majority of the issues with IOT devices are just basic security oversights and design errors.
You raise some very good points:
1. Secure by default should be mandatory. MS learned that one the hard way.
2. Consumer protection laws would certainly get device builders attention. I think that is required. But I doubt the current administration is included to enact such laws.
It is a shame that devices are certified by UL and FCC, but there is no security certification or even a basic audit that would catch: security backdoors, default / blank passwords, auth over http, basic XSS and CSRF vulnerabilities etc.
The bad news is that we don't know how to design a device with Linux and internet services that will be secure without updates for 5-10 years. So we either insist on updating .... or we keep some of the darn devices off the internet.
At at minimum, we should insist on having devices that don't listen on ports just waiting to be hacked. Devices should only connect out.
One solution to this problem is to institute consumer protection laws that say that consumers can return the product for a full refund if an exploitable security flaw is discovered in the device, and that products must disclose the privacy implications of using them.
Another option is to improve the software ecosystem for IoT to the point where everything is secure-by-default and you have to go out of your way to do something in an insecure manner. That will require a lot of careful API design and probably abandoning C and C++ in favor of something safer. (Rust seems like the most promising alternative at the moment.)
A useful test of whether or not we've succeeded is whether a hobbyist with basic programming knowledge can, with low effort, deploy a custom embedded device that connects to the Internet and have high confidence that it isn't a privacy threat or vulnerable to known security attacks and it will continue to be secure for the life of the product.
I think the full solution has got to be some mix of consumer protection laws and better tools for deploying secure devices. Maybe also some third-party validation organization could get involved, analogous to UL listing for electrical things.