Risk
4/24/2012
09:40 AM
50%
50%

Should FDA Assess Medical Device Defenses Against Hackers?

Federal advisory board calls for Congress to assign responsibility for preventing medical cyber-attacks.

Health Data Security: Tips And Tools
Health Data Security: Tips And Tools
(click image for larger view and for slideshow)

The vulnerability of wireless medical devices to hacking has attracted attention in Washington. Although there has not yet been a high-profile case of such a cyber-attack, the Information Security and Privacy Advisory Board, which advises the Office of Management and Budget (OMB) and the National Institute of Standards and Technology (NIST), recently proposed that the Food and Drug Administration (FDA) or another federal agency assess the security of medical devices before they're sold.

Reps. Anna Eshoo (D.-Calif.) and Edward Markey (D.-Mass.), both members of the House Energy and Commerce Committee, have asked the General Accountability Office (GAO) to prepare a report on the situation. That report is due out in July.

Congressional interest in the issue was prompted by a public demonstration of how easy it is to hack into a medical device: Security researcher Jeremy Radcliffe hacked his own insulin pump at a recent conference in Las Vegas, using a dongle attached to a PC port to change settings on the device wirelessly.

[ Is it time to re-engineer your Clinical Decision Support system? See 10 Innovative Clinical Decision Support Programs. ]

In 2008, researchers at the Medical Device Security Center in Amherst, MA, also hacked pacemakers and defibrillators wirelessly. An article in Wired Magazine noted that an attacker could use such an approach to kill somebody by sending a fatal shock to a pacemaker, for example.

The FDA has so far received no reports of patient safety incidents tied to the hacking of medical devices such as heart monitors and infusion pumps. But a Department of Veterans Affairs (VA) study showed that between January 2009 and spring 2011, there were 173 incidents of medical devices being infected with malware. The VA has taken the threat seriously enough to use virtual local area networks to isolate some 50,000 devices.

Recently, researchers from Purdue and Princeton Universities announced that they had built a prototype firewall known as MedMon to protect wireless medical devices from outside interference. MedMon monitors communications to and from implantable or wearable medical devices. If the firewall detects unusual activity, it can alert the user or send out signals to block the cyber-attack.

Niraj Jha, part of the team that developed MedMon, told UPI that although the risk of medical device hacking is low, security measures are needed before the kinds of attacks demonstrated by researchers occur in the real world.

Meanwhile, the Information Security and Privacy Advisory Board (ISPAB) believes the government should take action now. In a March 30 letter to OMB, ISPAB chair Daniel J. Chenok said, "The lack of cybersecurity preparedness for millions of software-controlled medical devices puts patients at significant risk of harm." Noting that federal responsibility for these devices is diffused among several agencies, Chenok said that oversight of cybersecurity should be given to a single agency, such as the FDA.

Chenok suggested that the FDA should work with NIST "to research cybersecurity features that could be enabled by networked or wireless medical devices in Federal settings." Furthermore, providers should not have to download software to enable such features; instead, they should be built into the device when it's purchased.

The 2012 InformationWeek Healthcare IT Priorities Survey finds that grabbing federal incentive dollars and meeting pay-for-performance mandates are the top issues facing IT execs. Find out more in the new, all-digital Time To Deliver issue of InformationWeek Healthcare. (Free registration required.)

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7421
Published: 2015-03-02
The Crypto API in the Linux kernel before 3.18.5 allows local users to load arbitrary kernel modules via a bind system call for an AF_ALG socket with a module name in the salg_name field, a different vulnerability than CVE-2014-9644.

CVE-2014-8160
Published: 2015-03-02
net/netfilter/nf_conntrack_proto_generic.c in the Linux kernel before 3.18 generates incorrect conntrack entries during handling of certain iptables rule sets for the SCTP, DCCP, GRE, and UDP-Lite protocols, which allows remote attackers to bypass intended access restrictions via packets with disall...

CVE-2014-9644
Published: 2015-03-02
The Crypto API in the Linux kernel before 3.18.5 allows local users to load arbitrary kernel modules via a bind system call for an AF_ALG socket with a parenthesized module template expression in the salg_name field, as demonstrated by the vfat(aes) expression, a different vulnerability than CVE-201...

CVE-2015-0239
Published: 2015-03-02
The em_sysenter function in arch/x86/kvm/emulate.c in the Linux kernel before 3.18.5, when the guest OS lacks SYSENTER MSR initialization, allows guest OS users to gain guest OS privileges or cause a denial of service (guest OS crash) by triggering use of a 16-bit code segment for emulation of a SYS...

CVE-2014-8921
Published: 2015-03-01
The IBM Notes Traveler Companion application 1.0 and 1.1 before 201411010515 for Window Phone, as distributed in IBM Notes Traveler 9.0.1, does not properly restrict the number of executions of the automatic configuration option, which makes it easier for remote attackers to capture credentials by c...

Dark Reading Radio
Archived Dark Reading Radio
How can security professionals better engage with their peers, both in person and online? In this Dark Reading Radio show, we will talk to leaders at some of the security industry’s professional organizations about how security pros can get more involved – with their colleagues in the same industry, with their peers in other industries, and with the IT security community as a whole.