Slashdot Mirror
Ask Professor Kevin Fu About Medical Device Security
Kevin Fu is a professor of electrical engineering and computer science at the University of Michigan. He heads a research group on medical-device security, Archimedes, that works to find vulnerabilities in medical equipment. WattsUpDoc, a system that can detect malware on medical devices by monitoring changes in power consumption, is based on his work. Professor Fu has agreed to put down the pacemakers for a moment and answer your questions about his work and medical device security in general. As usual, ask as many as you'd like, but please, one question per post.
How secure are Cochlear implants and their processors? Any chance I'm going to hear the voice of God (without the tooth implant, ala Real Genius?)
Hello!
Have you explored changing the dosages on drug pumps? Either through exploiting the device directly or by exploiting the database backend? I reference the Hospira pumps that run Linux, allowing one to telnet to them as root with no password authentication. Hospira did issue an update to that but since pumps are so numerous, I'm sure that many hospitals have been slow to update.
Thanks!
"Network penetration is network engineering, in reverse."
Most clinics, hospitals, insurance companies and dental offices are extensively computerized and networked. Based on your experience, how often are these systems compromised?
How have recent issues like sequestration, reduced NSF and NIH funding, and the government shutdown impacted your research?
Say I have an implant that could be hacked, what can I do to protect myself? Are any vendors more reputable than others when it comes to security? Is tinfoil effective? Should I demand my doctor replaces known vulnerable equipment?
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Are you following any medical device start-ups [If so what is your favorite]? As I see more low-power bluetooth implementations, I see the possibilty for bluesnarfing, any pointers for good software/electrical security design?
My pacemaker should be replaced in 2-3 years, what should I ask my cardiologist about the new one to address security concerns? Are there vendors, models or features I should request?
You knew the job was dangerous when you took it. -- Super Chicken
VPN by design is a secure connection...so, what would you consider the requirements for an insecure VPN to be?
"My immediate reaction is "WTF? What kind of moron doesn't make things 64-bit safe to begin with?" Linus
In commercial aircraft, there used to be a rule that the aircraft could be flown entirely by hand. Yes, you can even fly a 747 by hand if the systems fail. Is it feasible to have such a rule for medical devices? Does such a rule exist?
Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
Dieing Caps and other parts in systems that old may lead to higher power use
3rd party vendors have a bit of control over there own hardware / software and may want to even have some kind of remote login or even need ports open for sending data.
Also some of them don't want OS updates done as well.
Should the local IT team have full control over any system in place / should vendors be forced to let systems have AV and OS updates installed on them with out delays?
How do you create incentives for the companies that make these devices to make them secure?
The current comments on the draft for "Content of Premarket Submissions for Management of Cybersecurity in Medical Devices" pertaining to 21 CFR 820.30(g) have a disturbing trend of focusing on "unauthorized access" of these devices to be considered criminal (CFAA) instead of trying to protect against said access. Furthermore, I find any discussion of encrypting the data immediately turns to data bloat due to encryption. Often times, the data messages that are being sent back and forth are small (24 bytes), so device manufacturers are worried about real time responses when the data size is dramatically increased.
So, Professor, tell us about medical device security.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
What can those of us that have an implanted medical device do to protect ourselves now? I have Boston Scientific ICD, but due to the circumstances in which I was given the device it's not like I was able to make a choice in the matter. I couldn't do any research to determine which might be the most secure device to go with. So I am stuck with what I have, with no real knowledge of how secure it is and what my risks may be.
Being a highly regulated industry, I could see the eventual evolution of a competent security culture in medical IT/manufacturing. We certainly don't have it quite together now, but if and when that comes to pass, do you see the lessons learned in that sector promulgating out to other industries, or will the environment of high regulation (and high stakes) produce too alien a solution set for general application?
Someone had to do it.
What does the inside of a used implantable defib smell like? I know Kevin knows :)
This is usually not possible. Many of these medical devices don't run Windows or Linux. They are embedded systems with real time operating systems, embedded operating systems, a home grown operating system, and sometimes no OS at all. Other times the applications are statically linked with the OS so that it is unable to be upgraded independently.
That is different from medical turnkey systems that are basically generic computers overlaid with specialized applications (hospital records keeping, image management, drug access control, etc).
Is it feasible, for at least some devices, to embed in them a closed set of commands that are acceptable and have them automatically reject any other commands (e.g., prevent buffer overflow and sql injection sorts of things)?
I work in data acquisition and some of the equipment we have, digital multimeters, digital spectroscopes, run things like Win2K SP1 or XP SP1... Security updates were never 'though of' for those things. If we were to put them on an unsecured network they'd get owned in 20 seconds flat. It's terrifying but we know how to deal with it: don't even connect them to the internal subnet ! Is it as bad with medical devices ?
Non-Linux Penguins ?
So that we do not have to have a one-to-one relationship between patient and nurse? If these devices had no connectivity, then every patient would have to have at least one nurse in attendance at all times to monitor that the equipment is still functioning or that the various rates being measured are still within acceptable limits.
Wireless monitoring of data can be allowed without also allowing wireless reprogramming. For implanted devices they could at least restrict wireless protocols to near field communication.
Besides the obvious "Pumps are easy hacking targets," and "It's a CGM, not an artificial pancras you marketing schmuck,"... It's obvious we need better firmware and 3rd party testing for these devices. Medtronic in particular seems to be challenged in the data-accuracy department. Their Continuous Glucose Monitors seem to be the most expensive and most inaccurate glucometers manufactured in the past 20 years. Although I'd like to know what legislative hurdles remain for the creation of more open devices for us, the question my Endocrinologist is a bit more general and full of nuance. He would like to know how does a Doctor deal with the absolute insanity that is data reporting - just about every device, be it pump, glucometer, or CGM combo has the ability to export data, but requires some expensive proprietary setup to get the data out of the device (or is locked in a cloud). His office has stopped acquiring these devices due to the fragmentation and cost... and now I'm back to using paper for reporting (5-10 samples a day, submitted every quarter). Finding trends for most of my fellow patients has become more difficult, not less. As a typical /. reader, I manually transcribe my samples/tests (a timestamp/reading value tuple) into CSV files and follow up with some R (programming language) to do some simple trend analysis.
The typical capitalist approach of "vote with your wallet" doesn't apply to this regulated market especially because it's the insurance companies that pay most of the cost. How can we compel manufacturers to use an standardized format for reporting, something like a standard physical interface like USB for those of us who use non-implanted devices, and most importantly how do we get into the hands of medical health professionals an easy to use standardized device for post-facto data collection and analysis? And furthermore, my Endo was unaware of the Defcon presentation hack as recently as 3 weeks ago - where can they go to find this information about security?
"Poorly specified" is fair, inasmuch as it's extremely easy to rely on undefined behavior in C without knowing that one is doing so (and thus to get "compiler bugs" that aren't, when the compiler chooses to make platform-specific optimizations).
So, what happened? Where is the amazing Mr. Fu and his wonderful, dazzling insights? All I hear is crickets.
I have in mind soliciting donations of Implantable Medical Devices, building a Programmer such as you describe in some of the papers you've published, then holding an annual hackathon of the IMD's. Figure out how to crack them and control them, then give the results to the manufacturers. Each year, we publish last year's results and crack another batch. I'm sure this plan presents ethical dilemmas in some peoples' minds but to me those are nothing compared to the even worse ethics of letting crappy code ship in these life- critical devices. I think the delay in publishing the results gives mfgrs plenty of time to mitigate any lapses in code quality that they neglected to cover in the first place. This is the high level view, of course; building the Programer isn't quite as easy as, say, putting together a Lego airplane. But in principle, what obstacles, gotchas and advisories do you see to this scheme?