Re:Can I drop a pacemaker 0day?
by userbinator on Wednesday June 04, 2014 @10:20PM
(#7849851)
> How can we network everything while maintaining at least some scrap of security, especially in the long term?
Another question that we should be asking more is should we network everything that could be?
As for a pacemaker, personally I think the answer is a definite NO. It has only one function, to keep someone alive, and any extra functionality only represents an increased risk of malfunction. If there is any firmware in it then that firmware should be as simple as it can be. Preferably open-source and subject to being reviewed/corrected by many, before it gets permanently embedded in a device.
> how can we prevent them from occuring in the first place?
The obvious way is by doing it right the first time. Sadly, this is something that seems to have fallen out of fashion, as the prevalent mentality is more like "we can always issue an update, so it doesn't matter that much". A dangerous mentality indeed, when it's in truly safety-critical applications. Companies are increasingly pushing for "smartness" in their products, espousing all the ostensible advantages, while not giving much exposure to the possible downsides too.
Re:Can I drop a pacemaker 0day?
by aianus on Wednesday June 04, 2014 @11:03PM
(#7849987)
I imagine there's some value in being able to update the firmware on a pacemaker. Maybe a new pacemaking algorithm can save 1% more lives or something. Or it could automatically call an ambulance when you have a heart attack, etc.
Re:Can I drop a pacemaker 0day?
by ijk on Wednesday June 04, 2014 @11:49PM
(#7850123)
Implanted medical devices do seem like the ideal situation for wireless access, albeit you probably don't want to overburden the thing with features either.
Another question that we should be asking more is should we network everything that could be?
As for a pacemaker, personally I think the answer is a definite NO. It has only one function, to keep someone alive, and any extra functionality only represents an increased risk of malfunction. If there is any firmware in it then that firmware should be as simple as it can be. Preferably open-source and subject to being reviewed/corrected by many, before it gets permanently embedded in a device.
> how can we prevent them from occuring in the first place?
The obvious way is by doing it right the first time. Sadly, this is something that seems to have fallen out of fashion, as the prevalent mentality is more like "we can always issue an update, so it doesn't matter that much". A dangerous mentality indeed, when it's in truly safety-critical applications. Companies are increasingly pushing for "smartness" in their products, espousing all the ostensible advantages, while not giving much exposure to the possible downsides too.