## 3 The Proposed Attack Path Discovery
### Cyberattack Path Generation and Analysis Process
Therefore, the vulnerability chain demonstrates and escalates the attack vector from local to network access or vice versa. **Step 5--**Define the threat actor and user profile: A threat actor needs a certain profile to exploit a vulnerability for a successful attack. Depending on the asset dependencies and nature of the vulnerability, the profile may vary. The threat actor profile includes sub-attributes relating to attacker capability (very low, low, moderate, high, and very high) and location (local, adjacent, network, and physical) for an attack campaign by following the NIST SP800-30 guidelines. Additionally, it is also necessary to consider existing users of the healthcare ecosystem and their profiling, which may assist the threat actor to exploit the vulnerability. Depending on the user role and access rights to various systems and other assets, the user profiling can be categorized into three scales of high, medium, and low. **Step 6--**Generate attack paths: This step of the described methodology aims to generate the possible attack paths against target point assets. The individual and chain vulnerabilities are examined using a number of parameters, including assets, vulnerabilities, threat actor profiles, and exploitability level, for this purpose. The vulnerability chain demonstrates a series of exploitation of vulnerabilities using appropriate access vectors and escalation of the privilege. We follow the individual and propagated vulnerability level to determine the attack path. This step is iterative to generate the possible attack paths for the chosen healthcare context and the impact of the vulnerability are considered for selecting the appropriate ones. **Step 7--**Generate and prioritise an evidence-based vulnerability chain: Once the attack paths are identified, it is necessary to generate the vulnerability chains whose exploitation can lead to possible attack paths on given cyber-dependent assets. It is also necessary to collect the evidence relating to the attack path so that we can prioritise which paths need to be taken into consideration for suitable control measures. This step consists of a number of sub-steps (7.1-7.4):  
**Step 7.1--**Identify the vulnerability chain: The attack path discovery relies on unique characteristics, i.e., entry and target point assets and related vulnerabilities, the threat actor's capability, and asset interdependencies to identify all possible paths that can be exploited to gain access by generating vulnerability chains. At this stage, only the vulnerability chains that are under the attack capability for the exploitation are considered. **Step 7.2--**Assess the vulnerability chain: Once all vulnerability chains are identified, it is necessary to assess the vulnerabilities for a given chain. The step considers individual, cumulative and propagation vulnerability values:  
The individual vulnerability assessment (IVL): This measures the probability that a threat actor can successfully reach and exploit a specific confirmed vulnerability in a given asset. We follow the Exploit Prediction Scoring System (EPSS) of individual vulnerability and CVSS 3.1 score metrics (if EPSS is not available) to estimate the vulnerability level. Hence, several external sources such CVSS, EPSS, exploit-db are considered for IVL. Table 1 shows the individual vulnerability assessment scales. A list of generic assumptions for calculating the probability is made. **Assumption 1**. : _If exploitability features (proof-of-concept exploit code or weaponized exploits or arbitrary code execution) are available, then the probability of exploitation for a specific vulnerability is higher than without exploitable features._  
**Assumption 2**. : _If a security control is not defined or there is a lack of evidence about the existing control for a specific vulnerability, then the Attack Complexity (AC) can be low and increase the probability of exploitation. Otherwise, AC should be considered based on the CVSS base metrics._  
**Assumption 3**.