Risk assessment of cyber-attacks on telemetry-enabled cardiac implantable electronic devices (CIED)

Cardiac implantable electronic devices (CIED) are vulnerable to radio frequency (RF) cyber-attacks. Besides, CIED communicate with medical equipment whose telemetry capabilities and IP connectivity are creating new entry points that may be used by attackers. Therefore, it remains crucial to perform a cybersecurity risk assessment of CIED and the systems they rely on to determine the gravity of threats, address the riskiest ones on a priority basis, and develop effective risk management plans. In this study, we carry out such risk assessment according to the ISO/IEC 27005 standard and the NIST SP 800-30 guide. We employed a threat-oriented analytical approach and divided the analysis into three parts, an actor-based analysis to determine the impact of the attacks, a scenario-based analysis to measure the probability of occurrence of threats, and a combined analysis to identify the riskiest attack outcomes. The results show that vulnerabilities on the RF interface of CIED represent an acceptable risk, whereas the network and Internet connectivity of the systems they rely on represent an important potential risk. Further analysis reveals that the damages of these cyber-attacks could spread further to affect manufacturers through intellectual property theft or physicians by affecting their reputation.

External programmers are used by the physicians ab initio when configuring the devices prior to implantation and during patient follow-up sessions to retrieve data and for reconfiguration. They have three modes of operation: 1) the interrogation mode to check a patient's cardiac programmed parameters and stored data, 2) the test mode to test that the implant is operating properly, and 3) the programming mode which allows the physician to adjust the patient's therapy by reconfiguring the functionality of the CIED [4,5]. Reconfiguration after manufacturing is feasible since current CIED circuitry is microprocessor-controlled and its software can be updated [3,14,15,16,17,18,19,20].
Home monitoring devices are intended to supervise the patient's cardiac status. They periodically collect activity data from the CIED and send it to a cloud-based database. The latter may be operated by either the CIED manufacturing company or a web services provider used by the physician to access the patient's data [6,7,9].
As evidenced by previous work, CIED are vulnerable to cyber attacks that use their RF interfaces to communicate with the devices [21,22]. This is also true for non-telemetry enabled CIED, but telemetry introduces additional vectors of cyber attacks that can include manipulation of the home monitor, interception of transmissions from the home monitor to the cloud and the physician's station, and manipulation of the cloud-based database itself [8,23]. Proof of the increased concern of cyber attacks on CIED was given by the recall of almost half a million CIED by the Food and Drug Administration (FDA) in August 2017. According to the FDA, the aforementioned devices were vulnerable to unauthorized access, allowing a malicious person to reprogram them using commercially available equipment [24]. However, no such attacks have been reported. While we know it would be technically possible to conduct such an attack in the controlled environment of a research laboratory [21,22,8], it remains to be determined how viable such an attack would be on an actual target in the real world. This is precisely our research question: What are the real-life risks of cyber attack onto telemetry-enabled CIED and the systems they depend on?
In this work, we carry out a realistic risk analysis of such attacks, with regards to actual impact these problems pose in terms of: health, economy, quality of life and privacy of the affected parties. In order to carry this risk analysis, we inventory the vulnerabilities that have been made public up to now, we define attack scenarios based on them, describe and evaluate the impact of the various attack goals that various actors would want to achieve through such attack scenarios, and finally estimate the likelihood of occurrence of each of these attacks to determine overall risk.
Our motivation to conduct this research is based on the need to understand the real scope of the problem. After the FDA statement was released, patients began to massively call their cardiologists to get an explanation about these potential failures and to what extent they were in danger. It is at times difficult for physicians to answer them, since cybersecurity is not their field of expertise and because there is little information about the clinical impact of exploitation of the vulnerabilities found. This is why we believe that such a "reality check" is necessary, as the real scope of the problem it is not clear at all. By determining the scope of the problem we contribute to 1) extend the knowledge of the threats affecting CIED, 2) provide guidance on which threats should be addressed in priority and consequently 3) provide to the organizations potentially interested in this kind of risk assessment a basis from where to start, e.g. health regulation agencies, device manufacturer, health practitioners, etc.

CIED computer-based architecture
Few documentary sources on CIED architecture and design are available, due to the proprietary nature of that information. Nonetheless, common principles and some technical details are generally documented in some of the corresponding patents [3,16,17,18,19,20]. As depicted in Figure 1, today's software-based CIED circuitry is mainly composed of four electronic components with the first one being the microprocessor which is the "brain" of the CIED. It coordinates, controls and directs the interactions between the elements of the circuit. It also interprets and executes the algorithms programmed in memory. The second component is the memory, CIED holds two kinds of memories: Read-Only Memory (ROM) and Random-Access Memory (RAM). The ROM contains the embedded software (also known as firmware) providing low-level control of the device's hardware, as well as the code implementing the various functionalities of the device. While the RAM is taking care of storing a variety of parameters, such as device serial number, patient ID, clinical information, patient's cardiac activity (arrhythmia logs, frequency histograms) and certain programs implementing particular therapies. The third component dubbed the telemetry circuitry is used to establish a communication link between the CIEDand external devices, such as the external programmer or a home monitor. More specifically, the telemetry circuitry allows performing remote monitoring, therapy adjustment and reprogramming the CIED prior to implantation or during patient follow-up sessions. The fourth electrical component is the timing circuit which is a key element on the CIED circuitry as it takes care of synchronizing the stimulation pulses to the cardiac chambers as well as the memory access.
The previously described components are interacting together to maintain the CIED functionalities, each one of them has a specific task that has to be executed in a coordinated way. A good example of these multi-component interactions would be the automatic therapy selection loop ( Figure 2). This process is performed at the microprocessor level using signals coming from the detection probes that are continuously monitoring and re-transmitting the cardiac activity to the microprocessor. The re-transmitted signals are then interpreted in order to select the adequate therapy code from the RAM. Finally, the selected code is translated to a low-level instruction set (located in the ROM) before being executed by the microprocessor. It is also important to mention that the treating physician is responsible of determining which therapies can be applied under what conditions. The clinician uses the programmer's user interface to program or adjust the parameters of the patient therapy (i.e., number of beats per second). When fixing a therapy parameter on the programmer user interface, the external device subsequently sends to the CIED an instruction containing the change to perform on the therapy. The telemetry circuitry receives this instruction and then sent it to the microprocessor. Following the interpretation of the instruction, the microprocessor will access the RAM to perform the required change. (Figure 3).

