A Reference Architecture for Secure Medical Devices Steven Harp, Todd Carpenter, and John Hatcliff

FEATURE © Copyright AAMI 2018. Single user license only. Copying, networking, and distribution prohibited. A Reference Architecture for Secure Medical Devices Steven Harp, Todd Carpenter, and John Hatcliff Abstract and users cannot assume that medical Steven Harp, is a distinguished We propose a reference architecture aimed at devices will operate in a benign security engineer at Adventium Labs in supporting the safety and security of medical environment. Any device that is capable of Minneapolis, MN. Email: steven. devices. The ISOSCELES (Intrinsically connecting to a network or physically [email protected] Secure, Open, and Safe Cyber-Physically exposes any sort of data port is potentially at Enabled, Life-Critical Essential Services) risk. How should we think about and Todd Carpenter, is chief engineer architecture is justified by a collection of design manage risk in this context? at Adventium Labs in Minneapolis, principles that leverage recent advances in This question has been explored exten- MN. Email: todd.carpenter@ software component isolation based on sively.3,4 Special publications from the adventiumlabs.com hypervisor and other separation technologies. National Institute of Standards and Technol- The instantiation of the architecture for ogy (e.g., 800-39) provide a conceptual risk John Hatcliff, PhD, is a particular medical devices is supported by a management framework.5,6 AAMI TIR577 distinguished professor at Kansas development process based on Architecture describes how security risk management State University in Manhattan, KS. Analysis and Design Language. The architec- can be integrated with safety risk manage- Email: [email protected] ture models support safety and security ment (e.g., as addressed in ISO 14971 and analysis as part of a broader risk management specifically for medical devices in IEC framework. The models also can be used to 80001). The UL 2900 series of standards derive skeletons of the device software and to provides cybersecurity requirements for configure the platform’s separation policies and medical devices.8 an extensive set of services. We are developing In brief, a threat source initiates a threat prototypes of the architecture and example event, which may exploit a device vulnera- medical device instantiations on low-cost bility, causing an adverse impact. The boards that can be used in product solutions. impact might affect the mission of the The prototype and supporting development device, the end user, or the organization and assurance artifacts are being released that created or operated the device. In this under an open-source license. framework, risk is based on the likelihood of a threat event occurring and amplified by A reference architecture is a domain-spe- the potential loss (adverse impact) should cific design template for the structure of a the event occur. class of systems as a set of constituent parts Threat sources have capabilities, intents, with special roles and communications and often preferences for particular targets. patterns. The reference architecture Automated threats, such as malware, can be discussed in this article addresses the class indiscriminate in their target selection and of small bedside medical devices (e.g., do not care whether they are exploiting a infusion pumps, electrocardiographs, personal system or a hospital. Threats ventilators). The architecture also aims to targeting particular organizations also are support interoperability interfaces through well documented.9–11 The intent of the threat compatibility with the ASTM F2761 Inte- source is frequently financial, as exemplified grated Clinical Environment (ICE)1 or the by the recent spate of ransomware (e.g., IEEE 11073 service-oriented device connec- WannaCry).12 In addition to direct extortion, tivity standards.2 Any such architecture the medical information that is present in must address a wide range of requirements, some devices can have indirect value, such including safety, cost, maintainability, and as protected health information or personally performance. It also must address an identifiable information being leveraged to unpleasant modern reality: Manufacturers steal funds or illegally acquire drugs. www.aami.org/bit 357 FEATURE © Copyright AAMI 2018. Single user license only. Copying, networking, and distribution prohibited. A special type of impact needs to be instantiate it can reduce the attack surface. considered for medical devices: The lives Security controls in the device can further and health of patients may depend on them. reduce an attacker’s ability to exploit certain Security and safety are intertwined in such outstanding vulnerabilities and minimize systems, and failure to manage security the impact of successful exploitation of risks may pose safety risks.7 Beyond being others. an end target of an attack, a medical device The remainder of this article presents may represent a stepping stone for a larger principles driving the design and instantia- campaign. Exploitation of a vulnerable tion of Intrinsically Secure, Open, and Safe device may permit access to other clinical or Cyber-Physically Enabled, Life-Critical financial systems by allowing the attacker to Essential Services (ISOSCELES)—a safe and leverage trust information or to extract secure architecture for medical devices. credentials that allow the device to connect to these other systems. An example of a Architecture successful attack of this sort is documented The ISOSCELES reference architecture is in the MEDJACK report on blood-gas-ana- specified with tiered requirements: lyzers attacked in 2015–16.9 1. Platform core requirements for hard- A noteworthy long-term risk is when ware, system software, and services malware authors or researchers automate supporting the medical application. the attacks. This could result in multiple, 2. Platform design requirements derived nearly simultaneous malfunctions, similar from the platform core requirements Security controls in to what occurred with the WannaCry attack and refined to a specific design. the device can further in May 2017. With automation, botnet 3. Device design requirements specific to a reduce an attacker’s controllers could use the devices to attack particular medical device being devel- ability to exploit other devices on healthcare facility net- oped (e.g., an infusion pump). certain outstanding works. Decades ago, the attackers were The first two platform tiers drive the vulnerabilities and people who actively attacked your computer. reference architecture. These 134 require- minimize the impact of Unfortunately, automated botnets—mil- ments are intended to be suitable for a successful exploitation of lions of already-compromised machines broad family of potential medical devices. others. trying to grow their reach—are now the Figure 1 illustrates various components of prevalent attackers. a hypothetical medical device design based Recent Department of Homeland Security on this reference architecture. The exact advisories documented hard-coded pass- medical applications and services needed words and credentials in medical devices.13,14 may vary according to the device. A hard- Vulnerabilities such as these make it easier ware layer (bottom of figure) contains for malware (e.g., botnets, ransomware) to processors and peripheral devices that gain a foothold on the device. support security mechanisms. A low-level By itself, a medical device architecture separation layer of software uses these cannot address all aspects of risk. Security mechanisms to isolate all other software analyst Sergey Lozhkin noted that although components from each other, except for vulnerable devices were revealed in penetra- specifically allowed interactions. The tion testing, “the problem is not only one of ISOSCELES platform services satisfy typical weak protection of medical equipment, it needs of the top-layer medical applications has a much wider scope. The whole IT that provide medical diagnostics and infrastructure of modern hospitals is not therapies. The design of a specific device properly organized and protected, and the might incorporate only the required ele- problem persists worldwide."10 ments needed for that class of device. Until the day when software can be automatically and completely validated, we Architectural Principles must assume that some vulnerabilities The ISOSCELES reference architecture remain even after formal design and attempts to promote basic principles that extensive testing. However, a suitable provide security and safety. These principles reference architecture and tools to help and their motivations are described below. 358 Biomedical Instrumentation & Technology September/October 2018 FEATURE © Copyright AAMI 2018. Single user license only. Copying, networking, and distribution prohibited. Use Strong Time and Space Separation Many modern systems provide a basic security perimeter but lack internal security barriers, making it easy for attackers to access arbitrary information within the device, and even to control the device, after they have breached the perimeter. Strong barriers between software components help contain faults and attacks from propagating to safety-critical components. For example, if an infusion pump requires a network connection (e.g., to maintain current drug libraries), the network stack and code associated with retrieving the drug library should be wholly separate from the software that interprets the contents of the Figure 1. The layered ISOSCELES (Intrinsically Secure, Open, and Safe Cyber-Physically

Load more