*2.1. PARMS Topology*

Figure 1 shows a modified pacemaker automatic remote monitoring system (PARMS) from [32]. The PARMS includes the following components:

• **Wireless Pacemaker**: This is a battery-powered implantable device that produces an excitatory wave at an appropriate site within the heart. The pacemaker initiates the electrical depolarization cycle of the heart at approximately 72 beats/min in the atrioventricular (AV) node to replace a malfunctioning AV node. The AV node is the electrical connecting point from the atria to the ventricles, which continues excitation beyond a partial or total heart block. Modern pacemakers can also store diagnostic data [33].

**Figure 1.** pacemaker automatic remote monitoring system (PARMS).

The pacemaker consists of a cardiac pulse generator, which is a device with a power source and electronic circuitry that produces the excitatory signal. The pulse generator contains a power source "battery" to power it. It also contains a programmable segmen<sup>t</sup> to evaluate the heart function and send the appropriate electric impulse signal from the pulse generator to the heart [33]. Other components of the pacemaker are the leads which conduct electrical signals from the pulse generator to the tissue and, in some pacemakers, also conduct signals from the tissue to the pulse generator.

The pacemaker has also an electrode which is located at the end of the lead which continuously measures the heart rate. The sensed signal is then amplified using a low noise amplifier. Next, the amplified signal is filtered using a second order low pass filter, and the result is an appropriate electrocardiogram (ECG) signal. This signal is then applied to a comparator which compares it to a defined threshold to detect the heartbeat event executed by the heart and generates a pulse with every heartbeat using a pulse generator [34]. The wireless pacemakers are embedded with a micro-antenna to enable wireless communication with the home monitoring device and the programmer [35].


Communication among the PARMS' components can be summarized as follow [32]:


To illustrate how hacking into the pacemaker's system presents life-threatening risks to patients, two vulnerabilities are identified within PARMS. These are the microprocessor commercial o ff-the-shelf (COTS) vulnerability, and the firmware update vulnerability due to loss of validation of the source of firmware updates [32]. These vulnerabilities can be exploited resulting in the following possible attack instances:

1. *Intelligent Gathering (IG)*: This is used for gathering information about IoT devices such as Internet Protocol (IP) addresses, and checking the type of firmware, as well as the existence of COTS.


#### *2.2. Formal Description of PARMS*

The System can be formally described as follows:

	- • *Pre(IGij)* = *(cij* = *1)* ∧ *(phi* = *root)* ∧ *(pHS* = *none)*
	- • *Pre(SEij)* = *(cij* = *1)* ∧ *(phi* = *root)* ∧ *(phj* = *none)*
	- • *Pre(SEij)* = *(cij* = *1)* ∧ *(phi* = *root)* ∧ *(phj* = *none)*
	- • *Pre(Sij)* = *(cij* = *1)* ∧ *(pHS* = *none)* ∧ *(dHS* = *1)* ∧ *(COTSj* = *1)*
	- • *Pre(PSij)* = *(cij* = *1)* ∧ *(phi* = *user)* ∧ *(dj* = *1)* ∧ *(firmwarej* = *1)*
	- • *Pre(PVij)* = *(cij* = *1)* ∧ *(phi* = *user)* ∧ *(dj* = *1)*
	- • *Pre(SQLij)* = *(cij* = *1)* ∧ *(phi* = *root)* ∧ *(phj* = *user)* ∧ *(dj* = *1)* ∧ *(ej* = *1)* ∧ *(kj* = *1)*
	- • *Pre(MIMij)* = *(cij* = *1)* ∧ *(phi* = *user)* ∧ *(dj* = *1)* ∧ *(ej* = *0)* ∧ *(kj* = *1)*
	- • *Pre(MAij)* = *(cij* = *1)* ∧ *(phi* = *root)* ∧ *(pHS* = *none)* ∧ *(dj* = *1)* ∧ *(ej* = *1)* ∧ *(kj* = *1)* ∧ *(COTSj* = *1* ∨ *firmwarej* = *1)*
	- • *Post(IGij)* = *(dHS* = *1)* ∧ *(pHS* = *none)*
	- • *Post (SEij)* = *(phj* = *user)* ∧ *(dj* = *1)*

• *Post (SEij)* = *(phj* = *user)* ∧ *(dj* = *1)*


14. Initial state: phAP = root ∧ (∀j ∈ {PP, PN}: phj = none ∧ pHS = none ∧ (dj = ej = kj = dHS = eHS = kHS = 0)). (Initially, the attacker has a root privilege on access point, no data identification, no confidential data disclosure, and no ability to alter the setting of HS).

15. Security property ( ϕ): The attacker has no ability to edit the setting on the home monitoring device HS. Thus, jeopardizing patient's life. This property can be then described by a computational tree logic (CTL):

$$\varphi \equiv \text{AG} \left( \mathbf{e\_{HS}} = 0 \right) \equiv \text{AG} \left( \neg \left( \mathbf{e\_{HS}} = 1 \right) \right)$$

#### **3. Attack Graph Generation**