CIED ecosystem
The CIED ecosystem (Figure 4) encompasses the set of devices, cloud-based systems and cloud-based services employed for the diagnosis, the therapy's adjustment and the monitoring of patients with an implanted CIED. Apart from the CIED itself, there are two other medical devices forming part of this ecosystem. These are, the external programmer usually located at the hospital and the monitor located at the patient's home. Health professionals rely on the external programmer to obtain the programmed parameters of the patient, to adjust the desired therapies or to check the correct operation of the CIED [4,5]. The home monitor is used to periodically collect the data stored in the CIED and send them to a cloud-based database (DB). Thus, medical staff can access a patient's health information through a web-based application, operated either by the CIED manufacturer or a separate cloud service provider [6,7,9]. It is fair to say that the monitor is a key element of this system of systems as it is through him that some CIED data are available on the cloud-based elements of the ecosystem in study. By cloud-based elements, we refer to the cloud-based database containing the information coming from the monitor, the cloud-based application displaying this information and, the cloud-based server containing the application. Moreover, the set of devices employed to use the application mentioned above (e.g. smartphones, tablets, and laptops) form also part of the ecosystem of CIED.
The CIED interact with all the elements of their ecosystem. Depending on the element, the interaction could be either direct or indirect. Direct interaction takes place with both the external programmer at the hospital and the home monitor device, while indirect interaction occurs with the cloud-based systems and services. We distinguish the type of interaction since as we will see later (Section 6.2), it determines the kind of attacks that can be carried out.
Direct interaction consists of wireless communication between the CIED and a programmer or a home monitor device. Indeed, current pacing devices include two types of wireless technology. The first, referred to as Inductivecoil telemetry, uses an inductive RF field (0-300 kHz) to communicate over short ranges (0-10 cm), requiring proximity between the CIED and the antenna coil of the external programs. The second mode referred to as RF-link telemetry, uses a radiating RF field (i.e. traditional RF waves) at a higher frequency (402-405 MHz) to communicate over longer ranges (0-200 m) [25]. Both technologies can be used for interrogation and programming operations during follow-up visits at the hospital. The main difference between them is that with inductive coil telemetry it is necessary to apply a programming head 1 right above the CIED to establish communications, while with RF link this can be achieved without such proximity; it is therefore referred to as "wand-less" [4,5]. Nowadays, the trend is to use RF-link telemetry to the detriment of the inductive-coil telemetry, since it has a better conductivity in the human body, a higher data rate, a greater communication range, and thus constitutes a more adequate option for home monitoring [4,5]. This technology operates on the Medical Implant Communications Service (MICS) core band (402-405 MHz) initially allocated by the Federal Communication Commission (FCC) in 1999 [12], and that has subsequently been adopted in different regions of the world [10,2].
The MICS spectrum was established in order to support data transmission between any implanted and external device for diagnostic and therapeutic purposes, not only for CIED [10,13]. However, since this band is shared with communication devices used by meteorological services, its use has been normalized to avoid any interference [2,11,12]. These rules of use are based on ITU-R Recommendation 2 SA.1346 [26], whose broad outline is the following: • The MICS spectrum is divided into 10 transmission channels with a bandwidth of 300 kHz each.
• The implanted devices can only transmit after receiving a command from an external device authorizing them to do so (there are exceptions such as emergencies).
• External devices must integrate interference mitigation techniques, such as Listen Before Talk (LBT) and Adaptive Frequency Agility (AFA) to minimize the effect of ambient noise. External device radio transmitters use LBT to sense their radio environment before starting a transmission, in order to identify a free channel with least interference, i.e. the Least Interference Channel (LIC). Channel verification is done five seconds before initiating a transmission, with each channel being monitored for 10 ms to determine if it is occupied. Then, based on the sensed information the transmitters use the AFA technique to select an operating frequency that is not in use yet [27,28].
Although the use of the transmission means adheres to an internationallyadopted standard and is carefully regulated, the same cannot be said for signal-conditioning techniques or CIED access control mechanisms. While the Health Insurance Portability and Accountability Act (HIPAA) 3 determines privacy and security rules for the protection of medical data transmitted between systems, these remain very general and are more oriented towards traditional Information Technology (IT) systems such as computers and servers. While the FDA has defined good practice guidelines in this area, they do not establish legally enforceable responsibilities [29,30] so their application remains optional. This legislative vacuum results in an overabundance of proprietary communication and authentication protocols, where it is up to each manufacturer to set their own criteria and choose the security methods to apply to their devices.
Indirect interaction occurs between the CIED and the cloud-based systems or services when those are employed to display the information contained in the CIED. Health practitioners have the ability to access the collected data using their own portable devices via connection to the cloud-based web application through a regular Internet connection. This approach aims to improve the quality of patient care and the working conditions of medical staff while reducing health costs. Thus, even if strictly speaking there is no direct communication between the CIED and these systems, there is still a data link between them. Nonetheless, current CIED features do not include the capability to download information from the DB server, and in principle cannot be remotely reconfigured by the health practitioners from the monitors.
In summary, CIED operate in a complex and heterogeneous ecosystem composed of various devices connected to different networks and using multiple communication protocols to interact with each other. The necessity to reduce health costs is propelling a worldwide transformation of health service management that relies precisely on the interaction between medical devices and health practitioners. Nevertheless, this interaction, which is undoubtedly beneficial for all stakeholders, may have turned into a significant attack surface for cyber attacks against the CIED ecosystem [31].

Background on Implantable Medical Devices (IMD)cybersecurity
The security threats that affect CIED apply to all IMD. The latter are vulnerable to malicious exploitation of (i) their RF communication interfaces, and (ii) the telemetry functionalities and IP connectivity of the extracorporeal equipment on which they depend. In this section, we develop a critical review of the literature on cyber threats affecting IMD and risk assessments regarding IMD risk exposure to cyber attacks. We proceed in this way for two reasons. First, there is no abundant and exclusive literature on the cybersecurity threats of CIED. Second, we claim that the risk assessment methodology proposed here applies to all IMD.

IMD Cyber Threats
In the last decade, several research groups have exposed vulnerabilities in implantable medical devices (IMD), such as insulin pumps and, of course, CIED. Below, we chronologically describe these findings.
In 2008, Halperin et al. [21] unveiled CIED vulnerabilities to radio frequencybased attacks. By making use of a software-defined radio (SDR), the researchers succeeded in reverse engineering the device's communication protocol and conducting attacks such as sensitive data interception and dangerous command emission (electric shock dispensation).
In 2011, Hei et al. [32] found vulnerabilities that allow resource depletion attacks on insulin pumps. They demonstrated that by sending periodic wireless commands to the IMD, it was possible to keep an active communication session permanently opened, thus significantly reducing the device's service lifetime. During the same year, Li et al. [33] disclosed insulin pump vulnerabilities that allow unauthorized parties to communicate with the device. In fact, their work revealed that some insulin pump models possess a class of vulnerability that can allow an unauthorized party to "emulate the full functions of a remote control: wake up the insulin pump, stop/resume the insulin injection, or immediately inject a bolus dose of insulin into the human body" [23]. That same year, Jerome Radcliffe, a patient with diabetes, partially reverse-engineered the communication protocols of his insulin pump. He announced his findings at the Black Hat cybersecurity conference.
In 2012, the hacker Barnaby Jack demonstrated that certain CIED models can disclose their authentication credentials following the reception of a specific command [34]. He was also able to verify that the access codes of some devices are simply their serial and model number. Paradoxically, this information is disclosed by some CIED models when they receive a specific command from an external programmer or a home-monitoring device. This discovery highlighted that an unauthorized party could gain control of certain CIEDs by simply sending a command [23,35].
In 2016, Marin et al. [22] used a black-box reverse-engineering 4 approach to analyze the proprietary communication protocols employed by CIED to communicate with external programmers over a long-range RF channel. Their work evidenced that reverse-engineering CIED proprietary communication protocols is feasible and that they present several implementation weaknesses. As proof of that, they were able to implement a set of exploits like the interception of sensitive information, Denial-of-Service (DoS), spoofing and replay attacks. The findings of this research were reproduced for at least 10 different models of CIED.

IMD cybersecurity risk analysis
Even though the first study evidencing vulnerabilities in CIED was published in 2008 [21], it is only in 2015 i.e seven years later that the first IMD risk assessment study appears in the literature.
In 2015 Jagannathan and Sorini conducted a full IMD-specific cybersecurity risk analysis [36]. This study presents a methodology to evaluate medical devices exposure to cybersecurity risks. The method presented is a traditional Preliminary Hazards Analysis (PHA) study which was tailored to assess the cybersecurity properties of medical equipment. As any PHA study, their methodology consists of three main steps namely: 1) hazard identification, 2) risk determination, and 3) risk ranking and follow-up actions. This work analyses the cybersecurity risk of fictitious medical devices. Thus, its findings do not reflect the actual state of the problem. In our work, we analyze real medical devices that are currently in the market. Therefore, the results herein find not only illustrate the actual scope of the problem but can serve as a basis for the risk management procedures related to the CIED ecosystem.
In April 2017, a study by Stine et al. [37] presented a cybersecurity risk assessment method for network-connected medical devices. This study introduced a scoring system relying on a cybersecurity questionnaire based on the STRIDE 5 model developed by Microsoft for classifying threats [38]. The scoring system is intended to help healthcare organizations in identifying those medical devices that have the potential to endanger patient health or disrupt the quality of medical follow-up. This study estimates the probability of occurrence of an attack according to the security features implemented in the target system. Since the estimate of P is only based on the technical difficulty of the attacks, it does not adequately reflect reality. Just because an attack is technically simple to carry out does not mean that an attacker will be interested in achieving it. The chance and willingness to attack are essential factors when it comes to estimating P. Accordingly, in our study, we estimated P in function not only of the characteristics of the target system but also, in function of specific characteristics of the attacker.
In May 2017, Rios and Butts [8] conducted an exhaustive analysis of the CIED ecosystem and the interdependence between its elements. The hardware and software components of different models of CIED, external programmers and home-monitoring devices from different manufacturers were examined. As a result, over 8,000 known vulnerabilities were discovered in third-party libraries of four external programmer models belonging to four different manufacturers. Besides, vulnerabilities were found in all CIED evaluated. The publication of this work preceded the massive recall of CIED ordered by the FDA in August 2017, based on the vulnerabilities reported by the Industrial Control Systems Computer Emergency Response Team (ICS-CERT) of the US Department of Homeland Security (DHS). This work identifies the threats and their nature however, the real scope of the risk that those threats entail is not described. We consider that although there are vulnerabilities in a system, it is their probability of exploitation and the impact that this exploitation has on individuals that determines whether the vulnerability represents a significant risk or not. In our study, we estimate the risk of a vulnerability based on the probability that it will be exploited and, the impact that the exploitation will have on victims.
In 2018, Abrar et al. [39] conducted a risk analysis on cloud computing within the context of health applications, in order to evaluate their suitability for the Health Infrastructure System (HIS). The research team identified HIS vulnerabilities and then analyzed the impact that a security breach would have on its integrity if the vulnerable elements were deployed in a cloud computing environment. This paper analyzes a mortgage situation, while we analyze a real situation, i.e. the risk that current CIED cloud-based services represent for patient safety.
Our cybersecurity risk assessment is divided into three analysis: 1) actorbased analysis, 2) scenario-based analysis and 3) combined analysis. On the first one, we identify the potential actors and determine the impact of the attacks according to four separate aspects: health (H), monetary (M), privacy (P) and quality of life (QL). Thus, the outcomes of this work may support the objectives of different kind of organizations potentially interested in CIED risk assessment, e.g. health regulation agencies, device manufacturer, health practitioners, etc. On the second analysis, We determine the attack scenarios and then estimate their probability of occurrence according to the actors capacity, opportunity and motivation to achieve the attacks. Finally, in the last analysis, we calculate and characterize the risk associated with each threat (actor, scenario).

