Network Security

Credit card numbers, patient data, social security numbers. These days, this sort of data is uploaded to hospital networks with increasing frequency, presenting a tantalizing prospect to today’s modern hacker—a group no longer limited to computer-savvy youth looking for a taste of fame. “Hacking now is really a business driven by organized crime,” says Axel Wirth, national health care solutions architect with information security company Symantec Corp in Mountain View, Calif.

“Rather than looking for macro-distribution, we now see micro-distribution—targeted malware with a specific purpose,” Wirth says. “The malware is intelligent, it’s self distributing, and it has the ability to receive commands from remote servers with the goal to obtain as much as information as possible without being detected.”

This new breed of sophisticated cyber threat can cripple not only unsuspecting or poorly secured hospital networks, but nearly any system plugged into them as well, including medical devices. “What we have seen in the health care space is medical devices being the casualty of an attack,” Wirth says. “They’re not targeted, but because they have the same operating system under the hood, they’re basically drive-by casualties.”

The issue is of particular concern to biomeds and IT staff for a number of reasons. Principally, medical devices tend to be weak spots in a hospital’s network, making them more susceptible to damage. “Medical devices 5 or 8 years ago were not designed with today’s cyber threats in mind,” Wirth says. “They traditionally have weak protection.” Couple this already vulnerable equipment with older, rarely updated operating systems and the problem intensifies. “The problem is the security risk those old operating systems pose when they do not get patched properly,” Wirth says.

Hospital tendency to standardize practices by creating a homogenous environment of similar devices across the facility for training and maintenance purposes can also unwittingly add fuel to the fire. “Once one device gets infected, it very quickly spreads to like devices, and therefore it affects the larger enterprise, rather than just a single device,” Wirth says.

Closer to home, IT staff also fret about the internal threat. Plugging a USB device into equipment with the intent to upload new configuration data or a patch can potentially corrupt data or expose the entire network to harmful viruses. “Before you know it, that infection then uses that device as an entry point to infiltrate the larger network,” Wirth says. “So rather than having a cyber attack outside-in, via e-mail or Web access, you have an attack which is rolled up inside-out.”

Vendor Machines

Knowing these weak spots exist is not always enough to allow IT to patch them up, since security and updates are, for many pieces of medical equipment, the responsibility of the device’s vendor. “In our environment, I view these devices that are not managed by IT—let’s call them vendor-managed systems—as the ones I worry about the most,” says John A. Christly, manager of IT security at Memorial Healthcare System, Florida’s fourth largest hospital system. “If [vendors] don’t bring them into our fold, then our patching, antivirus, group policies, or our network rules don’t apply to them.”

For these systems, hospitals must rely on vendors to validate and release crucial security patches, which, frustratingly, can take time to develop and deploy, as medical devices are highly regulated. Change-control (and testing) is mandated to thoroughly assess any changes for impact on safety and effectiveness. “Many times, changes in a device can cause other parts of the device to malfunction,” says Nick Mankovich, senior director, product security and privacy with Philips Healthcare, Briarcliff Manor, NY. “So you really have to have a rigorous quality system to make sure what you’re fixing does not introduce any more risks.”

Whether or not the hospital or the vendor is responsible for keeping a given piece of equipment up to date ultimately goes back to the original agreement as negotiated with the vendor. “The term ‘responsibility’ is a tough one, but clearly when a hospital buys from us, we try to have a clear agreement and understanding of what will happen with those patches,” Mankovich says. “If in fact a system goes down, are we responsible? That’s up to the terms of sale and the existing service agreement.”

Communicating Effectively

Amid concerns about validating the safe and effective use of medical devices on hospital networks, industry professionals from both sides of the issue, vendor and hospital, have drafted a new international standard, IEC 80001-1, which in part covers the interplay between these groups concerning the release of security updates to end users in a timely fashion.

“The big issue in terms of cyber security is how quickly can we make those kinds of changes and who is authorized to make them,” says Sherman Eagles, a co-convener of the ISO and IEC working group that is developing the standard. “If the medical device needs to be modified, then how quickly can the device manufacturer say, ‘Yes, this can be done without impacting the safety of using our device’?”

The standard largely reaffirms the status quo regarding responsibility, but it spells out specific directives for both hospitals and vendors to help improve the lines of communication. “The standard makes it clear that the hospital owns the network, obviously, and they have the overall responsibility for it,” Eagles says. “The hospital is really responsible for doing risk management for the network.”

When performing this assessment, the standard suggests taking into account three key properties: safety, mission effectiveness, and data and systems security. “Looking at those three things, you need to assess the risks as you make changes to your network that may impact those three key properties,” Eagles says.

The standard lays out responsibilities for vendors as well. According to Eagles, vendors should provide pertinent information and collaborate with hospitals to facilitate the risk management process. “There are some specific things that the manufacturer is required to provide as part of their documentation with their device,” he says. “Then there’s the idea that the hospital and the manufacturer will probably want to have some kind of an agreement so that the hospital can acquire additional information that isn’t typically made public by the device manufacturer.”

Although the standard will not change the current, varying dynamic of vendor or hospital responsibility for device security, it may help spell things out more clearly for customers up front, according to Mankovich, who contributed security input to the standard and is part of the core standards development team. “I think what will change is perhaps the clarity of communication between the manufacturer and the health care organization about what our policies are ahead of time,” he says. “It will push us to disclose more about the risks associated with connecting the devices, and I think we’ll have to develop new documentation that consolidates a lot of the information about security risks in one place.”

To simplify the collaborative approach and get teams talking, the 80001-1 team compiled a set of four technical guidance documents to be released alongside the standard. Some of the documents will feature step-by-step guidance biomeds and IT staff can use to apply the standard’s principles in practical settings—including security. “Read through them and ask each other questions,” Mankovich suggests. “And then talk about the practicality. Turn that dialogue into a first-steps proposal to the CIO/COO/CFO of how to improve safety, effectiveness, and security.”

Taking Action

While the standard wraps up, biomeds should start sharing information with IT now, before an attack occurs. “There are some logistical challenges, but I think that for the clinical engineers, incorporation with IT is critical,” Wirth says. It’s important that they both “understand their assets, what’s on the network, and what is the configuration of what they have on the network.”

In the event of a security breach on a medical device, biomeds should also make it a priority to alert the device manufacturer, regardless of the vendor’s role in managing its security. “Even if you’re not under service contract, contact the manufacturer,” Mankovich says.

In the end, this improved communication may help to speed up the problem’s resolution. “We would want to know what happened, how it happened, and we would want it as a data point in a larger pattern, if nothing else,” Mankovich says. “We might also want to understand if maybe we haven’t deployed the right patch as quickly as we thought we had.”

---

Stephen Noonoo is the associate editor of 24×7. Contact him at .