Medical Device (IoMT) Cybersecurity 101
The “Internet of Medical Things” or IoMT is a growing market with connectivity being added to existing medical devices in addition to all the new applications and uses being developed by a wide range of companies. Connected medical devices can save costs for patients and healthcare providers alike by improving the efficiency of data processing, providing real-time input on patient conditions, and even allowing patients to vacate much needed hospital beds by moving to home treatments.
Common use cases include patient monitoring, testing and imaging, patient identification and data processing, and various medication dispensing systems from infusion and smart insulin pumps to medicinal marijuana inhalers. Connected medical devices even allow doctors to diagnose and treat patients without being in direct contact with them, which is especially important during the COVID-19 pandemic. Some applications involve smart medical devices screening people's symptoms before they opt for a doctor’s visit, while in other cases, healthcare workers can use connected medical devices for remotely monitoring vitals for isolated patients.
Other connected devices help with handling tasks related to the medical supply chain, making data processing easier. These range from smart inventory tags that are little more than RFID badges with better connectivity, to data terminals which plug into the complex interconnected backend data systems used by healthcare providers.
As more device classes are brought online, often with little time given to security considerations, the IoMT cybersecurity situation is becoming a point of concern for regulators, customers, security experts and medical device vendors alike. Security vulnerabilities in medical devices can cost lives, incur millions in remediation efforts, and result in ransomware attacks where hackers compromise patient data and even endanger patient safety. We examined some of these developments and incidents in a recent blog and lately the pandemic has attracted even more hackers looking to capitalize on the rise in connected devices.
In this article, we look into some considerations which differentiate the medical device field from other verticals. We will focus on cybersecurity as it applies to patient safety, with only a mention of the related privacy concerns. We then examine the different standards which apply to this vertical and describe some of the best ways to address the resulting compliance needs with automated solutions.
Internet of medical things cybersecurity
Connected medical devices follow the same established design patterns as other embedded or connected device verticals, namely:
- Constrained endpoint devices are small embedded devices with medical sensors (such as thermometers) and/or actuators (such as medical dispensers and pumps). Due to their limited size and internal resources, they typically do not have Internet connectivity of their own, and instead connect to a local gateway device over short-range communication protocols, predominantly Wi-Fi and Bluetooth (although infrared, short-range radio protocols over 802.15.4 and similar are also used). Some of these devices run on batteries and have barely enough CPU power to do proper cryptography, making them difficult to secure, which often leaves them open to attacks.
- Full-featured appliances and gateway devices are medical products with an independent connection to the Internet and decent-to-high processing power. They are typically plugged into mains power and have no major constraints with respect to the cryptography or security features they can run. Some even use stock operating systems like those used in regular PCs, such as embedded and regular variants of Linux and Windows. For example, gateways are dedicated devices that concentrate and pass on communications from weaker endpoint devices such as those described above. Other examples include powerful endpoint medical devices, such as MRI imagers and CT scanners, which have significant power and computing resources and can communicate directly to the service backend.
- Backend devices are the servers and cloud services which make up the interconnected data backend where medical data is stored, processed and provided to patients and caregivers. For the most part, these are conventional PCs, cloud and mainframe machines. Since their operation and security are in no way specific to the medical vertical, they are out of our scope for the purpose of this article.
The thing that makes cybersecurity for medical devices different from other industries is the inherent access to sensitive data that these products require, and the effect they can have on patient safety. This directly results in a tighter regulatory landscape which includes privacy regulations to protect patient data and safety regulations regarding functional requirements. This is a rapidly growing concern which has brought about considerable government and industry activity, resulting in new technical and procedural standards being created in this area. Compliance with some of these standards is now mandated by government regulations, while in other cases it helps vendors compete against others in the same market.
Below we examine the considerations related to privacy and safety, and then continue to a discussion of some of the relevant standards.
Privacy and sensitive data
Medical data is sensitive because it can reveal personal conditions – diagnoses, measurements and treatment plans – which makes it valuable for various data collecting and processing parties. Accordingly, regulators in the US, EU, and worldwide have stepped in to impose privacy regulations.
Collection, processing, retention, and sharing of medical data is subject to a different set of policies and restrictions from financial, personally identifiable and other types of sensitive data. Since the focus of this article is on cybersecurity rather than privacy, we will only mention the US HIPAA Privacy Rule which, according to the official description, “establishes national standards to protect individuals' medical records and other personal health information and applies to health plans, health care clearinghouses, and those health care providers that conduct certain health care transactions electronically.” Manufacturers and operators of medical devices which collect, process and transmit sensitive medical data can be subject to enforcement actions if they violate HIPAA regulations.
In many cases, medical devices are not just collecting data and feeding it to an upstream server, but also actively involved in applying the treatment. For example, a medical inhaler has to carefully portion out the active substance according to a treatment plan, in order to have the desired effect; and an insulin pump has the potential to cause severe damage if it administers the wrong dose. Even measurements collected using medical devices without actuators can still have an indirect effect on treatment.
Safety considerations play an important role in other market verticals where embedded devices are rapidly adding connectivity. For example, in the automotive market, where harm to the vehicle’s driver, passengers and their surroundings is a serious concern; and in the industrial sector, where concerns of harm to equipment operators, damage to the environment, and the continued operation of critical infrastructure are of critical importance. It is not surprising that patient safety concerns play a central role in product risk analysis for medical devices, including functional, safety and cybersecurity aspects; and this in turn affects product requirements.
In the medical device industry, requirements related to patient safety and the avoidance of patient harm come first and foremost, even to the possible detriment of other cybersecurity requirements. In risk assessment, threats are normally classified according to the following scale:
- Low - no threat of damage to health
- Medium – threat of limited injury or patient harm
- High – threat of death or serious injury
Whereas in many product security assessments risk analysis would deal more with how much control an attacker can have over a device, for medical devices it has more to do with side effects on the physical world. Of less concern, for example, are patient monitoring stations which have been compromised by hackers and are now sending out spam messages while still providing correct medical data, or medical pumps which have been hijacked to participate in a DDoS botnet but still properly perform their main intended function. It would be much more troubling if attacks against these devices caused them to make wrong diagnoses or dispense incorrect drug doses.
In practice, if a threat falls into the lower category as in the examples above, a medical device vendor would likely not have to issue software updates or have to inform affected stakeholders. Specific weaknesses or vulnerabilities might seem severe to a general security practitioner, but a monitoring station catching a virus is not treated as gravely as when the same thing happens to patients.
Medical cybersecurity standards
The medical regulation and standardization landscape is convoluted with different regulations applicable to each device based on the region where it is sold or operated, on the device type, and even on the type of marketing its vendor uses. Different medical associations can issue their own cybersecurity guidance and procedures so while we cannot provide a comprehensive analysis in this blog post, we will provide a sampling of the major medical cybersecurity standards.
Food and Drug Administration (FDA)
The US FDA has a mandate to regulate the safety and security of medical devices marketed and sold in the US, including software that is used as a standalone medical tool. The FDA publishes numerous guidance documents including two cybersecurity standards. It also recognizes many other cybersecurity standards as explained below.
The FDA understands that vendors may already have a cybersecurity compliance program of some sort, and lets vendors reuse these existing compliance statements for conformance to the FDA’s guidance. The FDA’s Guidance for Appropriate Use of Voluntary Consensus Standards (2018) defines this procedure, and the full list of recognized standards is available online. We will discuss two of the standards on that list in their own sections: the DTSec and UL 2900-1.
The FDA’s own guidance on medical device cybersecurity includes two major documents, which we’ll call “Premarket” and “Postmarket” guidance for brevity. The Premarket guidance establishes requirements for a secure design and development process and covers a comprehensive list of topics such as authentication and authorization, password protection, physical and cryptographic protections, communication and update security, and data and code integrity. It is high-level but can be translated into specific technical steps.
The Postmarket guidance, on the other hand, is more procedural. It addresses post-deployment maintenance requirements, procedures for incident response and handling and, most importantly, software updates. According to this guidance, vendors have to adopt a vulnerability disclosure policy, and notify downstream buyers or the FDA itself about security issues that have been discovered in their products. It mostly applies in cases where there is risk of patient harm. In other cases, the FDA allows applying software updates without the need to notify stakeholders or to re-certify the product.
National Institute of Standards and Technology (NIST)
The US NIST is recognized as a major cybersecurity authority in many areas, and medical standards are no exception. NIST has hundreds of security publications but we will mention only two here.
The NIST SP 1800-8 standard, “Securing Wireless Infusion Pumps in Healthcare Delivery Organizations”, was compiled in collaboration with some of the industry’s leading players. It’s based on the NIST Cybersecurity Framework and maps its requirements to the medical device cybersecurity field. It also refers to several non-governmental cybersecurity standards. The document addresses cybersecurity concerns across the device’s entire lifecycle, and describes the cybersecurity controls necessary to secure the network infrastructure, the infusion pump itself, the remote servers it connects to, and the enterprise network in which it can be installed. It also provides a functional test outline guidance which can be used to verify the implementation of its requirements.
Another valuable document from NIST is SP800-66 – “An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule” – which helps vendors by putting the HIPAA Security Rule into concrete terms by translating its requirements into a set of technical questions which can form the basis of an implementation plan.
Diabetes Technology Society (DTS)
The Diabetes Technology Society was one of the first to recognize the need for cybersecurity guidance that is specific to connected medical devices. It publishes the Standard for Wireless Diabetes Device Security (DTSec) which addresses the certification process for smart insulin pumps and related devices. For technical matters, the standard refers to the Common Criteria family of standards (ISO/IEC 15408) for which the DTSec developed its own protection profile. This standard is a high-level technical document, outlining the list of threats and the security requirements necessary to address them.
Underwriters Laboratories (UL)
UL, which is a major player in the global certification market, has published several cybersecurity standards for embedded devices under the UL 2900 family. UL operates a Cybersecurity Assurance Program (CAP) which certifies organizations and devices against this family of standards including medical devices.
Among these standards, UL 2900-1 is the central standard to which the other standards refer. This standard has been recognized by the FDA for certification of medical devices, as noted in the FDA section. Another standard in this family, the UL 2900-2-1 or “Software Cybersecurity for Network-Connectable Products, Part 2-1: Particular Requirements for Network Connectable Components of Healthcare and Wellness Systems” is dedicated to medical devices and systems. This standard maps most of its requirements into UL 2900-1, and adds a set of requirements specifically for medical device cybersecurity.
National Electrical Manufacturers Association (NEMA)
The US NEMA is a major association of manufacturers in various industrial verticals including medtech. It publishes a standard called the Manufacturer Disclosure Statement for Medical Device Security (MDS2) which is widely sued in the industry. This standard is a questionnaire which includes about 200 questions that cover a comprehensive range of subjects, from privacy to authorization to physical protection, as well as accompanying guidance which elaborates on the meaning and possible answers to these questions. Other versions and programs around the MDS2 abound, with many medical associations offering their own take; one such example is given below.
The Medical Device Innovation, Safety and Security Consortium (MDISS)
MDISS is a non-profit medical industry organization which provides a network of security testing labs for its members. It offers the MDRAP program for the certification of medical devices. The certification document is a questionnaire based on the MDS2 standard mentioned above, but with more questions and details on risk assessment and vulnerability management according to MDISS.
MDISS is also currently involved in an effort to create a derivative of the ISA/IEC 62443 standard for the medical industry. The ISA/IEC 62443 itself is a widely known and influential cybersecurity standard for IACS (Industrial Automation and Control Systems).
Open Web Application Security Project (OWASP)
OWASP is a non-profit, community-based organization that has been an influential cybersecurity player in general application and web security areas. It recently became involved with the security of embedded devices under the OWASP Internet of Things project. OWASP offers the OWASP Secure Medical Device Deployment Standard, which is a guide for medical device cybersecurity focusing on its deployment aspects. This is a useful source for cybersecurity practitioners interested in cybersecurity guidance for the organizational process, the network infrastructure and the device itself.
International Electrotechnical Commission (IEC)
The IEC is a global standardization body that deals with a very wide range of subjects, including cybersecurity in general and medical device cybersecurity specifically. The IEC 62304 standard, "Medical device software - Software life cycle processes" governs the software development and procurement processes for medical devices. It addresses several common practical concerns, such as the handling of legacy software and software obtained from sources that do not have an or orderly software management and development process. As is common in the medical industry, the standard's risk management is focused on patient risk. Conformance programs to this standard are available through several certifying organizations, including TUV SUD and UL.
Institute of Electrical and Electronics Engineers (IEEE)
The IEEE is a professional association with a wide range of publications and standardization activities. In the medical cybersecurity area, it has published the IEEE Building Code for Medical Device Software Security which includes best practices for embedded device development from several perspectives, including the organizational process, secure coding techniques, cryptography, code integrity, hardening and auditing. It serves as a useful overview but stops short of providing concrete requirements. As far as the authors of this blog post are aware of, it is not associated with any certification programs.
International Medical Device Regulators Forum (IMDRF)
The IMDRF publishes a document called Principles and Practices for Medical Device Cybersecurity which covers the procedural aspects of medical device security. It deals with subjects such as product life cycle from design to testing, the security process including risk assessment and general design principles, the procedures for vulnerability disclosure and incident response, the handling of legacy devices, and more. Like the FDA guidance, it is divided into premarket and postmarket considerations. The document cites a large number of associated standards and regulatory guidance documents for the medical industry.
Using automated tools for compliance
Compliance with medical cybersecurity standards can be challenging because of territorial fragmentation and differences between device classes. As with other verticals, using automated tools can help achieve compliance since they provide comprehensive analysis of the security posture for each device, enabling quick turnaround and covering many devices. We have examined how automated tools compare with or complement other available methods of compliance verification in a previous blog post.
Vendors are encouraged to use automated tools like VDOO Vision to scan their device’s firmware and track its security across different versions of the same product. Buyers, on the other hand, can submit the device firmware images for security scanning in order to discover their security postures rather than taking the vendor’s word for it.
Automated verification can find architectural and configuration issues and can be used to compare alternative products. It can even compare individual versions to test the effect of software updates before rollout. Medical device cybersecurity is often affected by vulnerabilities introduced by upstream suppliers, third-party software and open-source components, therefore every vendor or buyer would benefit from compiling a Software BOM (Bill of Materials), examining the medical device for known vulnerabilities and other possible weaknesses such as potential 0-days.
This blog post briefly reviewed the field of cybersecurity for embedded medical devices, or the Internet of Medical Devices (IoMT), the concerns that make it different from other connected device verticals, and the standards that govern it.
Ensure optimal security for your connected products across their entire lifecycle Contact us
Share this post