Aim of the risk assessment methodology
The number of IMD that rely on ICT to ensure patients therapy, diagnosis or follow-up is increasing. However, unlike traditional ICT systems (computers, servers, networks...), there is not yet a formal and effective method to assess the cybersecurity risk incurred by IMD. As mentioned in section 3, even if the first vulnerabilities were found in 2008, it is only recently in 2015 that the first IMD risk assessment appears in the literature. Therefore, this area of study is just starting to develop, hence the need for a methodology.
In this work, we propose a method for asses the cybersecurity risk incurred by CIED, a subcategory of IMD. Our method can be used to guide organizations interested in conducting risk assessments of CIEDs and can be extended to other IMD.

Definitions
We define here the cybersecurity and risk assessment terms used in this article. Actor: A person or organization that violates the integrity, privacy or confidentiality of a computer system's data to obtain a benefit. Impact: Quantification of an attack's effect or consequence on the target or victim. Victim: A person or organization that is the subject of a computer attack. Attack goal: Final effect desired by the actor, resulting in a negative impact on the target system or victim. Scenario: Set of actions carried out by the actor to achieve his attack goal.
Threat: A combination of a person with deliberate intent (actor) comitting acts in particular fashion (scenario), resulting in a negative consequence (impact). Vulnerability: A design, manufacturing or programming flaw in a system that may offer the opportunity to conduct an attack on it.
Attack vector: Subset of vulnerabilities for which there is a demonstrated attack method by which the vulnerability is employed (exploited) by the actor to reach its final goal or an intermediate goal towards it (e.g. gaining access). Exploit: Subset of attack vectors related to software vulnerabilities. Probability: Likelihood that a particular threat (a given actor successfully reaching an attack goal through a given scenario) be materialized during a given period of time.
Risk: Quantification of a threat (Risk = Impact * Probability).

Risk assessment methodology
Our risk assessment methodology is divided into three steps: Significant privacy impact if information is disclosed 3 Severe impact on the patient privacy if the information is disclosed 4 Catastrophic impact on the patient privacy if the information is disclosed Step 1. Actor-based risk analysis In this phase, we aim to determine and quantify the impact of attacks on the CIED ecosystem. To do this, we first identify potential actors that would be interested in attacking the CIED ecosystem. Then, we determine their likely attack goals and from there we quantify the impact on the victim of the successful accomplishment of such attack goals. We do this separately according to four different categories of impact: Health, Monetary, Quality of Life and Privacy. We measure the impact on health by applying the Hayes classification approach [40] that was introduced to classify the impact of different levels of clinically significant electromagnetic interference with pacemakers. The monetary, quality of life and privacy impacts are measured using the Fair Information Practice Principles 199 (FIPPS 199) from the National Institute of Standards and Technology (NIST). The FIPPS 199 is a standard for assessing the security of information systems. The impact is quantified according to a four-level scale described in Table 1 and discussed in more detail in Section 5.3.
Step 2. Scenario-based risk analysis Here, we estimate the probability of occurrence of various threats. We start by identifying attack vectors, i.e. exploitable vulnerabilities, associated with CIED. We found those attacks vectors on the literature [8,21,22,32], the ICS-CERT advisories [41,42,43], the National Vulnerability Database (NVD) main-tained by the NIST, and the Common Vulnerabilities and Exposure (CVE) database maintained by the Mitre Corporation [44,45,46,47,48,49,50,51] . Next, we describe how these attack vectors can be strung together into a series of actions, i.e. attack scenarios, that lead to the achievement of the attack goals (determined in Step 1). Once this is done, we calculate for each threat, i.e. each (actor, scenario) pair, its probability of occurrence according to the formula where c, o, and m represent, respectively, an assessment of the actor's capacity, opportunity and motivation to conduct the attack scenario described. More precisely, capacity takes into consideration the technical complexity of the attack scenario and the technical and material resources available to the actors to carry it out. The opportunity represents the actor's chances of having physical or network access to the target and being there at the right time to exploit an attack vector and conduct subsequent scenario actions. Finally, motivation captures the inherent likelihood that the actor will put the resources in place and attempt to conduct the attack scenario given what he stands to gain from successful accomplishment of the attack goal.
Step 3. Combined risk assessment In this last step, we calculate the overall risk associated with each attack scenario based on the most likely actor.
Where I is the impact calculated from Step 1, and P MAX is the maximum actor probability for each attack scenario, as determined in Step 2.

Potential actors
The ICS-CERT has characterized a cyber threat source as "persons who attempt unauthorized access to a control system device and/or network using a data communications pathway" [52]. It further classifies these threat source into four groups (A1 through A4): A1. Cybercriminals groups This includes traditional cybercriminals groups that use compromised computer systems to commit identity theft and online fraud of various kinds, mostly for monetary gain.
A2. Industrial spies Organizations that use computer tools to illegally acquire intellectual property, know-how, trade, and commercial secrets, or other kinds of corporate confidential information. This kind of espionage occurs between competing corporations, for economic reasons.
A3. Foreign Intelligence Agencies Foreign state-based organizations that use computer tools to acquire sensitive information on opposing states, corporations or individuals, or otherwise influence their actions.
A4. Terrorist groups Organizations seeking to create public disorder or sow national terror, by committing destructive violent acts.
While this taxonomy of cyber threat sources was introduced for traditional threats to IT infrastructure, we nonetheless proposed to use them in the context of cyber threats against the CIED ecosystem. To that effect, and considering the likely objectives [31] and motivations [52] of these actors, we maintained the six kinds of attack goals (G1 through G6) described herein.

5.2.
Attack goals G1. Access patient sensitive data CIED ecosystem devices are an attractive target because they constitute a rich source of information. Beyond medical data, they store other types of information such as email addresses, residence addresses, telephone numbers, social security numbers, etc., attractive to many actors. On the one hand, intelligence services (A3) and terrorist groups (A4) would be interested in having this information because it would allow them to attain their ultimate goal (surveillance, assassination, etc.). On the other hand, cybercriminal groups (A1) would be interested to leverage this information to obtain monetary gain since the medical data of individuals is highly valued in the black market [53,54,55,56]. Their clients could be for example insurance companies (medical or automotive) that may use this information to assess the cost of insurance premiums or simply refuse coverage.

G2. Gain knowledge of device operation and software
There is significant competition between medical-device manufacturers because of its high-profit margins and high barriers to entry in the market [57,58]. Accordingly, CIED ecosystem devices could be a target for industrial spies (A2) aiming to obtain intellectual property on device design, software and other kinds of engineering details. Subsequently, such information could be sold to competing medical-device manufacturers or possibly to counterfeit medical devices manufacturers in less regulated countries (similarly to the production of counterfeit or generic pharmaceutical products). Furthermore, this information is also valuable for criminal groups (A1), intelligence services (A3) and terrorist groups (A4) because it allows them to undertake attacks by maliciously exploiting the device characteristics or operating mode.

G3. Induce medical staff to make errors
Health is one of the main factors of concern for individuals. Hospitals and their personnel are highly valued in society because individuals trust them [59,60,61,62]. Some attackers may be interested in damaging the reputation of health centers or professionals to sow distrust and fear in the society. These could include foreign intelligence services (A3), terrorist groups (A4), or even cybercriminal groups (A1). Apart from sowing fear, said actors could be interested in harming a particular, targeted person. Thus, inducing medical staff to make errors not only would they be achieving their goal, but they would also be evading the responsibilities of their actions by making their interference less detectable.

G4. Disrupt or lower quality of patient follow-up
Cybercriminal groups (A1) could be attracted by those kinds of attacks to realize extortion, industrial or corporate sabotage. The first objective would be to disrupt or even interrupt a healthcare provider's service to demand money to restore it. The second would be to interfere with a targeted CIED manufacturer in order to make believe that their CIED equipment is defective, thus damaging the company's sales revenue and reputation. The third would be to damage the reputation of a targeted health center or professional. For example, disrupting the quality of a target center's patient follow-up could decrease public and government trust in the institution, and lowering its chances of getting adequate revenue and allocation of public resources. Intelligence services (A3) or terrorists (A4) could be motivated to conduct such attacks to harm the population of an opposing country.

