There's no incentive for manufacturers to do anything. This actually just increases sales, as dead devices are replaced (probably by the same device/firmware). Insecurity converts the equipment to a consumable that generates an annuity.
I see the normal manufacturers/sellers responsibility as the only good answer to the problem. I don't like solutions involving fines or large liabilities, because these can create wrong incentives to people/companies.
Doing security properly for these devices is not very expensive compared to scale they are being sold. Therefore I think simple things like increased return/warranty repair rates should provide enough incentive to focus on security.
Making manufacturers liable for incidental damage their devices do sends the message that they should avoid such damages as far as possible. That seems like a good message to me.
If device $20 device X does $20,000 damage to the hospital down the road, the fact that the consumer can return the device seems woefully insufficient.
If it were able to do that, then presumably that $20 device had eg a good amount of explosive in it, and therefore would be in no condition to return it to the store.
Unless you're alluding to that $20 device being used as a communications proxy, under a mistaken idea that the Internet has some concept of node trust. In reality, the hospitals $20k "damage" would be due to its own developers' negligence and demands for compensation should be placed squarely at the door of its suppliers and integrators.
What I did imply is that if I develop a device and put it on my network, then I'm essentially responsible for whatever damage it causes. Eg wiring a RPi to a heating element that will start a fire if left on continuously is a poor idea, regardless if the proximate cause is a cosmic ray bit flip or malevolent Internet noise.
'Cause certainly random average-consumer should know how dangerous adding crap to their network can be ... for others ... and certainly he/she is capable of making provisions for this.
Fortunately, modern legal theory actually does consider "who are talking about here, what can expected of them." in cases like this. Hospitals could theoretically sue IoT manufacturer on this as far my ianal knowledge goes and it's more that the manufacturers are distant cheap factories in China that prevents this.
Erm, no - the exact opposite. The consumer should look at the camera's manufacturer for their own connection being swamped, incurring overage charges, etc. In your scenario, if the hospital's only problem is that their Internet uplink is swamped, then they should be looking at their link provider for robust upstream shaping, etc. In the case of a simple traffic overload, nothing critical at the hospital should be affected because critical traffic should be segmented, or at least prioritized, over traffic from arbitrary endpoints. If there is more of an affect, then that is due to a further vulnerability that belongs to the hospital!
I referenced the hospital's developers/suppliers for these further vulnerabilities - in those cases they should be looking at their network admins, or at the creators of the failing (defective) equipment. The crux of the End to End principle (ie the Internet) is that edge nodes have the intelligence, and thus requirement/responsibility, for discerning "good" traffic from "bad". And (as I said) coming at it from the other direction, general robust engineering principle dictates that physical devices "fail safe" no matter what noise is presented at their network ports.
Not sure that's true. I did a 18 month stint with a tiny (6 person) hardware startup - most of my time was spent ensuring our devices could auto-update their embedded Linux securely without bricking or losing any of the custom hardware specific capabilities. It's not an easy trick to pull off (big thanks to the ARCH Linux team for all their work that I built on), and there's ongoing cost involved to ensure newly discovered vulnerabilities have a process to be evaluated, patched, tested, and deployed to the fleet of devices.
Vulnerabilities and updates are inevitable, but the current volume of them is not, by orders of magnitude.
The volume of serious exploits could be reduced dramatically if we started to more seriously apply the principle of least authority (and an important technique and way of thinking about that is capability security -- in fact an important technique to make 'brickless updates' easier to achieve too, I suspect).
I think how to kick-start the industry to actually do that is a difficult problem.
edit- The main objective, of course, being allowing unattended atomic updates with as low a risk of bricking the device as possible. Usually these devices will be updating the whole root filesystem at a time, which is otherwise read-only. Ideally this is also done with as little downtime as possible. There is some work in this space in standardizing a solution, but it isn't really there yet, so it tends to get home-grown for each product.
(Source: I was the platform security guy for an IoT startup in 2013/14, for a company who no longer exists and who's only product run is still out there somewhere no longer getting security updates...)