By Kurt Woock
On June 13, the FDA released a document titled, “FDA Safety Communication: Cybersecurity for Medical Devices and Hospital Networks.” Major news networks such as CNN and The Economist reported on the standard-issue release with pronounced alarm. The document outlines, in broad terms, a list of security risks that can be found in medical devices. In a related release, Homeland Security’s ICS-CERT (Industrial Control Systems Cyber Emergency Response Team) reported that two researchers found a hard-coded password vulnerability that might leave as many as 300 medical devices, many of which perform life-critical functions, prone to exploitation. Scary stuff, indeed.
But to many people who work with this equipment and, more importantly, the networks in which these devices live, the news is nothing new. “We’ve been waiting and expecting this for a number of years,” said Dennis Minsent, MSBE, CCE, CBET, director of clinical technology services at Oregon Health & Science University. Minsent said that his team has known about these for a while. “We have taken cyber security very seriously for a number of years; we’ve worked hard to firewall and protect all of our clinical devices.”
Software security expert Axel Wirth wasn’t surprised by the content of the release, though he said the timing of it was significant. Wirth, CPHIMS, CISSP, national healthcare solutions architect for Symantec Corp, said that he was not expecting the FDA to release such a statement until later this year. Many in the biomedical engineering community see this coordinated announcement between FDA and Homeland Security as an indicator of a heightened priority of this topic and a wakeup call for the industry. The problem of security, or general lack thereof, has been illustrated by the example of devices using a single, unchangeable password; find your way into one, and you can theoretically find your way into every other iteration of that device. But a more complete picture of medical device security also includes many other types of potential vulnerabilities, all of which need to be addressed in a comprehensive, industry-wide way.
For now, this threat remains theoretical — to date, no devices have been compromised by a targeted attack outside of a research setting. As to how this one type of security threat fits into the larger fabric of total network/IT security, Wirth said that risk profiles vary by facility, so it’s difficult to assess risk other than on a case-by-case basis. “You want to make sure that you understand the vulnerability profile of all devices on your network,” he said.”If it is a device used only in the hospital, it’s a very different risk profile than if it is used in a home care setting or even implanted in a patient. It’s also very different if the patient is you or me or if the patient is a celebrity, for example.” Minsent said, generally speaking, larger hospitals and hospital systems might have an advantage in dealing with the issue as many have the expertise needed in-house.
Attacks can occur in multiple forms. While reports such as these often conjure up an image of a lone malevolent hacker wreaking havoc, Wirth said that is but one way devices can become infected. Unintentional attacks occur, “not because someone is targeting a device but because the device is on the network,” Wirth said. The attacks can be just as potent. Malware that might have been a problem for PCs years ago but are now under control with respect to PCs might find their way onto medical devices. Operating System patches protect PCs, but medical devices often don’t have the same up-to-date patch status and protection. In addition, the ways in which malware might affect medical devices are largely unpredictable. They can impact functionality or plainly slow the device down should it become part of a botnet or spam server.
While the FDA’s release certainly caught the attention of many people, it’s the work ahead that forms the crux of this issue. Minsent said a final document from the FDA could take years to compile as comments from scores of vendors and others in the industry pile in. As for how this announcement will affect his department? “We’ll go back and do a review based on the recommendations,” he said. “I really see this as being more of a challenging issue for the device manufacturers rather than the end-users, the hospitals.”
The responsibility for action is split among several groups, Wirth said. The government must provide better regulatory guidance and framework for manufacturers to coalesce around. While its too early to know how exactly the FDA will proceed, Wirth said feasible options include: Requiring manufacturers to report and/or test their device’s security profile prior to pre-market approval; making the reporting of cyber incidents part of the FDA’s existing post-market surveillance program; requiring manufacturers to provide a certain minimum set of security features on their devices, which would likely vary based on device type, risk, software architecture, etc. The FDA will also likely be cognizant of international standards, reflecting the international nature of the industry, and, though the standards won’t necessarily be identical, Wirth said he would expect the trend toward “harmonization” of these types of regulations to continue.
Next, he said the responsibility of manufacturers is twofold: to secure the individual device they are building and to properly communicate the security profile of all their devices to the end user, i.e. the hospital. Once standards are set, new devices should have more robust protection from unwarranted activity, but hospitals will still employ millions of older devices. “With many devices that are being sold and maintained by the manufacturer, [retrofitting or installing a software patch] is a possibility,” he said. “But with other devices, that might not be an option, due to the age of the device or design restraints. Then it’s up to the manufacturer to communicate that vulnerability to the hospital.”
The third component needed to address this problem, according to Wirth, is the health care provider. “Their responsibility is to understand the security capabilities of their devices, but also to build a proper security infrastructure around the device; what we call layered security,” he said. “You’ve got to also monitor your network and protect its perimeter through firewalls. Then it goes all the way down to your door locks and things around the building.”
Wirth also said that he often encounters people who aren’t aware of all the options available to them. “They start with, ‘here are the reasons why antivirus software doesn’t work on a medical device,’” Wirth said. “They then give you three good reasons why antivirus technology doesn’t work — it uses significant resources, needs updates, and you have the risk of false positives. What many people don’t know is that there are other security technologies available that are much more suitable for these problems.” One example: Installing antivirus software —essentially a blacklist — is often outside the realm of possibility for many devices. The list, millions of lines long, is simply too big for many devices. But Wirth said an overlooked alternative to this problem is the inverse of antivirus software — a whitelist, a small list of approved processes and functions. Try to tamper with the predefined protocol, and it will be blocked.
As important as it is for each of these three stakeholders to address the FDA regulations, so to is it important for these groups to collaborate as they do so. “Part of the solution is technical, but the other part is communication: manufacturers, government, and end-users. That has not always happened in the past,” Wirth said.
The FDA’s release signifies both the need to address the problem of medical device security and the need to do so in a unified way. “It’s not anything new,” Wirth said. “It’s just getting a different momentum now. This problem is not going to go away quickly, but it certainly good news that it is being tackled now.”
The FDA published security recommendations and best practices for health care facilities. They included:
- Limit unauthorized device access to trusted users only. Employ user authentication whenever possible; strengthen password protection by avoiding hard‑coded passwords and limiting public access to passwords used for technical device access.
- Develop strategies for active security protection appropriate for the device’s use environment, including timely deployment of routine, validated security patches and methods to restrict software or firmware updates to authenticated code.
- Use design approaches that maintain a device’s critical functionality, even when security has been compromised.
- Develop retention and recovery protocols for incidents in which security has been compromised.
- Monitor network activity for unauthorized use.