G5. Alter device behaviour to endanger patient
This constitutes the most potentially worrisome outcome of the cyber attack against the CIED ecosystem. Indeed, by changing the device settings so that it has an unexpected or dangerous behavior, actors could seriously endanger a patient's life. It is conceivable that foreign intelligence services (A3) and terrorist groups (A4) targeting particular high-value or highly-visible individuals might be motivated to use this kind of attack for assassinations or as a form or extortion or ransom.
G6. Alter device behaviour to decrease quality of life For the same reasons described above, intelligence services (A3) and terrorist groups (A4) could be motivated to use similar methods to accomplish nonlethal disruptive effects on patients by forcing them to repeatedly visit the clinic due to device malfunction, generate false alarms, or otherwise tampering with device configuration. Beyond serious harm, such disruptions could be used to mine the confidence of the population on health providers, device manufacturers, or create panic and terror (A3 and A4). The possibility should also be considered that cybercriminals (A1) migrate from traditional forms of IT-based extortion, such as file-encrypting ransomware, to medical device-based extortion, e.g. by locking out access by health practitioners to a patient's CIED and demanding a ransom to restore it. In summary, the vulnerability of the CIED ecosystem to cyber attacks is a matter of concern not only for patients but also for other groups such as health practitioners, medical device manufacturers and government in general.

Impact of attack goals
Independently of the various actors goals and motivations, these attacks will have an impact on the victim, whether the patients themselves or those other groups affected. In order to account for the various types of consequences that these attacks could have on them, we measure impact according to four separate aspects: health (H), monetary (M), privacy (P) and quality of life  (QL). We chose these four factors because affecting them negatively align precisely with the attack goals we have previously discussed in Section 5.2. Furthermore, by separating our analysis for these factors, we aim to support different agendas and objectives of those organizations potentially interested in this kind of risk assessment, e.g. health regulation agencies, device manufacturers, health practitioners, etc. The impact scale ranges from 1 to 4, with 4 being the highest impact level (most severe). The description of the impact levels can be found in Table 1 and the summary of the analysis is presented in the Table 2. The explanation of the impact analysis by attack goal follows.
G1 (P) While confidential, the information disclosed would not have a severe consequences (except maybe in terms of insurability) and is likely to exist in other or be otherwise available to actors through other sources or other more traditional forms of cyber attacks no related to CIED. (M) The disclosure of this information may be grounds for legal action against the hospital and the manufacturer.
G2 (M) The medical device industry is very profitable, and competition between manufacturers is fierce. Losses due to intellectual property theft could reach tens of millions of dollars. 6. Scenario-based risk analysis

Vulnerabilities
We now inventory the vulnerabilities (V i ) affecting the CIED ecosystem. We have harvested this information from several sources, including ICS-CERT advisories, the NVD maintained by the NIST, the CVE database maintained by the Mitre Corporation and previous research in this area [8,21,22,32]. We separated the vulnerabilities in three groups, depending on what devices they affect, with some of them applicable to more than one type of device (i.e. V 9 , V 10 ). We have inventoried 15 vulnerabilities, enumerated in Table 3 6 , and explained in detail in the following paragraphs. Monitor V 9 Unprotected USB serial port connections V 10 Exploiting embedded debugging interfaces (JTAG and UART) V 11 OS hardcoded authentication credentials V 12 Exposed dangerous methods or functions V 13 Server hardcoded authentication credentials V 14 Hardcoded server parameters V 15 Exploiting remote firmware update secret key is their serial or model number. TOP authentication algorithms are vulnerable to identity theft attacks since an adversary who steals the secret key can generate valid passwords every time he wants to establish a telemetry session with the device [34,35,42,44,21].
The number of RF wake-up commands that a CIED can receive per session is not limited, i.e. an attacker can maintain a telemetry session indefinitely active by regularly sending the aforementioned commands to prematurely reduce the CIED's lifetime [22,32,42,45].
Unencrypted data storage and transmission Certain CIED models store and transmit patient information without encrypting it. Thus, a nearby attacker may intercept the data exchanged between the CIED and the programmer or even gain access to the sensitive data stored on the device by sending an unauthorized RF command [21,34,42,46].
V 4 : Lack of command whitelisting techniques Command whitelisting is a computer protection method based on software restriction policy rules. This technique blocks by default the execution of all the programs contained in the device so that only programs that are the subject of a policy rule can be executed. In the case of CIED there are no policy rules prohibiting the execution of programming commands from devices other than external programmers. Consequently, an adversary could send a programming command to the CIED by means of commercial available equipment such as a commerciallyavailable SDR [21,22,34].
V 5 : Unencrypted hardcoded authentication credentials The product username and password are stored in a recoverable format, i.e. without being previously encrypted [41,47].
V 6 : Software directory path traversal It has been shown that the software of certain devices contain directory path traversal vulnerabilities, i.e. a kind of software implementation vulnerability that permits the access to directories other than those permitted by design. Thus, an adversary will be able to exploit these weaknesses in order to read the external programmer's file system [41,48].

V 7 : Improper Restriction of Communication Channel
Downloading software updates is done by means of a Virtual Private Network (VPN) established between the programmer and its software update provider. While the use of VPN is a recognized good practice to secure communications between two parties, it has been unveiled that certain external programmers models do not verify that they are still connected to the VPN before the update operation is accomplished. Thus, an adversary could leverage the device's local network access features to interfere with the communication between the programmer and its software update provider [8,41,49].
Exploiting embedded debugging interfaces (JTAG and UART) Embedded debugging interfaces are connection ports present in a device's printed circuits. Manufacturers use them to perform functional testing and redesign of devices after manufacturing. For example, JTAG is a master/server interface used to verify a circuit, test device logic and perform functional redesign when needed. It can be used to read and modify the memory and the registers as well as to read the device's firmware. The UART interface provides a serial communication between the device's embedded systems and an external PC, i.e. a bidirectional interface used to send and receive data asynchronously. Since these interfaces allow direct access to the device memory and firmware, unprotected access to those interfaces constitutes an entry point for attacks against the CIED [8]. Home monitoring devices also have this vulnerability.
V 9 : Unprotected USB serial port connections Certain devices have USB port connections. They are frequently used by medical staff to store the information on a USB stick in order to transfer it to other systems, e.g. reporting software. If the USB port connection is not blocked with a password or another authentication mechanism, an attacker could connect to it and access data on the device and potentially take control of it [8].
V 10 : Unprotected removable media/hard-drives When they are in the attacker's hands, the media/hard drives become an entry point of attacks since they can be used to extract information from a device's file system [8].
V 11 : OS Hard coded authentication credentials In certain products, authentication credentials to the operating system (OS) are hard-coded on the device. That means that an adversary with physical access to the device's integrated circuit can access the OS by connecting to the debug port and authenticate with the hard-coded password [8,43,50].
V 12 : Exposed dangerous methods or functions Home monitors contain debug code to test their communication interfaces with both the CIED or the external system (databases, servers) of the cloud-based application used by the physicians. Thus, by leveraging this vulnerability an adversary with physical access to the monitor can maliciously exploit the debug code to accomplish a set of attacks, for example, read or write the device's memory content, interrupt the data sending to the cloud-based systems, enable bidirectional communication with CIED [43,51].
V 13 : Server hardcoded authentication credentials The credentials that home monitors use to authenticate to the cloudbased systems supporting the patient's remote follow-up service are hard-coded on certain devices. Thus, an attacker with physical access to the monitor can leverage these vulnerabilities to access the database in order to read or tamper with the patient's medical data [8].
V 14 : Server hardcoded parameters In certain home monitors the IP address of the authentication servers are hard-coded. An adversary could use this information to conduct a DoS attack to make the server temporarily unavailable by sending several web requests to this IP address [8].

Attack scenarios
Once we have identified who the actors are and what they are trying to achieve (attack goals), we are now interested in the strategy that it is going to be used by them, i.e. how will they exploit the vulnerabilities of the CIED ecosystem to achieve their goals? Thus, as illustrated in Table 4, an attack goal can be achieved through different scenarios. As defined in Section 4.2 an attack scenario is the sequence of events that must occur for the attack to take place.
It can be noticed that the same scenario can serve to achieve different attack goals. Since a threat is a pair (actor, scenario) and the actors can vary from one attack goal to the next, we carried out the scenario-based risk analysis by attack goals. The explanation of the scenarios of each attack goal follows. For a more extensive description of the sequence of events leading to the achievement of the attack scenarios refer to Appendix B.

G1 Access patient sensitive data
There are three ways to acquire patients medical data: performing a radio attack (S 1 , S 2 ) on the incoming RF communication between the CIED and the external devices (monitor, programmer), getting unauthorized physical access to the monitor contents (S 3 ) or performing a network attack on the monitor (S 4 ).
Executing the radio attacks described in Scenarios S 1 and S 2 requires the actor to have specialized materials and software, namely an SDR, an antenna and a radio signal processing software (e.g. GNURadio, HackRF, etc.). Once this requirement has been met, the actor must go either to the patient's home (S 1 ) or to the hospital(S 2 ), place himself at a distance relatively close to the CIED, configure its antenna in reception mode, tune it to the transmission frequency of the CIED then, record the signals emitted by the latter and read the patient's medical data by exploiting the CIED unencrypted data storage and transmission vulnerability (V 3 ). Extraction of the programmer's system data Sending a malicious http request from the device's SW deployment network server to the server S 6 Extraction of the programmer's system data Accessing the device through an update session communication channel S 7 Reading/extraction of the monitor file system Accessing the device USB port S 8 Reading/extraction of the programmer file system Accessing he device USB port S 9 Reading/extraction of the programmer system data Removing the media device hard drive S 10 Reading/extraction of the monitor OS information Connecting to the debugging ports

