Clarkston Consulting https://www.facebook.com/ClarkstonConsulting https://twitter.com/Clarkston_Inc https://www.linkedin.com/company/clarkston-consulting http://plus.google.com/112636148091952451172 https://www.youtube.com/user/ClarkstonInc
Skip to content

Medical Device Vulnerability

The Department of Homeland Security is currently investigating dozens of cybersecurity cases related to medical devices and their potential for exploitation. The focus is on finding and rectifying vulnerabilities. As medical devices become more complex, hardware and software control systems have become more prevalent. But even though the networks and information technology systems that devices interface with are more sophisticated, many believe they are still vulnerable.

Medical equipment today supports WiFi and Bluetooth communication, which ideally facilitates more efficient transferring and monitoring of patient information. However, significant security concerns regarding network-connected devices were brought to the medical community’s attention when two noted experts, Jay Radcliffe and Barnaby Jack, discovered that certain insulin pumps with wireless connections had security flaws that would allow them to be hacked via unauthorized remote control.

Such computerized devices are designed to continuously deliver anesthetic or therapeutic drugs into a patient’s bloodstream, and can be programmed remotely through a health care facility’s ethernet or wireless network. If they gain access, hackers could deliberately manipulate the amount, or timing, of drug released by the device—which could obviously cause serious harm to patients. In addition, some devices are shipped with preconfigured default passwords such as “password” or “admin”; so, if not properly secured or updated, they may be more prone to breaches.

Cybersecurity firm TrapX recently revealed three cases where hospitals were affected by data infringements, each after medical devices were infected with malware backdoors to move laterally within the healthcare network. In all three cases, the hospitals were unaware that these devices—a blood gas analyzer, a picture archive and communications system (PACS) and an x-ray system—were infiltrated with malware. The devices were spotted when TrapX installed its sensor-based technology in the hospitals.

In the fall of 2014, the FDA convened its first cybersecurity conference for medical devices. Following the meeting, Reuters reported that Homeland Security officials opened investigations into suspected cybersecurity flaws in medical devices.

In February 2015, the FDA finalized guidance in which it would remove requirements for agency review and approval for medical device data systems (MDDS), medical image storage devices, and medical image communications devices that created, transmitted or stored patient information. In 2011, the FDA classified these as “high risk”; this guidance reclassified the devices, stating that they pose a low risk to patient safety. In its policy guidance on MDDS, FDA states that it does not intend to enforce compliance with the regulatory controls applicable to these devices, as long as the devices meet relevant definitions outlined in FDA regulations.

In May 2015, the Institute of Electrical and Electronics Engineers (IEEE) published cybersecurity guidelines for medical device manufacturers. The report, “Building Code for Medical Device Software Security,” includes ten elements to consider when developing medical device software, which are listed below.

  • Elements intended to avoid/detect/remove specific types of vulnerabilities at the implementation stage (A)
  • Elements intended to assure proper use of cryptography (B)
  • Elements intended to assure software/firmware provenance and integrity, but not to remove code flaws (C)
  • Elements intended to impede attacker analysis or exploitation but not necessarily remove flaws (D)
  • Elements intended to enable detection/attribution of attack (E)
  • Elements intended to assist in safe degradation of function during an attack (F)
  • Elements intended to assist in restoration of function after attack (G)
  • Elements intended to support maintenance of operational software without loss of integrity (H)
  • Elements intended to support privacy requirements (I)
  • Desired characteristics of the building code, for example, standard names use, building code maintenance over time, and scope (X)

While device manufacturers and hospitals need to properly address cybersecurity concerns, clinicians should also be aware of security threats and take necessary precautions to prevent or limit data breaches. Patients using these devices should also be informed of potential risks, and should be instructed to immediately report unusual device activity that may indicate that it has been compromised.

Tags: Data Integrity
RELATED INSIGHTS