A New Pacemaker Hack Puts Malware Directly on the Device
36 replies, posted
Only certain ones. Who would bother doing that on your random old dude
This is obviously to give various loose ends sudden heart attacks
This is the mentality that ends up with a situation like this, this kind of hack can be automated, and it will just require one talented very evil person to create a self replicating malware that just kills people.
That may be a certification requirement.
The certification process takes ages and newer Windows versions are, let's say, 'less than adequate' for hospital use in some ways due to rampant telemetry.
I sorta disagree that OTA updates shouldn't be a thing, but with how simply abhorrently these IoT devices have been implemented, maybe it shouldn't be a thing. Apparently RSA and the like don't exist.
Hi, I work in this industry (not for Medtronic) and I can somewhat speak to some of ideas and things I see as misconceptions in this thread/your post to hopefully add perspective.'
To start, while the information in this article doesn't exactly say, the word pacemaker implies it's mostly for bradycardia, not tachycardia/defibrillation. The failure modes that are being discussed are barely worth noting for bradycardia pacemakers when compared to a defibrillation unit; a pacemaker for bradycardia need only help kick the heart into gear once it starts slowing down instead of it attempt to seize up. To add further, there are different kinds of pacemakers: some people are pacer dependent and others are not, the former being much more at risk in this case because pacemakers can only be made to establish a rhythm so fast (they cannot cause fibrillation).
I will move forward with the assumption we're talking pacemakers, not defibs.
You really want the pacemaker to be able to be updated after assembly, you 100% want this. Very few pacemakers are implanted with the same settings, every single individual is different. While you can start at whatever iteration of the current base model, it's going to require some post-implant programming to dial it into a patient's specific needs. You entirely want this to be changeable later if necessary in case the patient needs more/less/different therapy down the line during the life cycle of the unit (roughly 20 years).
I definitely agree that you do not want this to be over the internet and that the unit shouldn't be linked to the internet in any shape or form. At best the unit should be able to use something short distance, like bluetooth. Having bluetooth connectivity, so far the industry really only provides proprietary readout devices and not a mobile app or something similar, allows the patient to actively see their own data, status of the unit (battery, pace rate, etc.), and other useful information. Obviously this should be read-only information that doesn't even touch a programmable part of the circuit. The only way a device should be programmable is in person with some form or specific/proprietary manner of accessing such an interface for the device.
Awesome, thank you for the insight. I'm an EE myself so I suppose there are alot of MTBF testing and the device would fall into a default safe mode in case the upgrading process fails (Checksums galore).
Sorry, I'm mostly knee jerk negatively to anything remotely related to IoT because it always screams of half-baked engineering.
Oh, no worries. Others seemed to share the same sentiment and it's my job.
As far as safemode, I do know that the units we manufacture enter a safemode/default state when in specific environments, namely getting set-up to be programmed and when they detect a large magnetic field (so that they can be MRI compatible). I work much more on the component and QA side of manufacturing, so I don't know the full ins-and-outs of our software, for what it's worth.
Sorry, you need to Log In to post a reply to this thread.