G3 S 11
Insertion of a malware that produce programmer Performing a MITM attack during an reading errors update session S 12 Introduction of calibration errors into the CIED Sending RF commands microprocessor (through malware insertion or sending with an SDR inappropriate commands) S 13 Insertion of a malware that produce programmer Using the device USB port reading errors  The physical attack of Scenario S 3 also requires the actor to have specialized equipment. An in-debugger-circuit, a debugger IDLE and a pirate bus (or an F to F jumper wire) are needed. Since the monitor is the targeted device, the actor must go to the patient home, then connect to the device's debugging interfaces employing the pirate bus (or the F to F jumper wire). After that, he must use the in-debugger-circuit along with the debugger IDLE to access the monitor's memory content 7 . Consequently, the actor must exploit the following three vulnerabilities of the monitor: exploiting debugging interfaces (V 10 ), server hard-coded authentication credentials (V 13 ) and, hardcoded server parameters (V 14 ).
The monitor is once again the target device in Scenario S 4 . Here, the network attack proposed relies on installing a backdoor on the device. In this case, the actor must know beforehand the day when an update will take place. Once done, he must approach the patient's home then, access the patient's private network, and achieve a man-in-the-middle attack exploiting the monitor's remote firmware update session (V 15 ). At that point, the actor must swap the updated firmware for a backdoor. Thus, he will be able to access the target at any later time employing the backdoor.
G2 Gain knowledge of device operation and software G2 can be achieved by performing network attacks on the external devices (S 4 , S 6 , S 7 , or S 8 ), launching a web attack on the programmer software deployment network server (S 5 ), or getting unauthorized physical access to the external devices (S 9 , S 10 ). In the last case we will talk about a physical attack on the external devices.
For the network attacks of Scenarios S 4 , S 6 , S 7 , and S 8 , the actor must either go to the patient's home (S 4 , S 7 ) or the hospital (S 6 , S 8 ). Note that for Scenarios S 4 and S 7 , this must occur the day of an update of the monitor and the programmer respectively. Once on the crime scene, the actor should access either the targeted device network (S 7 , S 8 ) or the communication channel established between the communicating parties (S 4 , S 6 ). In the last case, the communicating parties are the external device and the web server of the entity in charge of the updates. Thus, once in the external device network the actor should either connect himself to the USB port and acquire the file system (S 7 , S 8 ) or have direct access to the devices and therefore to the data (S 4 , S 6 ).
In Scenario S 5 the actor must find the URL from which the programmer update application retrieve files from the server of the software deployment network. Once this is done, he modifies the URL with commands and web server escape code. After that, he sends this URL to the web server by means of a web request. Thus, if the attack is successful, the actor will be able to extract the desired files.
Getting an unauthorized physical access to the external devices (S 9 and S 10 ) is another mean to achieve G2. On Scenario S 9 , the extraction of the programmer hard drive is required. Thus, the actor should go to the hospital and remove it. As far as Scenario S 10 is concerned the attack is on the monitor, that is to say that the crime scene is the patient's home. The sequence of events of this scenario is that of S 3 except that two events are added, namely 1) connect to the debug port of the operating system and then 2) authenticate using the credentials that will have been previously acquired by performing the same actions as in S 3 .
G3 Induce medical staff to make diagnostic errors G3 can be achieved is feasible by achieving three kinds of attacks: a network attack on the programmer (S 11 ), a radio attack on the CIED (S 12 ) or a physical attacks on the programmer (S 13 ).
The sequence of events for Scenario S 11 is practically the same as that for Scenario S 4 . What differentiates both scenarios is the target device. In S 4 , it is the monitor while in S 11 , it is the programmer. Thus the only difference between S 11 and S 4 stems from the first event, that in the case of S 11 is happening in the patient's home.
Scenario S 12 is completely similar to Scenarios S 1 and S 2 . The only change is the actor's behavior. Indeed, in Scenarios S 1 and S 2 he intercepts data; he is a passive actor. In Scenario S 12 , however, he transmits data, thus he is an active actor. The events in Scenario S 12 are otherwise practically the same events as in S 1 and S 2 . We say practically because first, a new event is added. That is the transmission of data. Second, one of the events of S 1 and S 2 is modified. In fact we saw for the G1 scenario the actor would have to configure his antenna in reception mode to intercept the data, while in S 12 it will have to put in transmission mode.
In Scenario S 13 a network attack is performed on the programmer. The actor's purpose here is to introduce a calibration error on the device, by inserting a malware through the device's UBS port connection. In order to do so, he goes to the patient's home, accesses the patient's network, scans the network ports in order to find the one that corresponds to the USB connection, then sends the malware by means of the aforementioned port. As it can be noticed, the sequence of events for Scenario S 13 is quite similar Scenario S 8 . The difference between both is the last event which in S 8 is accessing the device file system while in S 13 it is sending the malware.

G4 Disrupt or lower quality of patient follow-up
The goals of G4 can be accomplised by performing a network attack against the external devices (S 4 , S 11 ), radio attacks against the CIED (S 12 , S 14 ) or physical attack against the monitor.
In the first cases, i.e. Scenarios S 4 and S 11 , the purpose of the attack is to render the data of the external devices unreadable. To do this, the actor will send a ransomware to the devices, i.e. a kind of malware that encrypts the system data. Data restoration consists of applying the same operation to the encrypted data with decryption key. Normally, the malware operator will have generated and kept secret a copy of the decryption key, that will only be revealed to the victim in exchange for ransom. The sequence of the events is similar to that of S 4 and S 11 for the G1 and G2 scenarios. The difference lies in the type of malware used, and this has no effect on the sequence of events.
For the radio attacks, the sequence of events leading to S 12 because is similar to that in G3. What changes between the two attacks goals is the nature of the data transmitted by the actor. In G3, it is a dangerous command, here it is malware. Scenario S 14 consists off periodically sending wake-up com-mands to the CIED to maintain open the incoming wireless communication.
In order to do that, the actor must obtain an SDR, an antenna and a signal processing software. He must track the victim and replay an RF wake-up command every time the wireless session is about to expire.
G5 Alter device behaviour to endanger patient G5 is achievable by perpetrating network attacks on the programmer (S 11 ). These attacks can take several forms as detailed in the Table 4. Indeed, the actor can implement these scenarios to send malicious code that ignores the therapy settings set by the practitioners, or introduces a calibration error into the device, or allows him to access the device by means of a backdoor. Performing a radio attack against the CIED (S 12 ) is another way to accomplish the Goal G5. The actor's purpose here will be to modify the device's RAM section containing the therapy code to be applied to the patient. As those scenarios have already been appearing in previous attacks goals scenarios (G3 and G4), the event sequence will be the same.
G6 Alter device behaviour to decrease quality of life Three kinds of attacks can be carried out in order to achieve attack Goal G6. The first one, S 10 , consists in perpetrating a physical attack on the monitor with the purpose of disabling the device's periodic data transmission. The second one, S 11 , relies on the execution of a network attack on the programmer. The actor introduces a calibration error on the device by inserting malware. The third one, S 14 , is a radio attack on the CIED. The goal will be to maintain a wireless communication session indefinitely open by sending RF wake-up commands. The event sequence is similar to that of Goal G5.

Probabilities of Occurrence
As defined in Section 4.2, the probability of occurrence (P r ) represents the chance that a given threat (actor-scenario pair) materializes. In other words, it is the likelihood that an actor achieves an attack scenario with success. By success we mean the achievement of the attack's goal or what is the same, the engendering of a specific impact on the victim. We calculate the probability by threat. That is, for each actor of each scenario. As explained in the methodology section (Section 4.3), P r is calculated (1) as the sum of the three threat attributes: capacity (c), opportunity (o) and motivation (m). The c, o, m values vary from 1 to 4, with 4 corresponding to a higher likelihood. In the following paragraphs, we justify the rates assigned to c, o, m for each threat, with the overall P r values given in Table 5.

