Cases of computer hacking grab headlines when they affect governments or big companies. But the hue and cry that accompanies the exploits of hackers when they target the likes of Google or the Pentagon has not been extended to the potential dangers facing patients with implantable medical devices. Although medical device security is not on everyone’s radar, the range of implantable devices that is susceptible to hacking is vast and the consequences profound, as was demonstrated not too long ago when Jay Radcliffe, a security researcher and diabetic, hacked into his own insulin pump.
|Insulin pumps are among the many medical devices that are susceptible to hacking.|
In an effort to break the silence surrounding medical device insecurity, a breakfast and roundtable forum will take place on Thursday, November 3 from 8:00 a.m. to 1:00 p.m. at the Marquette Hilton titled “Vulnerable Medical Devices Face Today’s More Virulent Networks: Scary Stories, Real Risks, and Mitigation Strategies.” Scheduled to coincide with MD&M Minneapolis and billed as a venue for healthcare providers and device manufacturers to acquaint themselves with the dangers posed by medical device hacking, the Amphion Forum 2011 Medical will feature digital security experts from a variety of companies and institutions, including Mocana (San Francisco), Codenomicon (Saratoga, CA), Symantec (Mountain View, CA), Medical Connectivity Consulting (Beaverton, OR), InZero Systems (Herndon, VA), IBM (Armonk, NY), the University of California, Berkeley, the University of Massachusetts Amherst, GraniteKey (Livermore, CA), Vanderbilt University (Nashville, TN), and NXP Semiconductors (Eindhoven, Netherlands).
The hacking summit will begin with a demonstration of how to hack an insulin pump, followed by a panel discussion around the theme “Indians vs. Smallpox: Vulnerable Devices on Virulent Networks.” Next, a panel discussion titled “Can You Hear Me Now? The Thirty-Thousand Device Hospital” will identify the challenges and risks posed by the latest generation of wireless medical devices and implants, addressing the security and functionality risks associated with operating a healthcare facility with thousands of devices that are all attempting to communicate wirelessly at the same time. The event will conclude with a panel focusing on “Building Safer Software (and Hardware) for Medical Devices: A Primer.”
To give MPMN readers a taste of what the hacking summit has in store, I conducted an interview with Kurt Stammberger, a certified information systems security professional and vice president of market development at Mocana. —Bob Michaels
MPMN: Please tell me a bit about Mocana and the role it plays in improving the digital safety of medical devices.
Stammberger: Mocana is a company that focuses exclusively on non-PC device security. We’re developing the industry’s only device-independent smart-device security platform that secures all aspects of IP-addressable devices, as well as the information, apps and services that run on them. We have about 180 OEM customers all across the value chain—device manufacturers that embed Mocana’s device security solutions into their devices.
The Internet of Things is a very horizontal phenomenon. In fact, most Internet-based devices today are not PCs, with non-PC devices outnumbering PCs about five to one. And one big segment of that is medical devices, and medical device security is an important segment for Mocana. We help several companies enhance the security of medical devices that are used directly with or within patients as well as those that are used in laboratory or clinical settings.
|It is estimated that 86 million connected medical devices will be sold from 2009 through 2013.|
MPMN: How does the digital safety of electronic medical devices compare with that of nonmedical devices? What are some examples of the safety standards and technologies common among nonmedical devices that have not migrated to the medical device world?
Stammberger: The security posture and safety of medical devices is relatively low, especially when compared with the best security practices applied to other types of connected electronics such as PCs or network equipment. But this discrepancy is symptomatic of the broader Internet-of-Things phenomenon. Every industry in the world—from apparel to medical to industrial—has its own types of devices and machines that they’ve been using in some iteration since the Industrial Revolution. But up until 15 years ago, those devices rarely talked to one another and never connected outside of the enterprise to the wider Internet. So in a very short period of time, all of these relatively unconnected devices have become connected to one another and then connected to the larger Internet somehow.
So, While it’s taken the PC and datacom industries about 20 years to get their acts together on security, this is still very new territory for medical device makers like Medtronic or Abbott. These are companies that might not have many cryptographers or computer security–coding experts on staff because it simply wasn’t necessary to employ those types of people before because the medical devices just weren’t connected. But now that’s all changed, and now there is a lot of urgency for every single device to connect with every other device.
That’s job one for medical device product teams: making sure that their devices connect and communicate. Unfortunately, the secondary consideration—one which everyone kind of blew off in the first round of product design—was, “Maybe we should worry about the security of the devices, too.”
MPMN: What particular medical devices are affected by the lack of security, and what can be done to protect them?
Stammberger: Of particular concern are fully implanted devices such as pacemakers or defibrillators, on the one hand, and semi-implanted medical devices such as insulin pumps, on the other. Such devices reside outside the patient but have a needle that is directly inserted into the body. Among all of the medical devices of these two classes that I have seen or read about—in terms of their security stance and posture—none of them have any significant ability to defend themselves against outside penetration attempts. We’ve seen this demonstrated over and over and over again in the past few years. Security is just not being designed into medical devices.
This situation is worrisome, because such devices are used in especially critical contexts. For example, they are either capable of delivering potentially dangerous, if not fatal, electric shocks, or they can be taken over wirelessly by hackers and instructed to deliver drugs in whatever dosage desired, as has been demonstrated with drug-infusion pumps.
But other types of devices that aren’t necessarily implanted or fully attached to the patient are also of concern, including ventilators, rolling workstations, or MRI machines. A case in point is that last year, a lot of attention was paid to the study of machines that were delivering too much radiation and causing illness in patients. The problem was basically traced back to a software error. Such incidents underscore the fact that machines can physically injure or kill patients because of faulty lines of code, problems introduced into the code by a hacker, or simply collateral damage caused by a viral infection spreading through a hospital network.
MPMN: What are medical device companies doing to rectify this situation?
|In 2008, researchers hacked into a defibrillator/pacemaker. The equipment used to hack the design included equipment normally used to reprogram the device, an oscilloscope, and a small radio transmitter. The researchers were able to extract personal information, shut down the device, and deliver shocks at will.|
Stammberger: The danger posed by the potential to hack medical devices is scary. But the other scary thing is that there isn’t a lot of momentum within the medical device industry to address such dangers. Most medical device manufacturers do not have a serious antihacking, device-defense cryptography program in place.
Meanwhile, a lot of attention is being paid to aspects of healthcare that are controlled by regulations, particularly the privacy of electronic health records. If you have a device or workstation that’s touched by the Health Information Technology for Economic and Clinical Health (HITECH) Act or by the Health Insurance Portability and Accountability Act (HIPAA), there’s a lot of focus on security. And the companies that manufacture such devices are working very hard to make sure that they comply because they can then get purchase orders from hospital and healthcare providers.
But there’s no requirement from anywhere—from FDA or from any kind of federal or state regulation—saying that you have to implement basic network-security best practices on your medical device so that someone can be reasonably assured that it cannot be invaded or taken over, either by a human actor or a piece of electronic virus or malware. No regulations, no such standards, currently exist.
MPMN: So what is Mocana doing?
Stammberger: When we work with medical device manufacturers or any other device manufacturers, we start by performing a clean-slate evaluation of the system as a whole. And we look at the device for exactly what it is: a computer on a network. And you know what? As an industry, we already know how to protect computers on networks. Twenty years of best practices have been applied to concepts like ‘defense in depth.’ You have not one, but several, security measures layered on top of each other—redundancy—ensuring that your device can defend itself from the most common types of attacks. This is a way to spend money where it will do the most good.
Measures include protections such as firewalling—a means for determining that an incoming update image is authentic and has not been compromised. For example, everyday your PC or Mac tells you that it’s got an update ready to be installed. Do you want to install it? For computers, there is an industry best practice whereby the software publisher digitally signs the image of the software cryptographically—using a digital signature—and your system checks that signature against the public key digital certificate from Apple, Microsoft, or other software publisher. Thus, the software update can be validated as coming from a trusted source, ensuring that it hasn’t been tampered with or infected since it was signed. With that validation, the system knows that it’s safe to install the update. This is a good thing because a lot of updates aren’t just application patches; they actually replace part of the operating system or the firmware of the device.
This concept is not common in the medical device field. First of all, firmware is rarely delivered remotely to electronic medical devices, and if it is, there’s no industry-accepted standard for authenticating it to make sure that it’s not a piece of firmware that I hacked up myself to replace the original personality of the device so that I can take it over. No one in the modern datacom, PC, or business computing economy would ever consider releasing a device that cannot authenticate its own firmware replacement. Yet, that’s done routinely in the medical device field.
MPMN: So you’re company’s goal is to try to change that?
Stammberger: Right. We try to bring cryptographic and security best practices to connected devices in all different verticals, including medical devices. And a lot of what we do with industries that are fairly new to cryptography and security—such as the medical sector—is to start with baby steps. We say, we’re not going to solve every problem that you could conceivably have with your device. But why don’t we do this: When you turn the device on, why don’t we check the firmware to make sure that it’s still authentic and that it hasn’t been replaced. When we connect to a remote system such as a hospital system, why don’t we do a challenge/response—a kind of cryptographic digital signature—and ask that the remote system certify that it’s actually the system I think it is and not an impostor system that’s trying to harvest my data or take me over.
Those are some basic steps you can take to play it safe on a hostile network. But medical device manufacturers don’t do these things yet. They think that their devices live in a really good, beautiful, safe neighborhood with beautifully manicured lawns and white picket fences, and nobody has to lock their doors. But the truth is, they don’t live in that kind of environment anymore because while no one was looking, in the past 10 years, their neighborhood has really gone downhill. Now, it’s nasty and it’s sketchy, and their network is just as dirty, just as virus-prone, and just as spam-filled as anybody else’s. The network is a dangerous place, and devices have to start taking more responsibility for their own defense.
MPMN: What do you hope that attendees will take home from the hacking summit?
Stammberger: Most of the audience will consist of medical device manufacturers. provider organizations, and software developers that work on, or with, medical devices. What we’re trying to do is raise awareness and create more of a sense of urgency to address this problem because the trend lines—like everything else in technology—grow exponentially. And the one thing about these exponential curves is that when you’re petering along at the beginning, like the medical device industry is now, device security doesn’t seem like much of a problem. But then you hit that knee and bam! It becomes a big problem, it’s everywhere, and it’s pretty much too late to do anything about it. Thus, we’re trying to sound the alarm, saying, “Let’s address this problem more holistically as an industry now while it’s a lot easier to deal with it, rather than 10 years from now when it’s going to be a nightmare.”
- Polystyrene Microbead Coating Procedures - Supplier Resource
- Optimizing Technology for Multi--Cavity Medical Molds - Video
- Understanding Accuracy and Precision for MEMS Pressure Sensors - Supplier Resource
- Bandwidth vs. Signal to Noise Tradeoff - Supplier Resource
- Dual Die Compensation for MEMS Pressure Sensors - Supplier Resource
- Liquid Silicone Rubber and Medical Device Design - Webcast