Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Ask Professor Kevin Fu About Medical Device Security

samzenpus posted about a year ago | from the protect-ya-neck dept.

Medicine 57

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.

Sorry! There are no comments related to the filter you selected.

Password protection (-1)

Anonymous Coward | about a year ago | (#45059721)

Do you password your protect your dildo? If so, who are the bears with the password?

How often are the virus definitions updated? (0)

Anonymous Coward | about a year ago | (#45059747)

And do you need to be within range of a wifi access point?

Cochlear Implants (3, Interesting)

mcspoo (933106) | about a year ago | (#45059821)

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?)

Re:Cochlear Implants (2, Funny)

girlintraining (1395911) | about a year ago | (#45060849)

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?)

That depends: Did you recently vote Republican?

Re:Cochlear Implants (0)

Anonymous Coward | about a year ago | (#45061161)

Or sucked a Democrats Cock. I'd ask if they payed off the highest democrat to get an exemption from Obama Care and the NSA. Just sayin. Liberals we make em dumber by the day. herp de derp

Re:Cochlear Implants (1)

LifesABeach (234436) | about a year ago | (#45062395)

One cannot help but wonder as to being shown a "Password Secure" Syringe.

Simple: let the free market sort it out (-1)

Anonymous Coward | about a year ago | (#45059839)

Release a defective product that kills a few people and the company that makes it will be out of business in no time. This is the true power of the free market.

!Ron Paul 2016!

Hospital network security (0)

Anonymous Coward | about a year ago | (#45060075)

How likely would you consider it to be that a hacker, either with malicious intent or just fooling around, could gain access to the average hospital's internal network, say through an insecure VPN connection? (That is, the network running the Laboratory Information System and whatever devices talk to it.) And that they would then proceed to try to guess user names and passwords of any devices on the network that allow SSH access? If you were developing such a device, is that a scenario you would worry about? Have there been any documented cases of such attacks?

Re:Hospital network security (1)

certain death (947081) | about a year ago | (#45060457)

VPN by design is a secure connection...so, what would you consider the requirements for an insecure VPN to be?

Re:Hospital network security (0)

Anonymous Coward | about a year ago | (#45061737)

VPN by design is a secure connection...

A VPN is a Virtual Private Network, and it's not any more or less secure than any other private network.
You're thinking of a VPN Tunnel, which is a secured connection between two endpoints used to connect two portions of a private network. And while the tunnel itself may be secure, that does not mean that either endpoint or any other part of the virtual network are also secure.

3rd party vendors have a bit of control over (1)

Joe_Dragon (2206452) | about a year ago | (#45060637)

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.

Re:3rd party vendors have a bit of control over (1)

anjrober (150253) | about a year ago | (#45061741)

i have worked at many, many of the largest and most prestigious hospitals (like hundreds of them) in this country (and many others) and all have VPNs options. Mostly IPSec but a few use other remote access tools. Its a requirement to run a hospital today.

Re:3rd party vendors have a bit of control over (1)

Darinbob (1142669) | about a year ago | (#45062549)

Well they want their own OS updates of course. Third party updates make no sense because usually there is no commonly known OS being used or it is statically linked with the applications.

Cell Phones (0)

Anonymous Coward | about a year ago | (#45060095)

Is everything really that vulnerable to a few jackasses with cell phones turned on?

Seems sketchy to me. Same with airplanes.

Patients or profits (0)

Anonymous Coward | about a year ago | (#45060133)

It seems to me that the primary goal of many medical devices is to get a "razor type" device accepted so they have a market for their high margin "blades". In your experience, is that a valid criticism?

Safer Programming Language (0, Interesting)

Anonymous Coward | about a year ago | (#45060163)

The C programming language is most often used for embedded devices. The language is poorly specified. Compilers sometimes have issues, and programmers find a zillion creative ways to make mistakes. MISRA C and its enforcement is a bag of hurt in the absence of certified tools. Has there been any work to define a more safe/sane programming language for embedded devices?

Re:Safer Programming Language (0)

Anonymous Coward | about a year ago | (#45060711)

  The C programming language is most often used for embedded devices. The language is poorly specified.

You don't mean to say "poorly specified", do you? May you want to say C allows poor programming practices?

Re:Safer Programming Language (0)

Anonymous Coward | about a year ago | (#45060799)

Poorly specified in the sense that some fundamental concerns are left to the implementer (i.e., the compiler vendor). The Motor Industry Software Reliability Association (MISRA) has good coverage of the associated problems. The language itself has gaping holes; e.g., the result of a boolean expression returns a signed integer, a result that is in a different essential type category than a _Bool.

Re:Safer Programming Language (1)

Charles Duffy (2856687) | about a year ago | (#45070459)

"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).

PCA Pumps? (2)

Digital Ebola (29327) | about a year ago | (#45060169)


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.


What to do when security is unfixable? (0)

Anonymous Coward | about a year ago | (#45060203)

Seeing the abysmal state of computer security, even basic computer reliability expectations (which Dijkstra already noted, years ago), it's no surprise that embedded systems are no better. Simply because you usually don't see them and are thus less likely to notice just how poorly and insecurely the software is done.

So how do we convince these people in the medical apparatus industry to leave well alone with the networking and wireless and bells and whistles, and simply deliver us machinery that does what it does, keep us alive, and not also surf the 'web for cat videos, or leave the door open for someone to come along with the latest exploit kit? Why do these things have to be connected at all?

Re:What to do when security is unfixable? (1)

kwbauer (1677400) | about a year ago | (#45063139)

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.

Re:What to do when security is unfixable? (1)

pepty (1976012) | about a year ago | (#45063789)

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.

Clinical Data Systems (1)

DeathGrippe (2906227) | about a year ago | (#45060225)

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 US budget issues affected your research? (2)

JAS0NH0NG (87634) | about a year ago | (#45060255)

How have recent issues like sequestration, reduced NSF and NIH funding, and the government shutdown impacted your research?

Re: How have US budget issues affected your resear (0)

Anonymous Coward | about a year ago | (#45061647)

Not at all. My research is PRIVATELY funded and thus not affected at all. this is why I always vote libertarian, because science is too important to leave to goverment.

!Ron Paul 2016!

What can I do if I have one? (2)

AmiMoJo (196126) | about a year ago | (#45060257)

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?

Start-ups (1)

Nanonite (1452127) | about a year ago | (#45060359)

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?

Re:Start-ups (0)

Anonymous Coward | about a year ago | (#45090269)

How good is malware detecting software and the WattsUpDoc system at finding something potentially harmful on a device?

Features to look for in an upgrade (1)

karchie (560701) | about a year ago | (#45060449)

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?

Manual override (1)

Errol backfiring (1280012) | about a year ago | (#45060583)

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?

Re:Manual override (1)

AeroMed45N (919761) | about a year ago | (#45071159)

There is a difference between "fly by hand" and "fly without depending on the computer" -- in today's modern fly-by-wire aircraft, there are still computers/electronics between the pilot and the control surfaces even when the flight management system, auto-pilot and even primary flight controls are "down".

The question is what failure modes, considering the presence of security threats, require simple back-up systems? How would such back-up systems be invoked?

Software updates and security (0)

Anonymous Coward | about a year ago | (#45060591)

How should security related OS updates be handled in a medical device running a general purpose OS such as Windows? Should Windows, for example, be allowed to update the OS automatically? Or leave it at the hands of the manufacturer and risk security breaches?

Dieing Caps and other parts in systems that old (1)

Joe_Dragon (2206452) | about a year ago | (#45060597)

Dieing Caps and other parts in systems that old may lead to higher power use

Question! (0, Offtopic)

war4peace (1628283) | about a year ago | (#45060635)

Have you ever considered changing your first name to "Kung"?

Should the local IT team have full control over an (1)

Joe_Dragon (2206452) | about a year ago | (#45060657)

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?

Re:Should the local IT team have full control over (1)

Darinbob (1142669) | about a year ago | (#45062633)

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).

Re:Should the local IT team have full control over (0)

Anonymous Coward | about a year ago | (#45068655)

If you mean implantable devices, sure, but the vast majority of medical hardware is not implantable--monitors, test units, pumps, ventilators, imaging devices, etc., and much of it is networked to make workflow more efficient.

The majority of medical devices that interact with other systems have a commodity OS as a platform. I have most commonly seen Windows, Linux, BSD, and QNX, in that order. We have demonstrated attacks telemetry attacks to vendors, who turn and claim it is not an issues as it is on a "secure network" (wired) or in a "secure facility" (wireless). They also don't see the issue with exposed ports on their linux based units. (-Anon Archimedes member)

Incentives (1)

giantism_strikes (1887188) | about a year ago | (#45060773)

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.

ob (1)

Hognoxious (631665) | about a year ago | (#45060839)

So, Professor, tell us about medical device security.

Re:ob (0)

Anonymous Coward | about a year ago | (#45061705)

Good grief, person, don't waste the professor's time. Just one search on ' IMD "Kevin Fu " ' will get you more than you can read in one sitting. I'd include the links here but you need to go find them yourself.


What can we do now? (1)

BradGwart (961302) | about a year ago | (#45061045)

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.

Model, or island? (2)

skids (119237) | about a year ago | (#45061183)

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?

Modding/hacking our own devices (0)

Anonymous Coward | about a year ago | (#45061361)

This is not a GPLv3 question but GPLv3 brings up a good point: If I am allowed to reflash/change my medical device, and it's technically clear that I've done so, does that really affect the legal liability of the original manufacturer?

My initial guess is that the manufacturer doesn't get a "get out of jail free" card when I've modified my software but that the burden of proof shifts to proving that unmodified software would have had the same issue and that my changes didn't make the issue more likely to happen.

Regulation (0)

Anonymous Coward | about a year ago | (#45061481)

Do you feel the amount of FDA regulation increases or decreases the level of security for medical devices?

Specifically, let's say a minor security bug is found in the software but the amount of validation, documentation and even the method of delivering this update to a customer makes it unrealistic to implement short of a complete release that happens to include this fix.

But how does it smell? (1)

mcorner (168581) | about a year ago | (#45061543)

What does the inside of a used implantable defib smell like? I know Kevin knows :)

What issues would prevent a hackathon of IMDs? (0)

Anonymous Coward | about a year ago | (#45061657)

I have in mind soliciting donations of Implantable Medical Devices, building the external programmer described in some of the papers that you and your cohorts have written, and putting on a public hackathon to crack as many different IMDs as possible. We offer the results to the companies that made them so they can secure their software, and openly publish the results a year later. Think a Black Hat convention for medical geeks.

Dr Fu, you're doing tremendous work in Archimedes but I think the manufacturers who aren't participating with your programs need a fire lit under them.

Thanks, and keep up your very important mission.
- HTuck

Starting a Medical Device Security Program (0)

Anonymous Coward | about a year ago | (#45061817)

How would you suggest starting a Medical Device Security program for a hospital system?

Closed set of acceptable commands? (1)

linear a (584575) | about a year ago | (#45062671)

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)?

Same as data acquisition? (1)

dargaud (518470) | about a year ago | (#45062801)

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 ?

Medical device security vs. Open standards? (0)

Anonymous Coward | about a year ago | (#45062859)

In the ever increasing world of consumerized technology (Apps, smartphones, smarter cars etc.), how do you see medical device security staying relevant and cutting edge while maintaining adequate security? More and more people can and probably will ask "why can't I use with my ?". For instance, could a secure, but open interface be created for Insulin pumps which would allow an end-user app to aggregate multiple data sources into a better snapshot of that person, while still being secure and protected from hijacking by a 3rd party?

Malware.. on medical equipment? (0)

Anonymous Coward | about a year ago | (#45063031)

Are there really any malwares targeting medical equipment? I can't see someone that evil. If so, how do they get infected in the first place since they are rarely connected on the Internet?

secuirty?... some devices still run NT4 (0)

Anonymous Coward | about a year ago | (#45063657)

Security? I know of a system that does medical imaging for cancer patients that still uses a primarily DOS based system to run the beam scanners and runs on Windows NT4... YES... Windows NT4...This particular one has 4 locations in Southern California.....

Insulin Pump (1)

officialchicken (3388011) | about a year ago | (#45063977)

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 [richthediabetic.com] in the data-accuracy [diabetesdaily.com] department. Their Continuous Glucose Monitors [medtronicdiabetes.com] 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?

Changing the Purchasing Model? (0)

Anonymous Coward | about a year ago | (#45068929)

How do you see things changing with regards to clinicians who select/demand specific medical devices to prioritize security or life cycle concerns?

While trying to insert IT into the purchasing process, we still have clinicians who purchase devices with wireless/wired networking, server, and cloud requirements that can barely be met. Security, TCO, life cycle and scaling are rarely considered, and if they are, there are often very few viable alternates anyway. Many solutions are designed for small clinics and we are trying to stretch them into massive deployments. Clinicians can wield significant political power and often expect IT to simply make it work without concern for the massive (and often unfunded) IT support workload their creative solutions create. The standard life cycle for a device is often 10-15 years, making any security woefully obsolete before they are replaced.

Hello? Fu? Anyone home? (1)

Smerta (1855348) | about a year ago | (#45149495)

So, what happened? Where is the amazing Mr. Fu and his wonderful, dazzling insights? All I hear is crickets.

IMD hackathon? (1)

HTuck (3403007) | about a year ago | (#45176609)

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?
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?