Blog & News

This is the first post of our IoT healthcare security series. This blog post summarizes background information specific to healthcare IoT from a security perspective. The fol­low­ing list shows the top­ics of all blog posts in this series. It will be up­dated with the cor­re­spond­ing links once new posts are being re­leased.

1. IoT Healthcare Devices: Background Information
2. Precautions, Considerations and Getting a First Overview on the Scope
3. Hardware Analysis, Vulnerability Scan and Impact Analysis
4. Software and Web Application Analysis and Documentation
   
   

Recent developments in healthcare have resulted in the combination of medical devices and the Internet-of-Things (IoT). With medical devices underlying special regulations and used in very specific contexts, the question arises how security assessments can be performed to address the sector-specific demands. While the results of security breaches in healthcare can be socially or financially devastating or cause serious patient harm, medical device manufacturers and applicants have to weigh these issues up against the many positive effects of digital medical device usage. To contribute to the solution of this issue, a bachelor thesis has been created that provides an overview on technical background information of medical devices and their context of usage, eventually introducing a novel methodology which can be used by security testers as well as medical device developers for security assessments of IoT healthcare devices.

Background Information

This section summarizes important characteristics and regulations of medical devices and their context of usage.

Types and Classifications of Medical Devices

Medical devices can intuitively be separated into three categories:

• Devices for home-usage
• Implantable devices
• Diagnostic and therapeutic devices used only by physicians or other medical staff (e.g. sonographic units, …) and capital medical equipment (e.g. MRT, CT, …)

Medical devices are grouped in four risk classes: Class I, IIa, IIb, III (see 93/42/EEC Annex IX III. Classification[1]). The following diagram depicts the risk classes as defined under the new MDR:

Furthermore, IEC 62304 divides medical device software into three safety classes: A, B and C as shown in the figure below (translated from a blog entry of the Johner Institute[2]):

Risk Acceptability Matrix

The following risk acceptability matrix as defined in ISO 14971 (found in the greenlight guru blog[3]) can answer whether risk levels are acceptable or risk reduction is required:

Challenges of IoT Healthcare Devices

The main challenges of IoT Healthcare devices are:

• Insecure devices can be used as entry points to access networks
• In the worst case scenario, security incidents can lead to severe patient harm, including death[4].
• Some devices may never be taken offline and must remain available at all times.
• Some devices, like implants, are directly connected to patients.
• Maintenance can cause malfunctions. Medical devices should be updated as seldom as possible.
• Health-related data is considered very sensitive under the General Data Protection Regulation (GDPR), and patient records can — unlike most other personal data — not be changed after a security breach like bank account numbers or credentials. As a consequence, health data should be as well-protected as possible.
• IoT Healthcare devices are used by non-technical and non-security aware individuals or institutions and commonly run in publicly available places. Sometimes, risks are addressed by installing cameras or attaching RFID tags to the devices, but eventually, security testers should assume all devices are physically accessible since of the low security awareness of medical personnel (‘we trust our patients’, anonymous quote from a doctor)
• Security is mostly of low priority for healthcare services
• Acceptance of security measures: a security measure that will complicate or slow down a process will — with good reason — be rejected by medical personnel and applicants. Therefore, security measures must be as easy and effortless for its applicants, as possible, and should — whenever reasonable — be the default setting, allowing secure device usage “out-of-the-box”
• Medical devices can be connected to heterogeneous, old or unpatched systems. This might also happen on coincidence (e.g. a housekeeper pulling the cable and reconnecting it to the wrong plug-in position). Additionally, many hospitals have BYOD-policies (‘bring your own device’). It must be expected that medical devices run in a vulnerable network, and thus, any device needs to be secured as best as possible, perchance taking a Zero Trust-approach.
• Deficient communication between IT and medical personnel leads to not properly scheduled maintenance at some places. Therefore, system updates should avoid affecting device performance, if possible.
• For some manufacturers, the sole focus of device development lies on medical functionality. While this may, in the end, maximize the positive effect on patient treatment, this implicates a lack of long-term security support or security-aware development and architecture for many devices and a demand to develop security models for healthcare devices.
• Security patches may require a new admission process or manufacturer’s approval (depending on the region), which can slow down the fixing of vulnerabilities significantly and creates a huge overhead of work.
• Applying official patches or upgrades may not be possible since they might make the device inoperable.
• Patients are almost completely uninformed about the devices used on them in hospitals and can hardly ever reject their usage due to security concerns. Additionally, patients often must rely on these unknown devices due to a lack of suitable alternatives and the urgent nature of health-related problems.
• The healthcare system may be subject to warfare, politically motivated groups and cyber criminality since being part of the critical infrastructure.
• Malware can be injected into medical devices before market release, sometimes through external libraries. Therefore, security measures should be integrated into the production process and third party code or hardware be tested for security, either.
• Remote control of medical devices is not only used to improve the effectiveness with which medical devices are programmed (in use), but also to enable surgeons to maintain a more sterile environment during surgery when it comes to implants. Lowering the radius in which a device functions, while increasing the device’s security, can negatively impact the patients' safety.
• The replacement of a defect implant requires surgery, risking injury or even death, and should be avoided at great lengths.

