With the proliferation of highly computerized and networked systems for healthcare, it’s not unexpected that they’re opening themselves up to new vectors for invasion of privacy—including the automated type presented by malware. Worse, medical information is confidential and valuable to bad people, not to mention that malware on sensitive medical equipment could lead to serious injuries. On this subject, Kevin Fu, a leading expert on medical-device security and computer science at the University of Michigan and the University of Massachusetts says the problem of medical malware is clearly on the rise.
According to an article run in MIT’s Technology Review, the increase in reported malware infections could have dramatic effects for the medical community.
Part of the problem is that the culture of medical equipment and the nature of computer networks collide in a very bad way: medical equipment is heavily regulated such that anything added to it must be vetted first through numerous agencies but advances in computer networks have given the ability for them to report to computers. As a result, manufactures produce new products that are open to attack, but are unwilling to update or fix them once they’re in the field because of that culture of regulation.
In a typical example, at Beth Israel Deaconess Medical Center in Boston, 664 pieces of medical equipment are running on older Windows operating systems that manufactures will not modify or allow the hospital to change—even to add antivirus software—because of disagreements over whether modifications could run afoul of U.S. Food and Drug Administration regulatory reviews, Fu says.
As a result, these computers are frequently infected with malware, and one or two have to be taken offline each week for cleaning, says Mark Olson, chief information security officer at Beth Israel.
As a result, the FDA is reviewing its regulatory stance on software and patches for networked medical equipment. In many ways, this is a necessity and may give rise to a market niche of external networking technology designed to detect and defend networked medical technology from malware.
Mark Olson from Beth Israel adds that virtually any equipment currently can become the target of malicious automated software.
“We also worry about situations where blood gas analyzers, compounders, radiology equipment, nuclear-medical delivery systems, could become compromised to where they can’t be used, or they become compromised to the point where their values are adjusted without the software knowing,” he said. He explained that when a machine becomes clogged with malware, it could in theory “miss a couple of readings off of a sensor [and] erroneously report a value, which now can cause harm.”
Often this software isn’t even directed towards sabotaging or even using the medical equipment as it is—as a result, we need not worry about a medical industry version of the Flame virus—instead most infections turn the equipment into zombies for botnets. The result can be the same, however, when the botnet decides to launch into action to spam or DDoS a target and it eats up the processor cycles on the equipment or floods the hospital network with noise.
Greater attention is needed from manufacturers and security professionals
Even though the FDA released guidelines in 2009 telling medical equipment manufacturers and hospitals to work on isolating their equipment from the Internet and each other using carefully managed firewalls and protocols, many manufacturers took this as admonishment not to issue patches. As a result, it may be important for the FDA to simply step forward and draft policies that require manufacturers to work with security experts to build systems that can be integrated easily with current firewall technology.
Since hospitals benefit greatly from networking mission-critical equipment for diagnostic reasons, it stands to reason that they will do so even if their equipment is behind the times on antivirus protection. As a result, there’s two ways that hospitals can combat these threats immediately: (1) security policies on internal networks that make use of partitioning and (2) firewalls to prevent penetration and training for both IT and medical personnel who use the networked equipment.
For the first part, any hospital-based IT department could do this like they would under any enterprise environment by partitioning internal networks away from external networks and separate databases, equipment, and mobile devices (such as tablets, etc.) from each other with firewalls. A basic security policy including log ins, device screening, and intrusion detection would greatly reduce the total damage that malware could do if it managed to infect any given device.
For the second part education is the key. As we already know from learning the lesson of the Kobayashi Maru the culture of the users has a great impact on the spread and damage malware can cause inside a network. As a result, any user who has a mobile device or directly uses sensitive equipment needs to be trained not to circumvent IT department security policies by using sensitive equipment to contact the outside Internet—i.e. no browsing the Internet on a computer connected to an MRI, even if that’s somehow possible—and when using Flash drives or other portable devices they should never be taken out of the secure partitions.
Putting protocols in place and training personnel would work well to prevent potential penetration and it would also quarantine infections extremely quickly to specific portions of the network. Add in intrusion detection and antivirus watching the network and infected equipment could be detected quickly and either taken offline or quarantined (as needed, being that much of this equipment is mission-critical after all.)
Latest posts by Kyt Dotson (see all)
- Domino’s teams up with Flirtey for drone pizza delivery in New Zealand - August 25, 2016
- Bitcoin Weekly 2016 August 24: Bitstamp turns 5 Ledger wallet giveaway, CEO of CHBTC interview, final Silk Road BTC auction and Bitcoin Core 0.13.0 - August 24, 2016
- Blockchain.info ‘down’ briefly due to an unexpected DNS problem - August 22, 2016