Two software programs were utilized to conduct the cyberattack scenarios' generation and visualization, as shown in Figure 2. These tools are JKind model checker and Graphviz. JKind is a software tool that we used to conduct cyberattack scenarios against the PARMS [40]. The model checker keeps checking repeatedly if a given finite-state model of a system meets a given security property of importance. JKind is an infinite-state model checker for analyzing safety attributes of a system asserted in Lustre, a data flow synchronous terminology arranged for programming reactive systems like automatic control and auditing systems [41]. The JKind employs a back-end satisfiability modulo theories (SMT) solver to validate if a system model complies with a specific temporal logic property in every execution of the system. A wrong execution in which a property is not fulfilled is expressed as a counter example (CE) illustrating a sequence of attack instances (i.e., attack scenarios).

The PARMS depiction model of the parts and their interfaces and links is defined using architecture analysis and design language (AADL), within the open-source integrated development environment (Osate2). The AADL model is confined by assume guarantee reasoning environment (AGREE) annex plug-in in which the constants or variables are established locally. The AGREE plug-in translates the AADL+Annex models and properties to Lustre and communicates with JKind which verifies the system against the security property under study ϕ, and gives the result as a CE.

Considering the given security property ϕ, the goal of the attacker is to gain a root access on the home monitoring device (HS), and therefore gain the ability to alter the settings of the HS. Thus, imposing a life-threatening risk to patient. The JKind model checker generated the following counter example (*CE1*: *IGAP-HS* → *SHS-PN* → *MIMPN-PN* → *MAPN-HS*) as a spreadsheet shown in Figure 3.

This attack sequence can be summarized as follows. Initially, the attacker has a root privilege on AP, an *IGAP-HS* attack is initialized to gather information about the HS (e.g., IP addresses). After the *IGAP-HS* attack an *SHS-PN* attack is launched between the HS and PN to ge<sup>t</sup> login username and password. This will allow the attacker to access the PN with user privilege therefore disclosing patient and HS information. Using the disclosed information, an *MIMPN-PN* attack is launched against the PN components to gain a higher privilege (root privilege). Using this privilege, an *MAPN-HS* attack is conducted exploiting a COTS vulnerability in the HS to gain a root access to it. By doing so, the attacker can alter the settings of the HS which will a ffect the wireless pacemaker and jeopardize the patient's life.

The generated counter example CE1 is encoded in disjunction with the property ϕ under study, that is ϕ ∨ *CE1*. A new counterexample complies with: ¬ *(*ϕ ∨ *CE1)* = ¬ ϕ ∧ ¬ *CE1*, i.e., a counter example of ϕ distinct from *CE1*. This produces a new counter example (*CE2*: *SEAP-PN* → *PVPN-PN* → *MIMPN-PN* → *MAPN-HS*). By continuing this process, three CEs were found, producing the complete attack scenarios (attack graph).

**Figure 2.** Cyber-attack scenarios implementation workflow. AADL: architecture analysis and design language, CE: counter example.


**Figure 3.** CE1 spreadsheet.

In order to visualize the union of generated cyberattack scenarios (attack graph), the Graphviz tool and DOT graph description language are used. Graphviz is a package of open-source tools used to represent structural information as diagrams of abstract graphs and networks. Graphviz takes the descriptions of graphs in a simple text language [20]. The resulting attack graph shown in Figure 4 consists of arrows and nodes. Each arrow illustrates a possible occurrence of an attack instance, while each node represents the system state resulting from executing the attack instance. An attack scenario is a sequence of attack instances represented by any path from the initial node to the final node in the attack graph. The shown attack graph has three attack scenarios that terminate in a reachable state where the settings of HS can be altered by the attacker. Hence, the attacker can gain a root privilege on the pacemaker, which may threaten the patient's life.

**Figure 4.** *PARMS* generated attack graph. MA: Malware Injection, SE: Social Engineering, IG: Intelligent Gathering, MiM: Man-in-the-Middle, SQL: SQL Injection, S: Sniffing, PV: Pivoting, PS: Phishing, HS: Home Monitoring Device, PN: Patient Support Network, AP: Access Point, PP: Physician Programmer pHS: Attacker level of privilege on HS, phi: Attacker level of privilege on host i, di: Data identification of component i; ki: Confidential data disclosure of component i, ei: Data alteration of component i.

The generated graph may aid system administrators to decide the placement of appropriate detection and prevention measures. For instance, experimental results showed that an MA attack can never be correctly conducted against the HS without running MIM or SQL attacks first against the PN. Thus, by way of preventing MIM and SQL, the system administrators can also eliminate the MA attack which would immensely enhance the system security.

In addition to that, the MA attack against the HS required exploiting the COTS vulnerability in its operating system or the firmware update vulnerability. Therefore, securing the HS operating system and deploying an intrusion detection system (IDS) between the HS and the PN may prevent the attacker from executing the remaining attacks.

The feasibility of protecting implantable medical devices (IMDs) is explored by [42] without adjusting them by carrying out security strategies completely on an external device called a shield. The shield is placed between the IMD and possible correspondents, e.g., worn on the body close to the implanted device. The shield performs as a gateway that conveys messages between the IMD and accredited endpoints. Such an approach improves the security of IMDs for patients who already have them and enables medical sta ff to access a protected IMD by discarding the external device or turning it o ff.