Attack goal G1
Capacity. Scenarios S 1 and S 2 are accomplished by means of radio attacks. The capacit for Actors A3 and A4 are the same (c = 3) for many reasons: the knowledge is abundant and accessible to all the actors, the software tools used to intercept and process RF signals are increasingly simpler to use, thus reducing the attack's technical difficulty, and the equipment needed to perform these attacks (SDR and antenna) is not expensive. For Scenario S 3 , even if the knowledge is accessible to all the actors and the equipment needed to conduct the attack is not expensive, the attack is technically complex to achieve. Indeed, it involves the exploitation of two vulnerabilities for which solid knowledge of computer programming and architecture is required. Normally, Actor A3 recruits experts with exceptional technical skills and have more human resources. They have more capacity than Actor A4. Thus, in Scenario S 3 A3 capacity (c = 2) is higher than the one of Actor A4 (c = 1). Scenario S 4 is a network attack and thus additional material is not required. Additionally, there is nowadays extensive information available and tools to perform the attack in S 4 . Thus, capacity for Actors A3 and A4 will be the same (c = 3) in this scenario.
Opportunity. In Scenarios S 1 and S 3 , the attack takes place in the patient's home. In these cases Actor A3 (o = 2) has a better chance than Actor A4 (o = 1) since they are specifically trained to infiltrate private sites without being noticed. In Scenario S 2 , the attack takes place in the hospital during a patient's medical visit. The latter implies that adversaries only have approximately two days a year to conduct the attack, coinciding with the number of times patients go to the doctor. However, since hospitals are public places, the actors are less likely to be noticed. Thus, the opportunity score for Actors A3 and A4 (o = 2) is the same. In Scenario S 4 the attacks take place during a monitor's update session, which takes place only about once a year.
Actor A3 access to this information and opportunity to leverage it is greater (o = 2) than that of Actor A4 (o = 1).
Motivation. Both Actors A3 and A4 benefit from the crime. They gain access to sensitive personal information. For A3, this attack objective is in line with  the raison d'tre of their profession, i.e. obtaining private information from individuals. Thus the motivation of Actor A3 (m = 2) will be higher than that of Actor A4 (m =1) because for A3 this attack objective is an end in itself while for A4 it is a means to an end (sow national disorder).

Attack goal G2
Capacity. In Scenario S 5 a web attack is launched. There is information and tools available online to perform this kind of attack. Actor type A4 are experts in the field (web attack). On the other hand, Actors A2 and A3 are specialists in the extraction of information from people or systems. In addition, they often have specialized human resources. Thus the capacity of A1, A2 and A3 (c = 4) is the same and it is higher than that of A4 (c = 3). In Scenarios S 4 , S 6 , S 7 and S 8 network attacks are conducted. Once more, information and tools are available to achieve these attacks. However, because they have more know-how than the others on the matter (i.e. network attacks) Actor A4's capacity (c = 4) is higher than that of A1, A2 and A3 (c = 3). The attack performed in S 9 has no major technical complications. It is necessary to remove a hard disk and then mount it later in another computer media. Thus, the capacity of all actors will be the same (c = 4). However, the achievement of Scenario S 10 presents a major challenge. On the one hand, solid technical knowledge of computer programming and architecture is necessary. In addition, there is no extensive information about how to realize the exploit in S 10 . Thus, Actors A2 and A4's capacity (c = 2) is higher than that of A1 and A4 (c = 1) since A2 and A3 normally are experts with exceptional technical skills and have more human resources.
Opportunity. Scenario S 5 is a web attack where there is no restriction of time and space. So the actors' opportunity will be higher and the same (o = 3). Scenarios S 6 and S 4 take place during targeted device update sessions, during which there are constraints in terms of time (update session) and space (near the patient's home or hospital). As far as the time constraint is concerned, Actors A2 and A3 have better possibilities to know when an update session will take place. In terms of space constraint, A2 and A3 have the same opportunities either at the patient's home or in the hospital. However, A1 and A4 will have more chances in the hospital as this is a public place where they can go unnoticed. Thus on the S 6 and S 4 Scenarios, Actors A2 and A3 opportunity is higher (o = 2) than that of A1 and A4 (o = 1). For Scenarios S 7 , S 8 , S 9 and S 10 there is no time constraint but there is still a space constraint. Scenarios S 7 and S 8 require the actor to be near either the patient's home or the hospital in order to access their network, whereas for S 9 and S 10 the actor must to have physical access to the targeted devices.
Similarly as for S 7 , since the attack takes place near to patient's home Actors A2 and A3 opportunity (o = 3) will be higher than the one of Actors A1 and A4 (o = 2). For S 8 however, all actors opportunity score is the same (o = 3) since the attack takes place in a public site. In Scenarios S 9 and S 10 , since the attack requires physical access to the device Actors A2 and A3 opportunity (o = 2) is higher tan that of A1 and A4 (o = 1).
Motivation. All actors benefit from the crime. They gain system information. A2 motivation (m = 4) is the highest since the goal of this attack is the purpose of their profession. Actors A3 and A4 follow them with the same level of motivation (m = 3). The motivation of A1 (m=2) is the lowest because obtaining system information is not an end but a means to accomplish their activities.

Attack goal G3
Capacity. Attack scenarios S 11 , S 12 and S 13 consist in introducing reading or calibration errors on the CIED's ecosystems devices. To do that knowledge of the device inner workings and advanced programming skills are required.
Since there is some but not a lot of available information about how programmers and monitors work, in Scenarios S 11 and S 13 the capacity of A1 (c = 4) will be higher than that of A3 and A4 (c = 3). The reason is that A1 are experts in the development of malicious code. On the other hand, there is much less information available about CIED and their architecture. Thus, for Scenario S 12 , the capacity of the actors will be the same (c = 2). This is due to the fact that while A1 are experts in malware development, A3 and A4 are more likely to obtain the CIED's mode of operation either by hiring personnel skilled in CIED programming or by using other illegal methods.
Opportunity. For Scenarios S 11 and S 12 there are constraints in terms of time and space. Scenario S 11 takes place in the hospital during a session update. Scenario S 12 must be performed near the patient and during an incoming wireless communication with one of the externals devices. In these scenarios, we apply the same opportunity values that we have applied to the scenarios S 6 and S 4 . That is to say that in S 11 and S 12 , Actor A3's opportunity (o = 2) is higher than that of Actors A1 and A4 (o = 1). On S 13 there is only a space restriction, and the same reasoning as in Scenario S 8 is applied: all actors have the same opportunity (o = 3).
Motivation. Actors A1, A3 and A4 all benefit from the attack. Actor A1 conducts these attacks in order to make money, whereas Actors A3 and A4 are motivated by the opportunity to cause harm. Thus, Actors A3 and A4's motivation is the same (m = 3) and higher than that of Actor A1 (m = 1) since for the latter there are other ways to make more money faster.

Attack goal G4
Capacity. In Scenario S 14 a replay attack is performed. There is no major challenge in conducting this attack, which consists in periodically transmitting a Wake-Up command to the CIED by means of an SDR. Thus Actors A1, A3 and A4's capacity is the same (c = 3). However, in Scenarios S 12 , S 11 and S 4 , Actor A1's capacity is higher (c = 3) than that of A3 and A4 (c = 2), since these scenarios consist in implanting a ransomware, and A1 are experts on malicious code development. For Scenario S 15 advanced knowledge in computer programming and architecture is needed. Thus, Actor A3's capacity (c = 3) will be higher because they have more human resources and specialized personnel, followed by, Actors A4 (c = 2) and A1 (c = 1).
Opportunity. In Scenarios S 14 and S 12 there are still constraints in terms of time and space. The actor must be close to the patient in order to send radio commands with its antenna to the CIED . Moreover, the attack must take place while the wireless communication is established in the CIED. As in the other scenarios where these constraints are presents, the opportunity of Actor A3 (o = 2) is always higher than that of Actors A1 and A4 (o = 1). In Scenarios S 4 and S 11 , the situation is the same, the actor being limited by space (home or hospital) and time (update sessions). Normally, when there is only a space constraint all actors have the same opportunity at the hospital (S 11 ) because it is a public place and, while Actor A3 has more opportunity at home (S 4 ). However, since in Scenario S 11 there is the additional the time constraint that it happens during an update session, the actors opportunity will be the same in both scenarios. Thus, in Scenarios S 11 and S 4 the opportunity of A3 (o = 2) is higher than that of A1 and A4 (o = 1). In Scenario S 15 , physical access to the targeted system, i.e. the monitor, is required. Thus, the opportunity for Actor A3 (o = 2) is higher than that of A1 and A4 (o = 1).
Motivation. Actors A1, A3 and A4 all benefit from the attack. By performing these attack scenarios, A3 (m = 2) and A4 (m = 3) would succeed in endangering patients' lives and consequently harming their quality of life, while A1 (m = 1) would make money through ransom.

Attack goal G5
Capacity. Since there is extensive information about the external programmer behaviour, the capacity of Actors A3 and A4 (c = 3) is the same on Scenarios S 11(a) and S 11(c) . For Scenario S 11(b) knowledge of Cardiology is required, and Actor A3 is more likely to have access to personnel with such knowlegde or hiring it. Thus, A3's capacity (c = 2) is higher than that of A4 (c = 1). On Scenario S 12 , the capacity of the Actors A3 and A4 will be the same (c = 2). The reasoning is the same as that for Scenario S 12 (Section 6.3.3), namely the lack of information concerning the CIED's behaviour and implementation.
Opportunity. The analyis of the opportunity factor for Scenario S 14 (Section 6.3.4) apply equally to Scenario S 12 . Thus, the opportunity of A3 (o = 2) is higher than that of A4 (o = 1). The same is true for the analysis of opportunity for Scenario S 11 on Attack Goal G3 (Section 6.3.3), which applies to Scenarios S 11(a) , S 11(b) and S 11(c) . That is to say that the opportunity of A3 (o = 2) is higher than that of A4 (o = 1).
Motivation. This attack goal clearly aims at harming the health of an individual. Thus it is Actor A3 (m = 2) and Actor A4 (m = 3) that benefit most from this attack. We do not give them maximum motivation because there are many faster and equally subtle ways to achieve this goal.