Contradicting Goals

Many medical devices, for example hearing aids, need to be small, light-weight, comfortable to wear, inexpensive, long-living (battery power, …) or easy-to-use. Therefore, medical device hardware can be strongly limited in terms of processing power, device storage and memory. These limitations can contradict with security functions, like cryptography or logging.

From a medical point of view health records should be as widely available as possible and allow emergency access by break-glass functions. From a privacy point of view this raises many questions about how data can be properly secured under these conditions. Additionally, regarding electronic patient records, the question is raised if access to health data can be denied for less costly devices with fewer security features without further compromising social justice.

Sector-Specific Threats

In their February 2019 breach insights[5], the Beazley Breach Response Service has released statistics on causes of incidents related to cyber incidents. This data shows that, while all sectors are threatened by hacks and malware, the healthcare sector is especially threatened by accidental disclosure and insiders. With 41% of all incidents, healthcare entities reported the highest number of incidents.

As pointed out in the Cyber Security Report 2020, the healthcare sector has still been one of the primary targets of ransomware in 2019. Even worse, ‘the targeted approach almost entirely replaced the mass distribution method for ransomware’.

As was stated in the 2019 HIMSS Cybersecurity Survey[6], e-mail remained the most frequent initial point of compromise, with healthcare entities achieving high phishing clicking rates (58% in total). With 25%, human error was the second-most initial point of compromise, while in 5% of the cases, medical devices were the initial point of compromise.

Three out of ten threat actors of significant security incidents in 2019 have been identified as benign actors (such as negligent insiders, vendors or consultants). Half of the incidents were caused by so-called bad actors like online scam artists (28%) and hackers (11%). The other threat actors were social engineers, malicious insiders, nation state actors and hacktivists.

The Health Care Industry Cybersecurity Task Force has listed possible risks of medical devices in their report on improving cybersecurity in the health care industry in 2017 (see table below), stating that the susceptibility of health care information to cyber threats has become very evident in the last few years with identity theft, ransomware, and targeted nation-state hacking becoming more frequent and extensive.

Technical Features of Medical Devices

Frequency bands

The following table shows the frequency bands used by medical devices for communication in the U.S.:

In the EU, medical devices can use any ISM band between 150 kHz to 80 MHz, as regulated in IEC 60601, however, medical devices can also use other frequency bands, especially older devices or if frequencies are used for diagnosis or therapy.

Sensors

Many medical devices use sensors for measurements. Proximity-based attacks could target these sensors, which are usually not sufficiently protected.

Operating systems

In 2020, the majority of medical imgaing devices ran on unsupported systems (83%), most of them running a Windows OS[10].

Databases for Medical Devices

There are several databases unique for medical devices:

• AccessGUDID (Global Unique Device Identification Database)
• MAUDE (Manufacturer and User Facility Device Experience)
• DIMDI (German, charges fees for access)
• EUDAMED (EU, in development)

However, none of these databases provided sufficient technical information as would be needed for security assessments.

Recently, the FCC database EAS, which provides information on radio-frequency-emitting devices licensed in the U.S., and inofficial sources provide the most accurate technical information.

Regulative Institutions, Acts and Norms

This section gives an overview on the institutions, acts and norms that regulate medical device security in any form.

Germany

The institutions that took responsibility for medical device security are:

• Federal Office for Information Security (BSI)
  • TR-03161 (security, mobile eHealth applications)
  • TR-03154, TR-03155, TR-03157 (Konnektor)
  • TR-03160, TR-03143, TR-03144 (security, electronic health card)
• Federal Institute for Drugs and Medical Devices (BfArM)
  • regulate medical products in general, do not occupy themselves with cybersecurity

The BSI has released the above listed technical guidelines directly addressing healthcare. Other interesting guidelines were released addressing topics like cryptography. We can expect further technical guidelines addressing the security of medical devices from the BSI in the future. Furthermore, the following legislation applies to medical devices. However, no technical information on medical device security could be found in these documents.

• Act on Medical Devices (MPG)
  • instance of European MDD
  • will be replaced by the MPDG (German Medical Device Act) in 2021 presumably
• Safety Plan for Medical Devices (MPSV)
• PDSG (medical patient data protection act) protection within the German Telematics infrastructure

EU

European guidelines give EU member states directions or ‘recommendations’ how a law should be deployed on a national level. The following guidelines were found interesting during research:

• 90/385/EEC (active implantable medical devices)
• 93/42/EEC (Medical Device Directive (MDD))
• MDR (Medical Device Regulation), which will replace the MDD (delayed due to Sars-CoV-2)
• MEDDEV guidance documents (guide manufacturers, not mandatory)
• EU 2016/1148(network security, national strategies)
• European Union Agency For Network And Information Security (enisa): Baseline Security Recommendations for IoT in the context of Critical Information Infrastructure

