FBI Notice Underscores Cyberthreats Posed by Medical Devices and IoMT – Risk Management Can Help
On September 12, the FBI released a private industry notification entitled “Unpatched and Outdated Medical Devices Provide Cyber Attack Opportunities.” The notification underscores how a growing number of vulnerabilities in medical devices and Internet of Medical Things (IoMT) assets can be exploited by threat actors to “impact healthcare facilities’ operational functions, patient safety, data confidentiality and data integrity.”
The FBI notification follows the discovery of significant vulnerabilities this year affecting medical devices and IoMT such as infusion pumps, medication dispensing systems and electrocardiographs. There has also been a wave of ransomware attacks targeting healthcare organizations in the past years – some of which have rendered medical devices unusable.
In this blog post, based on a full report, we discuss why medical devices are vulnerable and provide mitigation recommendations for healthcare delivery organizations (HDOs).
Why are medical devices vulnerable?
The FBI notification cites four common issues that lead to vulnerabilities being found or remaining unpatched in medical devices. We have previously researched each of these issues:
- Devices used with a default configuration are easily exploitable. Many medical devices have default open ports or credentials when they are configured by a manufacturer, and sometimes these are not changed when deployed in HDOs. In our Access:7 research, we identified medical devices that were shipped with a configuration agent still present and whole product lines sharing hardcoded credentials for remote access.
- The long lifespan of medical devices allows threat actors ample time to find and exploit vulnerabilities.Medical devices are used for 10 to 30 years, which not only provides time to find vulnerabilities but also means that the code running on them may be decades old. In our NUCLEUS:13 research, we found vulnerabilities on a software component used in medical devices since 1993.
- Devices require special upgrade procedures that delay patching. Due to specialized software and firmware running on many medical devices, the patching procedure is not as easy as in a traditional computer. Not only is applying patches more difficult but the mere existence of patches is not guaranteed for vulnerabilities affecting third-party components. This is an issue that we discussed at length throughout Project Memoria.
- Devices were not designed with security in mind. Many of the protocols running on these devices do not include basic security controls such as authentication and encryption. We have recently discussed the issue of insecurity by design in operational technology as part of OT:ICEFALL, but we have also demonstrated in the past how insecure protocols in healthcare allow attackers to leak patient data, tamper with diagnostic results, disconnect a patient monitor and even change a patient’s vital readings on the network.
Hospital privileged networks don’t protect insecure medical devices
A primary reason for the persistent insecurity of medical devices is the belief that those devices are not exposed to cyberattacks because they can only be accessed from inside a hospital’s privileged network. The fact that many remote ransomware attacks have spilled over to medical devices and related information systems is proof enough that this assumption is not true anymore. Beyond reported attacks, we have shown persistent segmentation issues in healthcare organizations, where several unrelated types of devices with very different criticality levels are present in the same network segments, providing a path for attackers to reach medical devices.
In truth, often medical devices are not connected directly to the internet, but they communicate with information systems that are exposed online. For instance, imaging modalities such as CT scanners communicate with picture archiving and communication systems (PACS), which in turn communicate with radiology information systems (RIS). Although CT scanners are not found online, many PACS and some RIS are and thus may provide a path for attackers to reach the most sensitive devices.
Mitigation recommendations
The FBI notification proposes five categories of mitigation actions for vulnerable medical devices:
- Run endpoint protection such as antivirus and endpoint detection and response (EDR) software on devices that support those technologies.
- Use complex unique passwords per device and limit the number of login attempts.
- Maintain an inventory of medical devices and use it for risk assessment.
- Follow security advisories from vendors and run vulnerability scanning on medical devices.
- Implement security training for employees to identify and report problems such as insider threats, phishing and social engineering.
The notification also encourages HDOs to “take other mitigation precautions, such as isolating the device from network or auditing the device’s network activities.” For more detailed guidelines on implementing segmentation for specific device types such as PACS, electronic medical record (EMR) systems and infusion pumps, see NIST’s security guidance publications. For general guidance on risk assessment of medical devices, see the recent NIST SP 800-66.
Network segmentation is extremely important considering our findings about exposed systems. The FBI’s recommendations, especially segmentation and network monitoring, should apply not only to medical devices but to every device on your organization’s network. As we showed in previous posts and as the Health Sector Cybersecurity Coordination Center (HC3) recently discussed, threat actors can leverage those other types of devices to gain access to or impact healthcare organizations.
Device-centric risk management for medical devices
Device-centric risk management (DCRM) is one of the most effective security approaches for medical devices and IoMT. Forescout’s CyberMDX DCRM solution provides cybersecurity “layers” that protect each device, driving remediation and mitigation directly on your medical and IoT assets as well as the broader network.
- On-device protection – With DCRM, you prioritize the devices most at risk and then apply recommended actions to remediate or mitigate the associated cyber risks. For example, you may choose to focus on remediating devices with known credentials issues or known exposed RDP ports and understand what the expected risk reduction is in each case. As you continue to identify and remediate these known issues, the corresponding risk decreases.
- On-network protection – The medical devices sit on the network, so you’ll want to allow only authorized traffic to flow to and from them via allow-list policies. You can add yet another layer of protection by restricting certain devices from communicating with one another through blocklist policies.
- Perimeter protection – Through these two layers (on-device and on-network), you have essentially built an internal firewall around each device. But DCRM adds a final layer of protection from the perimeter. You can further prevent unauthorized access by enabling next-generation firewalls (NGFW) to apply automated blocklist policies directly to the devices themselves.
DCRM can significantly reduce the risk to your hospital network – even if a breach occurs via phishing or ransomware attack. By implementing multiple layers of security, the DCRM approach is inherently more robust than focusing security and risk management solely on the network layer.
Of course, there is no silver bullet – the cybersecurity layers must work together to reduce exploitation of the devices. And while DCRM significantly mitigates the risk, the potential for a breach is always present.
Vedere Labs found more than 7,000 exposed medical devices and systems on the internet, including PACS, healthcare integration engines, EMRs and medication dispensing systems.