Attack goal G6
For Scenario S 10 the analysis made in Section 6.3.2 in terms of capacity and opportunity equally applies. For Scenarios S 11 and S 14 , the capacity and opportunity socres are the same as those of Section 6.3.3 and 6.3.4,n respectively. In terms of motivation the same reasoning than for Attack Goal G3 (6.3.3) is applied.

Combined risk assessment
Risk assessment values range between 3 and 48. They are calculated as the probability (ranging from 3 to 12) multiplied by the impact (from 1 to 4).

Risk level
Values Management strategy -Unacceptable R= [36,48] Refuse -Undesirable R= [24,35] Manage -Acceptable R= [12,23] Accept -Negligeable R= [3,11] Accept We calculate the risk separately for each impact category. This way of doing things gives insight of the risk that each threat (scenario, actor) represents separately for the health, economy, quality of life and privacy impact categories. Consequently, this analysis responds to the needs of several different groups such as medical practitioners, regulators, manufacturers and even patients. Each will know what the riskiest threat is for him and therefore the one to treat with priority. We ranked the risks in Table 6. Depending on the risk value, different risk management strategies can be chosen and applied. There are four strategies for managing risk, namely refuse, accept, transfer or manage the risk. The most drastic is of course to refuse the risk, which is when the risk is considered unacceptable because of the catastrophic consequences it may have on the victims. In those cases, it is recommended to prohibit, stop using or remove the system posing the threat. The strategy of accepting the risk is applied when the risk is either negligible or acceptable. That is to say when the benefits that the system bring outweigh its potential risks. Transfering the risk relies on giving the risk management responsibility to a third party such as an insurance company. This is a strategy that is not really applicable in those threats where the impact is on patient health or quality of life. Finally, the risk mitigation or risk management strategy consists in reducing the risk as much as possible with available means. This can be done through the updates of the systems, stricter regulations or even awareness campaigns.

Results and Discussion
The attacks goals of inducing medical staff to make errors (G3) and alter device behavior to endanger patient (G5) represent a risk for patient health. Those to gain knowledge of device operation and software (G2), induce medical staff to make errors (G3) and disrupt or lower quality of patient follow-up (G4) represent an economic risk to manufacturers and health organizations.
We can then note that G3 represents a risk for all groups. In terms of privacy or degradation of life quality, none of the attack goals represent a potential risk that needs to be managed. In this section, we focus on those threats representing either an unacceptable or an undesirable risk for the victims' health and economy. The risk results of all the threats herein considered can be found in Table 6 of Appendix A.
7.1. Monetary risk assessment 7.1.1. Monetary risk assessment by attack goals Attack goal G2. This attack goal represents a major risk in terms of economic losses. The victim can be either the manufacturer or the hospital. As hospitals are public organization, it can be considered that it is the whole society that is the victim. G2 contains five unacceptable threats (Scenarios S 4 , S 5 , S 6 , S 7 and S 8 with all actors). These threats should be managed with high priority. By analyzing these threats, we can see that the actor's attack method is always the same, namely exploiting the authentication mechanisms of the target systems, i.e. the external devices and cloud-based systems with which they interact. This fact in itself is good news. On the one hand, external devices are not constrained by the resource limitations as the CIED are, so robust authentication solutions can be implemented without significant problems. There is a plethora of standard robust and proven solutions to secure system authentication, and there is no need to resort to proprietary, unproven solutions. We, therefore, propose the following solutions.
The threats related to Scenario S 4 are solved by securing domestic networks.
To do this, patients must take the habit of securing their network with a robust password, e.g. a password containing upper and lower case characters, numbers and special characters. This password should be periodically changed. Also, the patient should pay attention to the other Internet of Things (IOT) devices that are connected to his network, as they can be the entry door to their network. Accordingly, they should ensure that all devices in their networks are secured with a password.
To solve the threats associated with Scenario S 5 , it is essential to insist that web developers use good code practices and that the source code of web pages be periodically reviewed.
To mitigate the threats associated with Scenario S 6 , hospitals and manufacturers should adopt more reliable VPN solutions even if they require more investment. Besides, hospitals and manufacturers should consider recruiting cybersecurity professionals and technical services whose responsibility will be to ensure that there are no cybersecurity threats in their systems and/or networks, including those used for CIED programming and management.
For the threats associated with Scenarios S 7 and S 8 , the solution involves securing USB ports of monitors and programmers with robust passwords, which should be continuously modified.
The threat posed by Scenario S 9 is not as significant. This means that it must be managed. The solution is simple: physical security of the targets devices, in this case, programmers. In addition, it would be necessary to carry out awareness campaigns among the staff who use those devices, so that they become aware of the scope of the problem and therefore more attentive to the physical security of these devices.
Attack goal G3. The threats associated with the scenarios S 11 and S 13 represent an undesirable risk. In order to mitigate the first threat, hospitals and manufacturers should adopt more reliable VPN solutions. The mitigation of the second threat involves securing the USB ports of the programmers with robust passwords.
Attack goal G4. The threat related to Scenario S 10 represents an undesirable risk whose mitigation is to protect the debugging interface ports with a password.

Monetary risk assessment by attack vectors
From an economic point of view, the vulnerabilities V 6 , V 7 , V 9 , and V 15 must be eliminated, because their exploitation constitutes an unacceptable risk for the hospitals and the manufacturers. V 6 is eliminated by using good programming practices and revising the source code of the programmers' software. V 7 by securing hospital networks, and adopting more reliable VPN solutions. The security of hospital networks can also be improved by implementing efficient identity and access management (IAM) rules. For V 9 , it is necessary to secure the USB ports of the external devices with strong passwords. Finally, securing home networks with strong passwords would eliminate the vulnerability V 15 . Once the vulnerabilities mentioned above have been addressed, vulnerability V 8 must be managed as a priority because its exploitation constitutes an undesirable risk for hospitals. To do that, they must ensure the physical security of the programmer devices.
7.2. Health risk assessment 7.2.1. Health risk assessment by attack goals Attack goal G3. The results of Table 8 reveal that G3 is the riskiest attack goal in terms of health. This is because of the unacceptable risk that Scenario S 13 represents, i.e. the insertion of malware on the programmer through a USB port connection aimed to generate reading errors. Among the riskiest threats of this attack goal, this one must be managed with priority. However, the solution is simple: protect USB port connection with a robust password and frequently change this password. During our observation of operations in a pacemaker clinic, we observed that it is common practice for staff to record the readings of the programmer (during follow-up sessions) in a USB key and then insert the key into a medical report formatting software in a separate computer system. We recommend that staff pay attention because this USB key could be the target of the actors. They could install the malware on it, and it would infect the programmer. Secondly, the computer where the software is located could also be the target of the actor. This means that the actor could infect the computer, subsequently the computer would infect the USB key, and then the programmer. Thus, it is necessary to pay attention to who is using the USB key, and then to ensure that the computer containing the report formatting software is itself secure (e.g. not connected to the network, unless strictly necessary).
The threats related to Attack Scenarios S 11 and S 12 constitute an undesirable risk that need to be mitigated. For Scenario S 11 , the threat consists in the insertion of malware into the programmer. S 11 is achievable by accessing the device network during the programmer update session. The threat, as mentioned above, is avoidable by securing the health center network. Accordingly, it is necessary to implement an efficient method of identity and access management (IAM) of the computer systems of those entities. On the other hand, S 12 threat takes advantage of the improper restriction of communication channels during the programmer updates. As mentioned in Section 6.1, those updates are achieved through a VPN between the device and the entity in charge of the updates. Thus, the health centers and manufacturers must invest in reliable solutions of VPN. For Scenario S 12 , the threat is the insertion of malware on the CIED. This threat is due to the lack of robustness of the CIED authentication mechanisms. One potentital solution consists in implementing more robust authentication mechanisms by using well-known techniques (e.g. asymmetric cryptography). However, CIED are limited in terms of computing resources and such solutions are not the most appropriate. There are, however, other more adequate solutions, which could be applied during the CIED manufacturing process. In particular, we propose that manufacturers use whitelisting techniques in the CIED software, which would prevent devices other than the programmer from sending commands to the CIED.
Attack goal G5. As in Attack Goal G3, the achievement of Scenarios S 11 and S 12 constitutes undesirable risk that must be managed. The same recommendations made for G3 therefore also apply here.