In a brief summary, most regulations demand safe and secure medical devices, however, a lack of clear instructions how to handle the contradiction between security and safety is missing.

Norms

The following norms are of interest when dealing with the cybersecurity of healthcare devices:

• ISO 13485 (medical, quality management system, manufacture)
• ISO 14971:2019 (medical, risk management)
• ISO/IEC 27001 (Information Security Management Systems (ISMS))
• ISO/IEC 27002:2013 (ISMS, practice recommendations)
• ISO/IEC 27034 (software, IT security)
• ISO 27799:2016 (medical, ISMS, checklist)
• IEC 60601 / EN 80601 (medical, fundamental safety)
• IEC 62304:2006 (software, life cycle processes, development, risk management, maintenance)
• IEC 62304:2017 (software, risk levels)
• IEC 62443 (IT security of industrial automated processes, commonly used by medical device manufacturers)
• IEC 80001 (medical, life cycle of IT infrastructures incorporating medical devices)

FDA

Medical devices traded in the U.S. undergo marketing approval by the FDA. The FDA has released four cybersecurity guidances:

• Cybersecurity for Networked Medical Devices containing Off-the-Shelf (OTS) Software
• Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices
• Content of Premarket Submissions for Management of Cybersecurity in Medical Devices
• Postmarket Management of Cybersecurity in Medical Devices

The first of the above listed guidelines states, that no further FDA review is needed after a software patch that addresses a cybersecurity vulnerability, while the second divides medical devices into three categories regarding the patient harm: major, moderate and minor. The third guidance splits the responsibility to maintain medical device security between stakeholders, including health care facilities, patients, providers, and manufacturers of medical devices' and demands a reasonable balance of security and usability, stating that no security control should unreasonably hinder access to a device intended to be used during an emergency situation. Manufacturers are encouraged to provide a cybersecurity documentation to their premarket submission. This guidance includes a list of recognized standards dealing with medical device security. The forth guideline deals with risk management and encourages the collaboration between manufacturers and Information Security Analysis Organizations (ISAO).

IT Security Guideline (Johner Institute)

A collaboration between the Johner Institute, TÜV SÜD and Siemens Healthcare GmbH has resulted in an ongoing and yet not officially released guideline[9] with the purpose to guide manufacturers in the interim period while there is already the demand for better IT security in healthcare devices and until more detailed norms and standards for IT security in medical products are developed. Its main focus lies on the security of the product itself regarding the patients' safety, and not the security of the organization. The need for a breaking-the-glass policy is stressed out as well as an understanding of the recent security levels of medical devices in use versus the security level an IT security expert would expect. The authors suggest accepting a step-by-step improvement of manufacturers regarding the security of their products to rather help them develop their products towards better security instead of discouraging them with strict demands since the authors believe it is still better for the patients' health to have an insecure product than no product at all. Security shall be addressed not only during the test phase, but in the product’s whole life cycle.

State of the Art Security

Most acts and even guidelines refer to state-of-the-art security. An 80 pages long document trying to keep up-to-date with modern security could be identified: Guideline: State of the art in IT security [8].

Privacy

In a summary, these are the implications of the EU’s GDPR and U.S. HIPAA:

• General Data Protection Regulation (GDPR)
  • applies to any data feasible to (indirectly) identify a person
  • emergency limitations regarding the disclosure and processing of health-related information and information of public interest
  • no data may be raised and processed without purpose and informed consent
  • data raised must be minimal
  • privacy by design
  • personal information should be protected by encryption or pseudonymization
• Health Insurance Portability and Accountability Act (HIPAA)
  • The U.S. have no equivalent to our GDPR in general
  • primary healthcare providers, health plans and healthcare clearinghouses are covered by this act, but not health data in general
  • the act is divided into a Privacy Rule and a Security Rule
  • The main principle of the Privacy Rule is ‘minimum necessary’
  • It follows from the Security Rule that covered entities need to secure the medical devices they use for diagnostic or therapeutic purposes to be able to fulfill these requirements.

Next Post in Series

• The next post in this series ‘‘Precautions, Considerations and Getting a First Overview on the Scope’’ will be published soon.
  Follow us on Twitter , LinkedIn , Xing to stay up-to-date.

Credits: The elaborations and novel methodology are results of a Bachelor’s thesis by Melissa Loos created at SCHUTZWERK in collaboration with Ulm University.

References

• [1] Legislation: 93/42/EEC - Medical Devices Directive (MDD)
• [2] Blog: Johner Institute - Sicherheitsklassen gemäß IEC 62304
• [3] Infographic: Risk Management for Medical Devices as defined by ISO 14971 by greenlight guru
• [4] Article: Patient dies after Ransomware Attack (german, 2020-09-17))
• [5] Report: Beazley breach insights - February 2019
• [6] Report: 2019 HIMSS Cybersecurity Survey
• [7] Website: FCC
• [8] Guideline: State of the art in IT security
• [9] Guideline: IT Security Guideline
• [10] Report: 2020 Unit 42 IoT Threat Report
• Title Image by Anna Shvets on Pexels

~ Melissa Loos