Health risk assessment by attack vectors
From a health point of view, vulnerability V 9 must be eliminated because its exploitation represents an unacceptable risk to the health of individuals. This is feasible by securing the USB ports of the external devices with strong passwords. Once V 9 is adequately managed, Vulnerabilities V 6 , V 7 and V 5 must be managed as a priority because their exploitation constitutes an undesirable risk. To mitigate the risk that V 6 represents, good programming practices and code source revision must take place on the programmer software. To reduce the risk associated with V 7 , the hospital networks must be secured, and reliable VPN solutions must be applied. Finally, to mitigate V 5 it is necessary to apply whitelisting techniques on the CIED.

Conclusion
As evidenced by previous work, CIED are vulnerable to cyber attacks that use their RF interfaces to communicate with external devices (programmer aims to individually support those groups objectives in terms of risk management.
We did three kinds of analysis. First, an actor-based risk analysis to determine who the actors are and what their attack goals are. This analysis allowed us to determine the level of impact of the attacks. We then made a scenario-based risk analysis to determine the probability of occurrence of the attacks. Finally, we performed a combined risk analysis by considering the impact and probability results. We determined the most dangerous attack goals on the one hand, and the most dangerous vulnerabilities on the other.
Our work reveals that the vulnerabilities associated with the RF communication interface of CIED represents an acceptable risk. This is due to the fact that these vulnerabilities have a low probability of being successfully exploited in real conditions (environment other than a research laboratory). However, the network and Internet connectivity of external devices represents a risk that in some cases is unacceptable, i.e. a risk that must be absolutely refused. The answer to our research question is therefore that the real risk is in the external devices and not in the CIED and that this risk is due to the increasing connectivity of said devices. We can therefore see that the problem under study is the medical variant of the trendy cyber-security problem: the lack of security of connected objects (Internet of Thing or IOT).
Indeed, among the 15 vulnerabilities identified, four constitute an unacceptable risk. They are V 6 , V 7 , V 9 , and V 15 and are all to external devices. Five other vulnerabilities (V 1 , V 4 , V 5 , V 8 , andV 10 ) represent an undesirable risk, i.e. a risk that must be addressed. Among the latter two are vulnerabilities specific to CIED (V 1 ,V 4 ). However, their exploitation will have an impact if and only if another specific programmer vulnerability is successfully exploited (V 5 ). There are already existing solutions to avoid all those vulnerabilities. The parties involved have to put them into practice. In order to achieve this, stronger regulation and legislation is needed. These should not be limited to good practice guidelines without any force of law as is the case today. In the same manner, the FDA or Health Canada (or other similar national organizations) should impose that hardware components of medical equipment pass a set of certification tests including cyber security assessment in order to be accepted in the market; the same should be the case for their software components. Finally, the various involved parties (practionners, patients, etc.) should be duly informed of the origin, nature and scope of the threats and how to protect themselves at their level. This information must be disclosed in language that is understandable to them so that they can take part in the solution.
Moreover, our analysis revealed that the attack goals (G2) Gain knowledge of device operation and software and (G3) Induce medical staff to make errors are the main attack goals of the actors. This result shows that while attacks on these devices affect patients, the patients are not always the target as we may have thought so far. The targets in many cases are manufacturers (intellectual property theft) and practitioners (threat of civil liability) for purely economic reasons. Manufacturers should, therefore, be aware of the problem and focus on the computer security of their equipment. The first step to this is avoiding secrecy regarding the software and architecture of their equipment. As has been often posited, code is more secure when it is open source since several people can test it and report errors so that they can be patched. This secrecy about code instead of protecting manufacturers, exposes them more to cyber security risk. Health centers have to become more selective and demanding with the equipment they buy and implant on patients, as this would allow them to put more pressure on manufacturers to make the right cyber security choices.
-------Using the UART interface---------(e 1 )Acquire the hardware (Pirate bus, PC with IDLE debugger) (e 2 )Go to the patient's home (e 3 )Take the patient's monitor (e 4 )Connect one end of the pirate bus to the monitor debug port (exploiting V 10 ) (e 5 )Connect the other pirate bus end to the PC containing the IDLE debugger (e 6 )Access the monitor memory by means of the IDLE debugger (e 7 )Use V 13 and V 14 to adjust the server settings and credentials to authenticate to them (e 8 )Access the server by means of the information obtained in (e 7 ) (e 9 )Read the patient's medical data S 4 : Network attack on the Monitor (e 1 )Gain access to the patients router the day of the monitors update (e 2 )Intercept the updated firmware (V 15 ) (e 3 )Replace the firmware with a backdoor S 5 : Web attack on programmers' SW deployment network server (e 1 )Find the URL in which the programmer (app) retrieve files from the server (e 2 )Modify URL with commands and web server escape code (e 3 )Send the URL to the server(via http request) (e 3 ) (e 4 )Extract the desired files S 6 :Network attack on the programmers (e 1 )Go to the hospital the day of the update (e 2 )Access the programmers network (e 3 )Leverage V 7 to gain access to the programmer (e 3 )Extract the desired files S 7 : Network attack on the Monitor (e 1 )Go to the patient home (e 2 )Acces the patient network (e 3 )Acces the monitors USB port (V 9 ) (e 4 )Navigate in the file system and extract the desired files S 11 : Network attack on the programmer (e 1 )Gain access to the CIED room consultation the day of the update (e 2 )Intercept the updated firmware (V 7 ) (e 3 )Replacing the firmware with malware S 12 : Radio attack on the CIED (e 1 )Acquire the hardware (SDR, antenna, signal processing software) (e 2 )Go to the hospital (e 3 )Be located at a distance relatively close to the CIED (e 4 )Configure the SDR in Transmission mode (e 5 ) Perform a frequency scan of the MICS band to determine the Programmer's transmission frequency (e 6 ) Transmit commands (via RF signals) to the CIED (V 1 ,V 4 ,V 5 ) S 13 : Network attack on the programmer (e 1 )Go to the hospital (e 2 )Access the hospital network (e 3 )Access the monitors USB port(V 9 ) (e 4 )Insert a malware S 14 : Radio attack on the CIED (e 1 )Acquire the hardware (SDR, antenna, signal processing software) (e 2 )Go to the hospital (e 3 )Be located at a distance relatively close to the CIED (e 4 )Configure the SDR in Transmission mode (e 5 ) Perform a frequency scan of the MICS band to determine the Programmer's transmission frequency (e 6 ) Transmit Wake-up commands (via RF signals) to the CIED periodically (V 1 ,V 2 ,V 4 ) VITAE Mikaela Ngamboé holds a degree in Telecommunications Engineering from the Universidad Politécnica de Madrid. She is currently a Master's student at theÉcole Polytechnique de Montréal, within the Computer Systems Security Laboratory. Her research has focused on determining the risk factors that increase the exposure of cyber physical systems to computer attacks. She has studied this issue in systems ranging from traditional information and communication technologies to implantable medical devices.
Paul Berthier holds a degree in Telecommunications Engineering from thé Ecole nationale supérieure des Télécommunications. He holds a M.A.Sc. from theÉcole polytechnique de Montréal. His master's project focused on the cyber security of the Automatic Dependant Surveillance-Broadcast protocol (ADS-B) that allows aircraft to report position, altitude and speed of in real time, and which is intended to replace radar in civil aviation applications. Mr. Berthier worked for two years as a Research Associate in the Computer Systems Security Laboratory at theÉcole Polytechnique de Montréal, managing the aviation cyber security research team in that organization. He works as Senior Cybersecurity Advisor in a private company.
Nader Ammari holds an engineering degree from theÉcole Nationale des Sciences de l'Informatique (ENSI). He holds a M.A.Sc. from theÉcole Polytechnique de Montréal. His master's project focused on the improvement of defenses mechanism of the Return Oriented Programming (ROP) based attacks. An attack method by which it is possible to modify the behavior of a program without injecting malicious code on it. Mr. Ammari worked for one year as the IT security engineer of a firm. He is a Research Associate in the Computer Systems Security Laboratory at theÉcole Polytechnique de Montréal.
Dr. Katia Dyrda holds degrees in Engineering Physics from Queen's University and a degree in Medicine from the University of Ottawa. She trained in internal medicine at Queen's University and then specialized in adult cardiology at the Universit de Montral. Following this, she trained in electrophysiology at the Montreal Heart Institute (MHI) and at the Leiden University Heart Centre in The Netherlands. She now specializes in complex ablation at the MHI where she has been since 2013. She also serves as Cardiology residency program site director for the MHI and EP training program director for Universit de Montreal. Throughout, she has maintained her ties to engineering through multiple research projects but with a special interest in electromagnetic interference with cardiac implantable devices.
Dr. José M. Fernandez, Eng., is a Full Professor in the Computer & Software Engineering Department at theÉcole Polytechnique de Montréal, where he leads the Computer Systems Security Laboratory. His research interests include security of cyber physical systems, in particular critical infrastructure, industrial control systems, and transportation systems in aviation and vehicular traffic. Dr. Fernandez holds a Ph.D. from the Université de Montral, an M.A.Sc. from the University of Toronto and two B.Sc. degrees from the Massachusetts Institute of Technology (MIT). Apart from its academic activity, he has several years of professional experience in computer security in the private and public sector.