Cybersecurity risk assessment in OT systems using attack graphs

Abstract

Cybersecurity risk assessment is essential for ensuring the security and resilience of Operational Technology (OT) systems, which are increasingly targeted by cyber threats. Traditional assessment frameworks often struggle with complexity, inefficiency, and the inability to adapt dynamically to evolving attack scenarios. In this work, we propose a novel approach that utilizes Attack Graphs to systematically model and assess cybersecurity risks in OT environments. Attack Graphs provide a structured representation of attack paths, enabling a comprehensive analysis of vulnerabilities and potential adversary actions. We extend conventional Attack Graphs by integrating countermeasures and impact assessment, allowing for a more complete cybersecurity risk evaluation process. Our framework facilitates adaptive assessments by efficiently incorporating system or environmental changes and identifying the most critical security threats. We validate our approach through a case study, demonstrating its effectiveness in enhancing OT risk assessment and aligning it with established cybersecurity standards. By bridging the gap between theoretical cybersecurity risk assessment models and practical security challenges, our work contributes to a more proactive and structured defense strategy for OT systems.

1 Introduction

The increasing integration of Operational Technology (OT) with Information Technology (IT) has significantly expanded the attack surface for industrial control systems (ICS), critical infrastructure, and other cyber-physical systems. OT environments, which manage and monitor physical processes in industries such as energy, manufacturing, and transportation, are particularly vulnerable to cybersecurity threats due to their reliance on legacy systems, stringent availability requirements, and the high potential impact of disruptions. Unlike traditional IT systems, where data confidentiality is a primary concern, OT security must prioritize availability and integrity to ensure the safe and reliable operation of physical processes. As cyberattacks on industrial environments grow in sophistication–ranging from ransomware targeting industrial processes to supply chain attacks on embedded control systems–there is an urgent need for advanced cybersecurity solutions that can effectively model, assess, and mitigate cybersecurity risks.

Graphical cybersecurity modeling has emerged as a powerful approach for representing and analyzing cyber threats in OT environments. These models, including attack graphs, Bayesian networks, and threat modeling diagrams, provide a structured and visual means of understanding system vulnerabilities, attack paths, and potential mitigation strategies. Graphical models facilitate cybersecurity risk assessment, decision-making, and automated threat analysis by mapping out the relationships between system components, vulnerabilities, and adversary tactics. However, despite their advantages, existing graphical modeling approaches often face significant limitations in accurately quantifying threats and adapting to the unique characteristics of OT systems.

A major limitation of current graphical models is their inability to handle the quantification of cybersecurity risk across domains, regulatory frameworks, and standards. Existing models often assume independent attack steps, fail to consider countermeasures, or lack the ability to incorporate customizable risk metrics. Furthermore, many traditional models are tailored to specific IT-oriented cybersecurity risk assessment methodologies, making it difficult to adapt them to diverse OT environments with industry-specific operational constraints, architectures, and threat landscapes.

Another critical challenge is aligning existing graphical modeling techniques with evolving cybersecurity standards and best practices. OT security frameworks such as IEC 62443 (Industrial Network Security) [1], the NIST Cybersecurity Framework [2], and ISO/IEC 27001 [3] provide essential guidelines for securing industrial environments. However, many cybersecurity modeling tools struggle to integrate these standards effectively. As a result, organizations often face gaps in compliance, inconsistent threat analysis methodologies, and difficulty in implementing security measures that align with regulatory requirements and operational constraints. Additionally, the heterogeneity of OT environments requires a modeling approach that is both adaptable and scalable to different architectures and use cases.

This research aims to address these limitations by developing an advanced graphical cybersecurity modeling framework specifically tailored for OT environments. Our approach integrates complex attack vector representations, countermeasures with immediate effect on risk calculation, customizable risk calculations, flexibility in attribute and value definitions, as well as aggregation functions. Therefore, enabling security analysts to properly evaluate the cybersecurity risk of OT systems. Additionally, we demonstrate that our methodology can be aligned with cybersecurity modeling techniques with established standards, ensuring that organizations can systematically assess and improve their security posture in compliance with industry best practices.

While risk assessment in IT systems primarily focuses on confidentiality, integrity, and availability of digital assets, OT environments impose fundamentally different requirements. OT systems are tightly coupled with physical processes, and risks must be evaluated not only in terms of technical compromise but also their consequences for safety, availability, and operational continuity. Standards such as ISO/SAE 21434  [4] and CLC/TS 50701  [5] highlight that OT risk assessment therefore requires incorporating both attacker feasibility and the potential physical or safety-related impacts of successful attacks. Existing IT-oriented approaches, which emphasize probabilistic likelihoods of compromise or vulnerability exploitation, are difficult to apply in this context due to scarce incident data, long system lifecycles, and the safety-critical nature of OT. Our framework extends attack graphs to explicitly address these OT-specific needs by integrating feasibility scoring and consequence modeling into a unified graphical representation.

The remainder of the article is structured as follows: Section 2 presents the background information on cybersecurity risk assessment in OT systems as well as attack and defense modeling. Section 3 discusses related work. Our definition of Attack Graphs is given in Section 4. We use a well-known and simple example, the attack tree described by J.D. Weiss in 1991 [6], to illustrate these aspects of Attack Graphs. The necessary adjustments to use these Attack Graphs are presented in Section 5, including an example of how a cybersecurity risk assessment for a railway system can be performed graphically, while being conform with existing relevant standards. Section 6 validates our defined framework by showing how it can realize the cybersecurity assessment processes of ISO/SAE 21434  [4] and CLC/TS 50701  [5] respectively, again using the attack tree by Weiss as an illustration example. Section 7 presents an overview on the case study of future railway systems, where we analyzed which cybersecurity threats to these systems require more research and standardization. Scalability and practicality of our methodology are evaluated by applying it to future railway scenarios in Section 8. To create the graphs and evaluate our proposed framework, we developed a publicly available plugin tool for diagrams.net¹, providing a user-friendly development and visualization of attack graphs and mechanisms that automatically recalculate risk values upon dynamically changing attributes or adding or deleting nodes. Section 9 concludes the article.

2 Background

Before presenting our approach, we first provide background on the specific requirements of cybersecurity risk assessment in OT systems and the role of graphical modeling in this context. This background establishes the domain-specific challenges, highlights the expectations set by relevant standards, and motivates the need for structured, transparent, and scalable methods.

2.1 Cybersecurity risk assessment in OT systems

Cybersecurity in OT environments differs fundamentally from IT contexts. OT systems in domains such as railway signaling, automotive electronics, and industrial automation prioritize safety, availability, and reliability. Updates and patches are restricted due to certification requirements, real-time operation, and long system lifetimes. This creates a strong dependency on proactive risk management methods that can identify and mitigate threats early.

Several standards define processes for risk management, including ISO/SAE 21434 [4] (automotive), IEC 62443 [1] (industrial automation), and CLC/TS 50701 [5] (railway systems). These standards prescribe structured assessment of assets, threats, vulnerabilities, feasibility, and consequences, but they typically do not prescribe how such assessments should be operationalized. In practice, this leads to a gap between high-level requirements and practical methods for cybersecurity risk analysis.

2.2 Graphical modeling for cybersecurity risk assessment

Graphical models are widely used in cybersecurity to represent adversarial behavior, dependencies between system components, and the effect of countermeasures. Their visual nature supports communication across interdisciplinary teams and provides a structured foundation for systematic risk assessment. Unlike textual or matrix-based methods, graphical models make attack propagation explicit, allowing analysts to reason about both attacker capabilities and system vulnerabilities.

2.2.1 Attack modeling

In 1991 J. D. Weiss [6] introduced a graphical solution for threat modeling called threat logic trees. Today, all AND-OR tree structures representing attack vectors are referred to as attack trees, a term first introduced by Salter et al. in 1998 [7]. Since then graphical solutions to present cybersecurity landscapes have become popular and various frameworks have emerged to handle different domains and use cases, including different features.

The strengths of Attack Trees lie in clarity and intuitive structure. However, they are inherently static and limited in scalability, since they cannot easily represent converging attack paths, or interdependencies. To address these limitations, Attack Graphs [8] extend the tree structure to a Directed Acyclic Graph (DAG), allowing multiple attack paths and more realistic modeling of system states. Subsequent extensions such as Bayesian Attack Graphs [9] and multi-parameter extensions [10] incorporate probabilities and temporal logic, enabling quantitative analysis. While these methods increase expressiveness, they often rely on detailed quantitative data (e.g., probabilities of success, exploit likelihoods) that are rarely available in OT environments. Furthermore, their complexity limits accessibility for practitioners who are not experts in probabilistic modeling.

2.2.2 Defense modeling

Recognizing that risk assessment must also account for mitigations, several extensions to attack modeling have incorporated defenses. Attack–Defense Trees [11] enrich traditional Attack Trees by introducing defensive measures as counter-nodes, allowing analysts to reason about potential mitigations alongside attack steps. Similarly, Attack Countermeasure Trees [12] provide a semi-quantitative framework for assessing how countermeasures affect the likelihood of attack success. Other variants, such as Bayesian Defense Graphs [13] and Boolean logic Driven Markov Processes (BDMPs) [14], further extend expressiveness by capturing costs, probabilities, and time factors. These approaches illustrate the importance of representing defensive actions, but they typically remain constrained to hierarchical structures or require probabilistic inputs that are not always feasible in OT systems.

2.2.3 Implications for risk assessment

Together, attack and defense modeling approaches demonstrate both the potential and the limitations of graphical models in cybersecurity. Attack-focused models provide clarity and scalability but often fail to capture defenses or operational consequences. Defense-focused models introduce mitigation effects but remain tied to restrictive structures or demanding data requirements. As a result, existing approaches capture only subsets of what is needed for comprehensive OT risk assessment. In particular, OT standards emphasize feasibility scoring, countermeasure integration, and consequence modeling, requirements that are only partially addressed in current graphical modeling methods.

These observations motivate the definition of a framework that integrates the strengths of existing models while addressing their shortcomings.

3 Related work

Recent advances in graphical risk assessment have focused on integrating uncertainties and improving efficiency in risk analysis. Additionally, recent research highlight the importance of comprehensive risk assessment in OT systems and the need for adaption of risk assessment methods to OT requirements and regulations. We also reviewed existing tools to create visual representations of attack graphs and support cybersecurity risk calculations. While many tools exist, most are inflexible in attribute and value assignment, or can not adapt OT standard practices, like proposed in IEC 63443 [1] or CLC 50701 [5].

3.1 Risk assessment

Kutej et al.  [15] introduce a graphical approach to risk assessment that incorporates the representation of uncertainties, comparing it with traditional risk and opportunity assessment methods. The study employs various aggregation methods and tests them using a case study in critical infrastructure. However, while their study analyzes the statistical differences between traditional and their proposed graphic risk assessment method, the absence of a definitive truth prevents a direct validation of the results.

Zhang et al.  [16] propose a flexible attack graph generation algorithm, which can be appliesd for large-scale heterogeneous industrial control systems (ICSs), and includes a quantitative assessment method. They mainly use CVE-NVD and CNNVD as a data source for vulnerabilities to generate the graph, and CVSS data for probability assessment. They do not describe how the impact of vulnerabilities are assessed, and calculations are done in separate tables instead of directly in the graph.

Kern et al.  [17] generate attack paths for automotive systems in a semi-automated way to reduce the manual effort of attack path generation. To automatically generate the attack paths a preliminary system architecture and an asset list need to be defined and threat agents need to be assigned. Several other works dealt with automatically generating attack trees, like [18, 19], and even attack graphs [20,21,22]. However, none of these include countermeasures or the automation of attack evaluations or risk calculations.

Viticchié et al.  [23] extend the MulVAL attack graph framework [24] to enhance scalability and integrating domain-specific enhancements and advanced pruning techniques. MulVAL models vulnerabilities and attack paths using a rule-based system [25], and requires significant adaption to manage the complexity of OT systems [23]. While they propose a method for attack graph generation, they do not include risk calculations and metrics.

Yang et al.  [26] propose a dynamic risk assessment framework for Industrial Internet of Things (IIoT) security based on Bayesian Attack Graphs [9] that enhances vulnerability evaluation and enabling system-level security posture analysis. Vulnerability evaluation is based on the CVSS system and enhanced using exploitability quantification and industrial attribute integration, introducing observability and controllability. System-level security posture analysis is enabled using probabilistic attack path modeling. While this approach includes the impact on security metrics, like confidentiality, integrity and availability (based on CVSS metrics), it does not include the impact on stakeholder consequences, like financial, regulatory, or safety.

Recent research highlights the importance of comprehensive risk assessment in OT systems. Hollerer et al.  [27] propose a methodology integrating safety and security metrics to evaluate risks in industrial architectures. They propose a mapping of CVSS scores to the Security Level (SL) and the Safety Integrity Level (SIL). As the SL only considers an attacker’s intention, motivation, skills, and resources, the potential impact is not considered in this mapping. Instead they use SIL of the OT component, business-criticality of the asset, and SL-Target of zone targeted by an attack as impact-indicator. This method provides a good basis to combine security and safety requirements, but in our opinion their approach of impact-indicating lacks the preciseness needed to examine all stakeholder interests.

Semertzis et al.  [28] propose a quantitative risk assessment method for cyber-physical systems. The likelihood is computed using the Time-to-Compromise and Mean-Time-to-Detect metric. They also propose a domain-specific language to describe OT assets of electrical power systems and models the attack graph. Impact assessment is modeled using a digital twin that computes system dynamics and simulates cascading failures caused by cber attacks. As their method requires a digital twin, it is not suitable for early stages of systems but more for existing systems. However, we believe that for future systems security should already part in the designing phase, especially in safety-critical systems. Furhtermore, their approach does not include risk reduction methods.

Gao et al.  [29] use Attack Countermeasure Trees [12] and combine them with a quantitative risk assessment of threats on SCADA systems. To calculate the risk they use the three indicators vulnerability, defense capability, and attack impact. The vulnerability is calculated using cost and stealth, the defense capability is measured using the number of existing countermeasures and the employed password policy, and the impact is determined using the indicators confidentiality, integrity, availability, operation, organization, and infrastructure. While this approach utilizes cybersecurity risk calculations in a graphical modeling approach, the calculation and the indicators used are fixed. Hence, this approach is not flexible enough to adapt to various OT cybersecurity risk standards. Furthermore, there is no qualitative assessment of countermeasures, as they only consider the number of countermeasures.

OT standards, like IEC 62443 [1], ISO/SAE 21434 [4], and CLC 50701 [5], provide examples for semi-quantitative approaches to evaluate cybersecurity risk. Semi-quantitative risk assessment approaches combine qualitative and quantitative methods by assigning scored scales, e.g., 1-5, to likelihood and impact instead of vague categories, e.g., low, high, or severe. These scores may be mapped to qualitative terms and allow arithmetic operations. This approach is more systematic and repeatable than purely qualitative, and does not demand full statistical data, while supporting priorization.

3.2 Graphical risk assessment tools

Several tools exist to create attack trees. Some can incorporate countermeasures and some even include the possibility to perform calculations. We differentiate two types of tools: (1) tools that only allow for the generation of trees, and (2) tools that can also represent graphs. In this section we present and discuss some of the more prominent tools.

3.2.1 Attack tree tools

Attack tree tools allow for a hierarchical structure with a clear parent-child relationship, typically rooted at a top-level goal. They often use Boolean logic (AND/OR) to show dependencies between sub-goals or attack steps. These tools usually focus on identifying and analyzing paths to achieve a specific goal, often for risk analysis or decision-making. The most prominent tools of this category are: the ADTool², SeaMonster³, and ThreatModeler⁴. These tools enable the creation of attack trees using AND/OR tree logic. Some of these tools allow for the modeling of countermeasures, like the ADTool. SeaMonster and the ADTool also integrate risk calculations. However, these calculations are not flexible and cannot directly be adjusted to existing OT standards. Tools like ThreatModeler use predefined templates to generate attack trees and come with an extensive threat library, which is good for consistency, but requires workarounds for unique or emerging attack vectors. In summary, there are some tools that minimize the manual workload for analysts and enhance consistency. However, the lack of flexibility in attributes, calculations, and connectors, as well as the inability to generate graph structures, makes these tools unsuitable for OT cyber risk assessments according to existing standards.

3.2.2 Attack graph tools

Attack graph tools allow for a general graph structure (nodes and edges), which can represent complex, multi-dimensional relationships, including cycles. Attack graphs are often used to depict all possible attack paths within a system, showing multiple entry points, intermediate states, and goals. They are usually used for analyzing system-wide vulnerabilities, attack chains, or even multi-stage attacks. Their visualization is more flexible and allows non-hierarchical structures, loops, and multiple connections between nodes. The most prominent tools in this category are: MulVAL (Multi-host, Multi-stage Vulnerability Analysis Language) [30, 31], Cauldron [32], Neo4j⁵, the Attack Graph Generator⁶, Graphviz⁷, ArchiMate⁸ [33], and STRIDE GPT⁹. Some tools can generate graphs automatically based on configurations, like Cauldron or the Attack Graph Generator, others integrate Large Language Models, like STRIDE-GPT. Inputs are usually combined with threat databases, like Common Vulnerabilities and Exposures (CVE). Other tools have their own modeling language instead of a drag-and-drop user interface, e.g., MulVAL is based on the Datalog modeling language and Graphviz is based on the DOT language. Neo4j is a database management platform that stores security data, like vulnerabilities, network topologies, and access paths, and generates graphs according to queries using the Cypher language. The tools MulVAL, Cauldron, Attack Graph Generator, and Graphviz do not provide any cybersecurity risk calculations at all. While Neo4j and ArchiMate provide possibilities for cybersecurity risk calculations, those need to be separately queried in case of Neo4j and are not automatically integrated, and ArchiMate does not consider the cybersecurity risk reduction of countermeasures. Furthermore, the visualization options regarding MulVAL are limited and may need to be combined with external tools for clearer presentation, Cauldron lacks flexibility for customized attack graph generation outside its default parameters, and the Attack Graph Generator does not model countermeasures. Finally, ArchiMate models systems and their interactions, but does not natively support representing dynamic attack paths or adversarial activities, like attack graphs or attack trees, as its focus is regarding business and IT architecture rather than modeling the flow of cyberattacks.

4 Attack graphs

Fig. 1

Attack tree about obtaining administrator privileges on a UNIX system, designed by Weiss in 1991 [6]

Existing solutions either do not provide all characteristics to perform risk assessment including risk calculations directly in the graphs or they are constricted by not being flexible enough to support various standards and domains. Therefore, we define an attack graph methodology that is applicaple to evaluate the cyber risk landscape for OT systems. In this section, we define what we understand as an attack graph as well as the necessary parts that are needed to create a basic attack graphs displaying attack vectors and to perform calculations on the graph to evaluate it. In Section 5, we define additional parts that extend the attack graph definition of this section to enable cyber risk calculations and evaluations. In this section and the next, we define the general properties. We do not have a specific implementation in mind, rather we want to define it in a way so that this framework is applicable to all cybersecurity risk standards and all domains. This is necessary as different domains use different standards. All specific implementations used in these two sections are purely exemplary and only used to illustrate how the theory would work in praxis. We propose the use of a DAG structure for the development of the security modeling framework. DAGs consist of nodes, which are connected through directed edges that do not form any loops. For a better understanding we use Weiss’s attack tree [6] shown in Fig. 1 to illustrate the main components for a DAG structure. This is a rather old example that was purposefully chosen for its simplicity and prominence. For current and more complex scenarios see Section 7.

4.1 Attack graph components

This section summarises the main components of an Attack Graph.

Nodes

Nodes represent the attacker’s goals. There are three different types of nodes: (1) Root Nodes, the set of which is defined as $\mathcal {R}$, (2) Leaf Nodes, the set of which is defined as $\mathcal {L}$, and (3) Inner Nodes, the set of which is defined as $\mathcal {I}$. Finally, all nodes $n \in \mathcal {N}$ form the set $\mathcal {N}$:

$\mathcal {N} = \mathcal {R} \cup \mathcal {L} \cup \mathcal {I}$.

Edges

Edges indicate relations between nodes. Attack Graphs use directed edges, thereby enabling nodes to have predecessors (also called parents or ancestors) and/or successors (also called children). The set of predecessors of a node $n \in \mathcal {N}$ is defined as $Pred_n$, and the set of successors of a node $n \in \mathcal {N}$ is defined as $Succ_n$. For example, for node n := “Access System Console” in Fig. 1, $Pred_n$ = {“Obtain Admin. Privileges”} and $Succ_n$ = {“Enter Computer Center”, “Corrupt Operator”}.

Root Nodes

A node that has no predecessor is a Root Node $r \in \mathcal {R}$. Root Nodes indicate the main goal of the attack. For example, the Root Node in Fig. 1 is “Obtain Admin. Privileges”.

Leaf Nodes

A node that has no successor is a Leaf Node $l \in \mathcal {L}$. Leaf Nodes indicate basic actions that can easily be understood and quantified. Examples for Leaf Nodes in Fig. 1 are “Break in to Comp. Center”, “Obtain Password File”, and “Corrupt Sys. Admin”.

Inner Nodes

A node that has at least one predecessor and at least one successor is an Inner Node $i \in \mathcal {I}$. On one hand, Inner Nodes are specialized actions, goals, or sub-goals of their predecessor nodes. On the other hand, they are generalized actions or goals of their successor nodes. Examples for Inner Nodes in Fig. 1 are “Access System Console” and “Enter Computer Center”.

Node Attributes

Nodes are refined into sub-goals until they represent basic actions. Basic actions can then be quantified by assigning attributes, which are quantifiable properties, to nodes. A set of node attributes is defined as $\mathcal {A}$. For every $a _k \in \mathcal {A}$, we assign a value $v _m \in \mathcal {V}_k$, where $\mathcal {V}_k$ is the finite set of acceptable values of the attribute $a _k \in \mathcal {A}$. The process of assigning values to an attribute is defined by the function g:

$g(a _k) = v _m$,

where $a _k \in \mathcal {A}$ is an attribute of a node $n \in \mathcal {N}$, and $v _m \in \mathcal {V}_k$ is a value of this attribute. The set $\mathcal {F}_g$ contains all functions g that assign values to attributes.

The number of attributes as well as their numerical range depends on the used method for cybersecurity risk assessment. Both the number of attributes as well as the value ranges might differ from domain to domain and, consequently, from standard to standard. Before cybersecurity risk assessments are performed, attributes and domains need to be defined. Furthermore, they should be consistent for all use cases and attack graphs in this domain to ensure consistency.

Edge Attributes

The relation between nodes can be quantified by assigning attributes to edges. A set of edge attributes is defined as $\mathcal {A}_\mathcal {E}$. Edge attributes cannot be assigned to nodes, and similarly, node attributes cannot be assigned to edges. Therefore, $\mathcal {A}_\mathcal {E} \cap \mathcal {A} = \emptyset$.

Connectors

Connectors $c \in \mathcal {C}$ indicate the refinements of nodes. Conjunctive refinements (AND) indicate that all successor nodes need to be fulfilled to achieve the refined node’s goal. Disjunctive refinements (OR) indicate that at least one successor node needs to be fulfilled to achieve the goal of the refined node. Conjunctive and disjunctive refinement are just examples. Any form of refinement can be used and implemented in the framework and the developed tool. Other refinements can be, e.g., XOR ($\oplus$) or k-out-of-n.

Aggregated Attributes

By definition, a node $n \in \mathcal {N}$ and all successor nodes $Succ_n$ have the same set of attributes. Hence, the attribute values of node $n \in \mathcal {N}$ can be determined by aggregating the attribute values of all of its successor nodes $Succ_n$.

For example, let $n_2$ and $n_3$ be successor nodes of $n_1$, with $n_1$, $n_2$, $n_3 \in \mathcal {N}$. Further, let $a_1$ be an attribute from the set $\mathcal {A}$. Then, there is a set $\mathcal {V}_1$ with acceptable values for the attribute $a_1$ and all three nodes have this attribute. To determine the value for $a_1$ of node $n_1$, the values of $a_1$ of the nodes $n_2$ and $n_3$ are aggregated using a function f. Whereas the result value needs to be in the set of acceptable values $\mathcal {V}_1$ for $a_1$.

An attribute value can be typically computed using a function that returns (1) the maximum, (2) the minimum, (3) the sum, or (4) the product of a set of given attribute values. In this case, the set of attribute values $v_m \in \mathcal {V}_k$ needs to be arranged in a natural sort order, where $x_{min}$ is the smallest and $x_{max}$ is the largest value of the set. The following functions are commonly utilized for aggregating attributes. However, our framework is open to other functions as well. In the following definitions, $a_1$ represents the attribute for node $n_1$, $a_2$ represents the attribute for node $n_2$, and so on. Thus, all attributes $a_1$, $a_2,...$ represent the same property, e.g., knowledge needed to perform this action.

Maximum. The maximum function takes only the highest value:

$f_{max}(g(a_1), g(a_{2}),~\dots , g(a_{k})) = \max \{ g(a_1), g(a_{2}),~\dots , g(a_{k})\}$.

Fig. 2

Attack Graph about obtaining administrator privileges on a UNIX system, enhanced with the seven characteristics proposed in this article. The color coding of the nodes identifies Leaf Nodes (green) and countermeasures (blue). The color coding of the node attributes in the upper right corner underlines the severity of a result even without knowing the value range for this attribute (neon green: negligible, light green: low, yellow: medium/moderate, light red: severe, dark red: critical / very high)

Minimum. The minimum function takes only the lowest value:

$f_{min}(g(a_1), g(a_{2}),~\dots , g(a_{k})) = \min \{ g(a_1), g(a_{2}),~\dots , g(a_{k})\}$.

Sum. The sum function adds the values:

$f_{sum}(g(a_1), g(a_{2}),~\dots , g(a_{k})) = \min \{\sum \limits _{j = 1}^{k} g(a_j), x_{max}\}$.

Product. The product function multiplies the values:

$f_{prod}(g(a_1), g(a_{2}),~\dots , g(a_{k})) = \min \{\prod \limits _{j = 1}^{k} g(a_j), x_{max}\}$.

4.2 Attack graph definition

Following our definitions from Section 4.1, we define an attack graph as follows:

A directed acyclic Attack Graph $\mathcal {G} = \{\mathcal {N},\mathcal {E}, \mathcal {C},\mathcal {A},\mathcal {V},\mathcal {F}_f,$ $\mathcal {F}_g\}$ contains logical connectors $\mathcal {C}$ and depicts an attack scenario. The edges $\mathcal {E}$ are weighted, and the nodes $\mathcal {N}$ include attributes $\mathcal {A}$ that represent the difficulty of performing this attack step. Attributes have a predefined set of values $\mathcal {V}$. Finally, functions in the set $F_g$ assign the values to the attributes, and functions in the set $F_f$ aggregate values of successor nodes.

5 Attack graph risk assessment

We enhance the Attack Graph definiton presented in Section 4 with (1) Consequence Nodes, which indicate the negative consequences of the main goal of the attack and create a relation to constitute the impact of an attack, (2) Attack Feasibility Attributes, which indicate the ease of launching an attack, and (3) Countermeasure Nodes, which indicate security measures for either preventing or mitigating attack steps or the impact of those. As a visual demonstration example we adapt the attack tree shown in Fig. 1. The adaptations are shown in Fig. 2 and are used as an example to represent the definitions of the previous section (Section 4) and this section (Section 5). Green nodes in Fig. 1 represent Leaf Nodes defined in Section 4.1. This is used for an easier visual understanding where the attack vector ends. Countermeasure nodes are displayed in blue.

Consequence Nodes

In Attack Graphs, Consequence Nodes (i.e., “Data Leakage” and “Denial of Rightful Access to the System”), shown as rounded corner rectangles, become the highest nodes (i.e., the Root Nodes) in the tree structure. They indicate the negative consequences of the main goal of the attack, which is now represented by the topmost Inner Node (i.e., “Obtain Admin. Privileges”). For the rest of the article, Root Nodes are referred to as Consequence Nodes.

Consequence nodes are not part of the set $\mathcal {N}$ and build their own set $\mathcal {N}_C$, with $\mathcal {N} \cap \mathcal {N}_C = \emptyset$, and with a different set of attributes $\mathcal {A}_R$, with $\mathcal {A}_R \cap \mathcal {A} = \emptyset$. This is necessary as nodes of the set $\mathcal {N}$ represent actions with their attributes, consequently describing properties necessary to perform the action or how easy it is to perform this action. Whereas nodes of the set $\mathcal {N}_C$ describe the consequences of actions, and thus their attributes typically describe the risk of that consequence to arise.

Attack Feasibility Attributes

For cybersecurity risk calculations, it is necessary to evaluate whether an event is likely to occur. In business risk management, such feasibility is typically expressed as a probability. While our framework is capable of supporting fully quantitative probabilistic modeling, in practice this is often impractical in cybersecurity and particularly in OT systems, because of the lack of reliable incident data, the uniqueness of system configurations, and the dynamic nature of evolving threats. Almost all security standards therefore rely on qualitative or semi-quantitative measures to express likelihood, typically using scales such as “low to “very high”. Depending on the domain and standard, this attribute appears under different names: attack feasibility (ISO/SAE 21434  [4]), likelihood (CLC/TS 50701  [5], IEC 62443 [1]), or attack/success probability. To avoid confusion with these varying definitions and to emphasize the focus on attacker effort and conditions rather than statistical frequency, we adopt attack feasibility as an umbrella term. In our framework, feasibility is thus assessed semi-quantitatively by default, while still allowing probabilistic extensions when sufficient data is available.

Fig. 3

Example Node $n_1$ with the attributes $a_1$, $a_2$, and $a_{k-1}$ as well as the attack feasibility attribute $a_k$. The attributes $a_1,~a_2,~\dots ,~a_{k-1}$ are assigned the values $v_n,~v_p,~\dots ,~v_{q}$

We can assign an attack step an attack feasibility, which is computed based on its attributes. The Attack Feasibility Attribute is computed using either (1) a function of a set of given attribute values, (2) a matrix of a set of given attribute values, or (3) both. The actual method depends on the used method/standard for cybersecurity risk assessment. To further demonstrate the calculations, we use the node $n_1$ with the attributes $a_1$, $a_2$, and $a_{k-1}$ as well as the attack feasibility attribute $a_k$ shown in Fig. 3 as example.

In the first case, the value $v _m \in \mathcal {V}_k$ of an Attack Feasibility Attribute $a _k \in \mathcal {A}$ of a node n is computed using a function that aggregates the attributes $a _{1}, a _{2},~\dots , a_{k-1} \in \mathcal {A}$ of node n:

$v _m = f(a _{1}, a _{2},~\dots , a_{k-1})$.

For the example node given in Fig. 3 this would result in aggregating the values $v_n$, $v_p$, and $v_q$ of the attributes $a_1$, $a_2$, and $a_{k-1}$. The resulting value $v_m$ is taken as the attack feasibility attribute $a_k$.

Similarly, in the second case, a set of attributes $\{a_1, a_{2},$ $~\dots , a_{k-1}\}$ is aggregated over a d-dimensional matrix, where d is defined as the amount of elements in the set $d:= |\{a_1,~a_{2},~\dots ,~a_{k-1}\}|$. An example of a 2-dimensional matrix is shown in Table 1. Here, for a node n with attributes $a_1$ and $a_2$, there exist a set of values $\mathcal {V}_1:= \{v_0, v_1,~\dots , v_{m_1}\}$ for $a_1$ and a set of values $\mathcal {V}_2:= \{u_0, u_1,~\dots , u_{m_2}\}$ for $a_2$. As such, the aggregation of $\mathcal {V}_1$ and $\mathcal {V}_2$ returns a set of values $\mathcal {V}_3:= \{v_{00}, v_{01},~\dots , v_{{m_1}{m_2}}\}$ for an Attack Feasibility Attribute $a_3$.

Table 1 Aggregation of attributes $a_1$ and $a_2$ using a 2-dimensional matrix, with $a_1$ and $a_2$ being attributes of a node n

Returning to our example in Fig. 3, Table 1 allows to aggregate values of attributes $a_1$ and $a_2$ using a 2-dimensional matrix.

In the third case, a function and matrix are combined arbitrarily. An example that is also used later is that the (genuine) subset $s \subset \{a_1, a_{2},~\dots , a_{k-1}\}$ is aggregated using an |s|-dimensional matrix, which generates a preliminary result $v_{pre}$. The remaining attributes $r:= \{a_1, a_{2},~\dots , a_{k-1}\} \setminus s$ are then aggregated together with $v_{pre}$ in a function f, generating the final result. For example, let s be the set of values $\{a_1, a_{2},~\dots , a_{k-2}\}$ which are aggregated to form the preliminary result $v_{pre}$. Then $r = \{a_{k-1}\}$ and the result v is calculated by using the function f over the preliminary result $v_{pre}$ and the value of $a_{k-1}$: $v = f(v_{pre}, g(a_{k-1}))$.

Using the example node $n_1$ of Fig. 3, the attributes $a_1$ and $a_2$ could be combined according to Table 1, with $v_{pre} \in \{v_{00}, v_{01},~\dots , v_{{m_1}{m_2}}\}$. Then we use a function f to combine the value $v_{pre}$ with the value $v_q$ of attribute $a_{k-1}$ resulting in the value $v_m$ of the attack feasibility attribute $a_k$: $v _m = f(v_{pre}, v_q)$. Examples for the function f are given in Section 4.1Aggregated Attributes. Attributes can be arbitrarily chosen to fit certain cybersecurity standards.

As a specific example, consider Fig. 2, when the attributes Resources, Knowledge, and Location are combined to compute the Attack Feasibility in a combination of a 2-dimensional matrix and a function f. The function, attributes, and ranges are described in detail in Section 5.1. To enhance readability of the Attack Feasibility Attributes, we depict them as colored squares on the top right of Inner Nodes, indicating the ease of launching an attack. As described later in Section 5.1, the scale of the attack feasibility used in the example shown in Fig. 2 ranges from 1 (negligible feasibility $\hat{=}$ attack is hard to perform) to 5 (very high feasibility $\hat{=}$ attack is easy to perform). An attack (step) that is hard to perform, therefore, results in a lower feasibility value. In contrast, an attack (step) that is easy to perform results in a higher feasibility value. We used a traffic light color scheme to support readability of this information, ranging from neon green for the value 1 to dark red for the value 5.

Countermeasure Nodes

Finally, Countermeasure Nodes (i.e., “Physical Access Restriction”, “Firewall” and “Vulnerability/Malware Scans”), shown as light blue nodes in Fig. 2, are included to indicate the security measures taken to mitigate the risk. Countermeasure Nodes are used to represent existing and planned defense mechanisms. Existing defense mechanisms depict a realistic view of the security landscape. Adding planned defense mechanisms supports the decision process for countermeasures as their impact on the threat landscape is directly noticeable.

Fig. 4

Example of an attack node $n_1$ and a defense node $d_1$ with the attributes $a_1$, $a_2$, and $a_{k-1}$ as well as the attack feasibility attribute $a_k$. Included are the respective values for the attributes

There are two ways how those countermeasures can influence the risk assessment process. First, there are countermeasures that mitigate or prevent specific attack steps. These are attached as new leaf nodes, as shown in Fig. 2. Using the aggregation functions described in Section 4.1, the node attributes of the parent nodes are influenced. As example, consider Fig. 4 which shows an attack step $n_1$ with attributes $a_1$, $a_2$, and $a_{k-1}$ and their respective values $v_n$, $v_p$, and $v_q$, which are combined to the attack feasibility attribute $a_k$ as presented previously. The countermeasure is represented as node $d_1$ which has the same attributes as node $n_1$, namely $a_1$, $a_2$, and $a_{k-1}$, but with potentially different values $u_r$, $u_s$, and $u_t$. These values represent how a countermeasure influences the attack node $n_1$.

To model the influence of countermeasure nodes, we use special aggregation functions f to calculate new values for the attributes of $n_1$ taking into account attributes of $d_1$. This function can be different for every attribute and depends on the calculations used by the analyst. However, they should be consistent within a domain/standard. The new value $v_{n_{new}}$ of $a_1$ for node $n_1$ is calculated as $v_{n_{new}} = f(v_n, u_r)$. This is done for all attributes $a_2, ~\dots , ~a_{k-1}$ respectively. Finally, the feasibility $v_m$ of node $n_1$ is adjusted based on the newly computed attributes.

In the example of Fig. 2, the chosen function f that represents the influence of the countermeasure node on the attack node is the Sum-function presented in Section 4.1. When using a sum function the values of the countermeasure nodes are added to their parent nodes, which complicates the attack and, therefore, reduces the attack feasibility of the predecessor nodes. Consider the countermeasure node “Physical Access Restriction” and the inner node “Break in to Comp. Center” on the lower left of Fig. 2. The node “Physical Access Restriction” is rated to increase the value of Resources and Knowledge by one as the aggregation function chosen here is the sum function. Hence, the values for Resources and Knowledge of “Break in to Comp. Center” are both increased by one to their new value of two. The originally rated value for “Break in to Comp. Center” is still visible in blue but crossed out in Fig. 2 to illustrate the effect of countermeasure nodes.

A small example showcasing the effect of a countermeasure on an attack step is shown in Fig. 5. The attack feasibility values are again shown in the upper right corner using a traffic light color scheme. On the left there is an attack node with attributes resources, knowledge, and location and its attack feasibility. On the right the countermeasure node is attached to the attack node. The attack node on the right displays the new and old values for its attributes and its new attack feasibility value. Attributes and functions are chosen and defined as described in Section 5.1. The green node represents a basic action / leaf node, the blue node represents a countermeasure node. The attack feasibility values are highlighted using a traffic light color scheme for simpler interpretation.

Fig. 5

Example of countermeasure influence on an’ attack step

Table 2 For exemplatory usage, we defined Resources and Knowledge with values from 1 (basic) to 5 (extraordinary)

Second, a countermeasure can influence an attack’s impact on a specific consequence. This case is more complicated to illustrate as it is influencing an edge (between a Consequence Node and a topmost Inner Node) instead of a node. However, the principle is the same as for nodes. An example is shown in Fig. 6. The attributes and values are again described in Section 5.1 and depend on the specific domain/standard. In Fig. 6 the resulting risk for a consequence is shown in the upper right corner of the consequence node. The risk scale is also explained in Section 5.1, in the example the values M for “Medium” and L for “Low” are used. The values for risk and attack feasibility are again highlighted using a traffic light color scheme. On the left there is a an attack node with its attributes and values and a consequence node on the top displaying the risk value. The edge between those two nodes is annotated with the impact of the attack regarding the consequence, which for this example has the value 3. On the right side there is a countermeasure that reduces the impact of the attack regarding the consequence. Typical examples for such countermeasures are insurances for financial consequences or business continuity management solutions for cases when services are no longer available. As shown in Fig. 6 we use a small rectangle to incorporate the correct calculations. The old impact value is still displayed but crossed out and the consequence node displays the new risk value.

Fig. 6

On the left there is an attack node with attributes resources, knowledge, and location and its attack feasibility. On the right the countermeasure node is attached to the attack node. The attack node on the right displays the new and old values for its attributes and its new attack feasibility value. Attributes and functions are chosen and defined as described in Section 5.1. The blue node represents a countermeasure node, the attack feasibility and risk values are highlighted using a traffic light color scheme for simpler interpretation

5.1 Application of risk assessment graphs

We now show an example of how to adapt Attack Graphs to facilitate cybersecurity risk assessment. When the described definitions are used to create a graphical representation or risk landscape, we refer to these graphs as Risk Assessment Graphs.

All attributes and aggregation functions used in this example are based on the international standard IEC 62443 [1] dealing with security in industrial applications and the German prestandard DIN VDE V 0831-104 for the application of IEC 62443 to railway signalling systems [34]. The standard uses the attributes Resources, Knowledge, and Location to evaluate attack steps, which are then combined into an attribute called Attack Feasibility. We use those same attributes, however, for this example we alter the value ranges for some attributes.

According to DIN VDE V 0831-104, the Attack Feasibility (AF) of the Inner Nodes shown in Fig. 2 is computed based on the attacker’s capabilities and mitigation factors. First, the attacker’s capabilities are described by two attributes: (1) Resources (R), reflecting the financial and workforce capacity of the attacker to prepare and launch an attack, and (2) Knowledge (K), reflecting the information that the attacker holds about the system they intend to attack. We define the scale for these attributes in a range of 1 (basic) to 5 (extraordinary), see Table 2. Second, the mitigation factors relate to the risk of the attacker being discovered, and they are described by the Location (L) attribute, which reflects whether an attack can be launched remotely ($L = 0$) or locally ($L = 1$), which is shown in Table 3.

Table 3 Defined value ranges for Location

Every lowermost Inner Node (green node) is assigned the Resources (hammer) and Knowledge (light bulb) attributes, whose value ranges from 1 to 5, and a Location (pin) attribute, whose value is either 0 or 1. First, the Resources and Knowledge of the attacker are related in a matrix, such as the one shown in Table 4, to initially determine a Preliminary Attack Feasibility (PAF), which indicates the ease of launching an attack without taking into consideration the risk of being discovered. The computation of the values is based on an example given in the appendix of [34].

For example, Fig. 2 shows that the “Break in to Comp. Center” attack (i.e., bottom left Leaf Node) requires Low Resources ($R = 2$) and Low Knowledge ($K = 2$) to be launched. In this case, Table 4 shows that $R = 2$ and $K = 2$ results in $PAF = 4$. Second, the Location of the attacker is subtracted from the Preliminary Attack Feasibility to determine the Attack Feasibility eventually. Here, Fig. 2 shows that the “Break in to Comp. Center” attack requires Local Access ($L = 1$) to be launched. In this case, the Attack Feasibility is equal to 3 ($AF = PAF - L = 4 - 1 = 3$).

Table 4 Preliminary Attack Feasibility matrix

Table 5 Definition of Impact values

When the Attack Feasibility of all lowermost Inner Nodes is determined, the Resources, Knowledge, and Location attributes of all predecessor Inner Nodes are obtained from their successor Inner Nodes, in this case, either conjunctively (AND) or disjunctively (OR). Other graphs can include different logical connectors as well. Similar to Weiss’s attack tree [6], only conjunctive refinements are shown explicitly. That is, all refinements shown in the Risk Assessment Graph are disjunctive unless two Inner Nodes are connected through an AND gate, in which case the refinement is conjunctive. Regarding conjunctive refinements, an Inner Node obtains, in this case, the sum of values for each Resource, Knowledge, and Location attribute exhibited among its successor nodes. The Attack Feasibility is determined based on the resulting values. For example, the attack Guess Password can only succeed if an attacker obtains the password file and encounters a guessable password. Hence, the nodes Obtain Password File ($R=1, K=3, L=0$) and Encounter Guessable Password ($R=1, K=2, L=0$) are conjunctively joined and their predecessor node Guess Password obtains the sum of their values ($R=2, K=5, L=0$). This particular sum function has an upper limit, meaning that if the addition of the successor values would result in a higher value than defined in the range of this attribute, then the maximum value for this attribute will be chosen for the predecessor node. For example, if the sum of the values for Ressources would exceed the value 5, the predecessor node will obtain 5 as the value for Ressources. This is based on our definition of the value range (see Table 2) as the value $R=5$ is defined as such that more than €1 billion are needed to develop and execute the attack. Regarding disjunctive refinements, an Inner Node obtains its successor node’s Resources, Knowledge, and Location attributes with the highest Attack Feasibility. If the highest Attack Feasibility is exhibited by multiple successor nodes, we defined an order on the attributes, deeming Resources more critical than knowledge. If the lowest Resource value of the successor nodes exhibiting the highest Attack Feasibility is exhibited by multiple successor nodes, the values for Knowledge are compared. If multiple of these nodes exhibit the same lowest value for Knowledge, any node can be chosen as they must have the same rating. Because, if the values for Attack Feasibility, Resources, and Knowledge are identical, then the values of Location have to be identical as well or it would not result in the same Attack Feasibility. E.g., in the case of Look over Sys. Admin. Shoulder and Corrupt Sys. Admin, both have an Attack Feasibility of 4, so to decide which one is more critical, the algorithm checks the Resource Attribute. The Resource Attribute for those nodes is different and as Look Over Sys. Admin. Shoulder requires only Basic Resources the predecessor node Obtain Admin Password obtains its values.

In addition, the edges relating Consequence Nodes to the topmost Inner Node are assigned with an Impact attribute, which indicates the magnitude of damage or physical harm caused by negative consequences on the system. The impact of negative consequences is typically rated using numerical ranges and qualitative scales, as shown in Table 5. However, the impact rating terminology remains rather inconsistent across risk assessment standards. Here, if the “Obtain Admin. Privileges” attack is eventually achieved, the impact of “Data Leakage” is 3 (moderate), and the impact of “Denial of Rightful Access to the System” is 2 (minor).

Table 6 Risk matrix

Finally, the Impact and Attack Feasibility attributes are related in a matrix, such as the one shown in Table 6, to determine a Risk attribute, shown as colored squares on the top right of Consequence Nodes, indicating whether the current risk level is acceptable or not. Here, the Risk Assessment Graph shows a risk of significant (S) “Data Leakage” and a moderate (M) risk of “Denial of Rightful Access to the System”.

5.2 Summary

In this section, we defined the components required to perform risk assessment using Attack Graphs: (1) consequence nodes, (2) attack feasibility attributes, and (3) countermeasure nodes. These attributes contribute to extending the threat landscape to a risk landscape. Apart from the formal definitions, we further showed a practical example of utilizing Attack Graphs. The example is grounded on the risk assessment process described in the DIN VDE V 0831-104. The described risk assessment process was also used in the project “Forecast of security requirements and evaluation of possible security concepts for the railway system” provided by the German Center for Rail Traffic Research (DZSF) at the Federal Railway Authority (EBA). A detailed report about the risk assessment process is presented in [35]. The results of the risk assessment including the required security countermeasures are reported in [36, 37].

6 Applicability of risk assessment graphs to risk management standards

The goal in developing the model described in Section 4.1 is to generate a flexible approach that can accommodate existing well-established methods for risk analysis. In this section the model of Risk Assessment Graphs is tailored to ISO/SAE 21434  [4] and CLC/TS 50701  [5], which specify engineering requirements for cybersecurity risk management in the automotive and railway domains, respectively. During this process, standardized attributes, as well as aggregation algorithms, need to be defined. Which yields consistent and reliable analysis, even if performed by different analysts. In the following, we show that our framework is able to accommodate different risk management frameworks.

Table 7 Example aggregation of attack potential

6.1 Risk assessment according to ISO/SAE 21434

The ISO/SAE 21434  [4], a widely used standard in the automotive domain, defines (1) an item as a component or set of components that implement a function at the vehicle level and (2) an asset as an object that has value or contributes to value. Assets have properties whose compromise may realize damage scenarios, which refer to the negative consequences imposed on items. In this regard, the first step in the risk assessment process, according to ISO/SAE 21434 is the asset identification, where the assets of an item are specified, and the possible damage scenarios are evaluated. The second step is the threat scenario identification, where the potential causes (i.e., threats) of compromise of the assets’ properties are analyzed. Here, a threat scenario can lead to multiple damage scenarios, and a damage scenario can correspond to various threat scenarios. The third step is the impact rating, where the magnitude of damage or physical harm (i.e., impact) of a damage scenario is estimated. The damage scenarios are assessed against potential negative consequences, and the impact rating of the damage scenarios is determined to be (1) negligible, (2) moderate, (3) major, or (4) severe. The fourth step is the attack path analysis, where threat scenarios are analyzed for identifying attack paths. Here, attack paths are linked to the threat scenarios that can be realized by these attack paths. The fifth step is the attack feasibility rating, where the ease of attack path exploitation is rated as (1) very low, (2) low, (3) medium, or (4) high. According to the standard, the attack feasibility rating should be based on either (a) an attack potential-based approach, (b) a CVSS-based approach, or (c) an attack vector-based approach. If the rating is based on the attack potential, the attack feasibility should be determined based on core factors including elapsed time, specialist expertise, knowledge of the item or component, window of opportunity, and equipment. For each attribute, numerical values can be defined. The informative parts of the standard propose an example based on the ISO/IEC 18045 [38], see Table 7. The attack potential is then calculated by adding all parameters, and the result is then mapped according to Table 8.

The sixth step is the risk determination, where the risk of threat scenarios is determined from the impact of the associated damage scenarios and the attack feasibility of the associated attack paths. The risk value ranges from 1 (lowest risk) to 5 (highest risk). Here, risk matrices, such as the one shown in Table 9, also proposed by the informative parts of the standard, can also be used for risk determination. In addition, if a threat scenario is linked to multiple attack paths, the attack feasibility of these attack paths is aggregated (i.e., the threat scenario is assigned the maximum attack feasibility level of the attack paths). The final step in the risk assessment process, according to ISO/SAE 21434, is the risk treatment decision, where treatment decisions for the identified risks are taken mainly based on the impact and attack feasibility ratings. Here, the risk treatment options are (1) risk avoidance, by removing risk sources, (2) risk reduction, by, e.g., inserting countermeasures, (3) risk sharing or transference, through, e.g., contracts or insurances, or (4) risk acceptance, in case of low impact and attack feasibility [4].

Table 8 Attack Feasibility mapping according to ISO/SAE 21434

Table 9 Risk matrix from ISO/SAE 21434  [4]

6.2 Applicability of risk assessment graphs to ISO/SAE 21434

Fig. 7

Risk graph evaluation of scenario designed by Weiss [6] using the risk assessment process described in ISO/SAE 21434  [4]. The color coding of the nodes identifies Leaf Nodes (green) and countermeasures (blue). The color coding of the node attributes in the upper right corner underlines the severity of a result even without knowing the value range for this attribute (neon green: negligible, light green: low, yellow: medium/moderate, light red: severe, dark red: critical / very high)

Fig. 7 shows an example of a Risk Assessment Graph using ISO/SAE 21434. The risk assessment process is carried out as follows. First (asset identification) the item is a UNIX system, and the asset is the administrator privileges. Second (threat scenario identification), the threat that may compromise the administrator privileges is represented by the topmost Inner Node (i.e., “Obtain Admin. Privileges”), which leads to two damage scenarios (i.e., negative consequences) represented by Consequence Nodes (i.e., “Data Leakage” and “Denial of Rightful Access to the System”). Third (impact rating), the edges relating Consequence Nodes to the topmost Inner Node are assigned with an Impact attribute. Here, if the “Obtain Admin. Privileges” threat is eventually realized, the impact of “Data Leakage” is major, and the impact of “Denial of Rightful Access to the System” is moderate. Fourth (attack path analysis), attack paths are identified through the refinements of Inner Nodes. That is, the topmost Inner Node (i.e., “Obtain Admin. Privileges”) represents the high-level threat (i.e., the main goal of the attack), which is refined into low-level threats (i.e., sub-goals of the attack), represented by successor Inner Nodes until the lowermost Inner Nodes (green nodes) ultimately represent the least significant threats (i.e., elementary attacks). Hence, all Inner Nodes of the same attack path need to be fulfilled for the “Obtain Admin. Privileges” threat to be realized (i.e., the main goal of the attack to be achieved). Fifth (attack feasibility rating), every lowermost Inner Node (green nodes) is assigned with Elapsed Time (hourglass), Specialist Expertise (star), Knowledge of the Item (or Component) (light bulb), Window of Opportunity (calendar), and Equipment (hammer) attributes, whose value ranges are described in Table 7. Then, the Attack Feasibility of every lowermost Inner Node threat is assigned using Table 8, and predecessor Inner Nodes obtain the attributes from their successor Inner Nodes either conjunctively or disjunctively, as described in Section 5.1.

For inner nodes, no specific values are shown as for the risk calculation, only the attack feasibility is necessary, and if multiple successor nodes have the same attack feasibility, the most critical path is the one which has the lowest sum of attribute values. Furthermore, the conjunctive calculation is an addition of the values of the successor nodes, resulting in a value of 22 which, according to Table 8, results in Low for the attack feasibility. Sixth (risk determination), the Impact attribute and the Attack Feasibility of the topmost Inner Node are used to determine the risk of Consequence Nodes. Here, using the risk matrix shown in Table 9, the Risk Assessment Graph shows a risk of 4 for “Data Leakage” and a risk of 3 for “Denial of Rightful Access to the System”. Finally (risk treatment decision), the options to avoid, reduce, or share/transfer the identified risks are represented by Countermeasure Nodes. Conversely, if the Impact attribute and the Attack Feasibility of the topmost Inner Node are low, and therefore, the identified risks are accepted, Countermeasure Nodes do not need to be added to the Risk Assessment Graph.

6.3 Risk assessment according to CLC/TS 50701

Similar to ISO/SAE 21434, CLC/TS 50701 is also describing an asset-based risk assessment. In this regard, the first step in the risk assessment process according to CLC/TS 50701 is the system definition, where the purpose, scope, operational environment, and applicable security standards of the system under consideration (SUC) are specified. In addition, the valuable objects (i.e., assets) supporting the essential functions of the SuC are identified. Assets are classified into information technology (IT) assets, whose compromise may lead to business consequences (e.g., loss of revenue), and operational technology (OT) assets, whose compromise may lead to physical consequences (e.g., sustained service outages). The second step is the threat landscape, where a list of potential negative actions or events (i.e., threats) capable of jeopardizing the assets of the SUC is established and maintained.

Fig. 8

Risk graph evaluation of scenario designed by Weiss [6] using the risk assessment process described in CLC/TS 50701  [5]. The color coding of the nodes identifies Leaf Nodes (green) and countermeasures (blue). The color coding of the node attributes in the upper right corner underlines the severity of a result even without knowing the value range for this attribute (neon green: negligible, light green: low, yellow: medium/moderate, light red: severe, dark red: critical / very high)

Table 10 Risk matrix from CLC/TS 50701  [5]

Here, threats are classified into internal (i.e., arising from within the system) and external (i.e., arising from outside the system). The skills and motivations driving the threats to exploit the vulnerabilities of the SUC and affect the assets of the SUC are documented, as well. Third, the impact assessment, where the negative consequences, in terms of confidentiality, integrity, and availability (CIA), imposed on assets are evaluated. The impact on CIA is assessed qualitatively and ranges from A (highest impact) to D (lowest impact). The fourth step is the likelihood assessment, where the attack surface (i.e., exposure) and the level of expertise and/or resources required to exploit the vulnerabilities of the SUC are evaluated. The value of both exposure and vulnerability ranges from 1 (highly restricted logical or physical access for the attacker, vulnerability can only be exploited with high effort) to 3 (easy logical or physical access for the attacker, vulnerability can be exploited with low effort). In addition, the likelihood function is given by $L = EXP + VUL - 1$. Consequently likelihood of attacks ranges from 1 (highly unlikely) to 5 (highly likely). The final step in the risk assessment process, according to CLC/TS 50701, is the risk evaluation, where the risk of the documented threats being realized is determined usually by translating the threat landscape into a risk matrix, in which the assessed impact and likelihood of documented threats are related. Table 10 shows an example of such a risk matrix.

6.4 Applicability of risk assessment graphs to CLC/TS 50701

The applicability is demonstrated through the example of a Risk Assessment Graph using CLC/TS 50701, shown in Fig. 8. The risk assessment process is carried out as follows. First (system definition), in this case, the SUC is a UNIX system. Second (threat landscape), the threats (that may jeopardize the assets of the UNIX system) are represented by Inner Nodes. Similar to ISO/SAE 21434, the topmost Inner Node represents the most significant threat, successor Inner Nodes represent less significant threats, and the lowermost Inner Nodes (green nodes) ultimately represent the least significant threats. Hence, the topmost Inner Node is fulfilled when all Inner Nodes of the same attack path are fulfilled. Third (impact assessment), the negative consequences are represented by Consequence Nodes (i.e., “Data Leakage” and “Denial of Rightful Access to the System”). In addition, the edges relating Consequence Nodes to the topmost Inner Node are assigned with an Impact attribute, whose value ranges from A to D. Here, if the “Obtain Admin. Privileges” threat is eventually realized, the impact of “Data Leakage” is A, and the impact of “Denial of Rightful Access to the System” is C. Fourth (likelihood assessment), every lowermost Inner Node is assigned the Exposure (lock) and Vulnerability (shield) attributes, whose values range from 1 to 3, and the likelihood (red bubble) of every lowermost Inner Node threat is computed using the function $L = EXP + VUL - 1$. Then, predecessor Inner Nodes obtain the Exposure and Vulnerability attributes from their successor Inner Nodes either conjunctively or disjunctively, as described in Section 5.1. Finally (risk evaluation), the Impact attribute and the likelihood of the topmost Inner Node are used to determine the risk of Consequence Nodes. Here, using the risk matrix shown in Table 10, the Risk Assessment Graph shows a high (H) risk of “Data Leakage” and a significant (S) risk of “Denial of Rightful Access to the System”.

Fig. 9

The 62 areas of application of the future railway system

7 Case study: the future railway network

To evaluate our presented method, we explored the evolving landscape of the railway system and assessed their corresponding cybersecurity challenges. The study¹⁰ aimed at providing a forward-looking perspective on how future railway technologies could introduce novel threats, necessitating robust security measures and research efforts. The research involved a two-fold approach: First, we identified technological trends and future use cases for railway systems. Second, we conducted a security analysis for these identified scenarios. We analyzed the railway system in its entirety by examining the different areas: (1) Operation, Traffic Management, Maintenance, (2) Infrastructure, (3) Train Protection / Signalling, (4) Rolling Stock, (5) Passengers, and (6) Freight. We further devided each area into the three categories: (1) Planing), (2) Building, and (3) Operating. That lead to 62 areas of application that are depicted in Fig. 9.

Then, we constructed 21 use cases to cover all of these 62 areas of application. These use cases are: (1) Automated Hump Control, (2) Automated Planning and Plan Review, (3) Cloud Interlocking, (4) Contactless Ticket Control, (5) Decentralized Interlocking, (6) Emotion and Intent Recognition, (7) ETCS Train Protection, (8) Freight Route Management, (9) Fully Automated Driving, (10) Identification of Persons, (11) Intermodal Freight Handling, (12) Intermodal Travel Chain, (13) On-site Information, (14) Optimized Travel and Price Arrangements, (15) Optimization of Passenger Changeover Time, (16) Passenger guidance through the Train Station, (17) Predictive Maintenance, (18) Remote Controlled Rolling Stock, (19) Steering Action for Scheduling, (20) Travel and Life Management, and (21) Virtual Coupling.

All these use cases are described in detail in [39]. For all 21 use cases, we then used the above defined methodology for attack graphs to identify threats and consequences. We implemented a draw.io plugin to realize the method and evaluate its practical use.

One investigated use case is train protection using the European Train Control System (ECTS). ETCS is the signaling and control system of the European Rail Traffic Management System (ERTMS) and should replace the incompatible railway systems across and outside Europe. ETCS is comprised of different levels from 0 to 3, whereas in Level 0, ETCS-compliant rolling stock is not interacting with lineside equipment, and Level 3 is the most advanced system that is not relying on trackside equipment for train location and train integrity [40]. From today’s perspective, the implementation of the already standardized ETCS Level 3, Hybrid Level 3, and Level 2 without signals will significantly shape future railway operations, thereby leading to the abandonment of conventional track vacancy detection systems. Positioning and train integrity verification will be performed onboard and continuously. This information will then be transmitted to the interlocking system via the RBC (Radio Block Center). The train spacing will shift from the fixed block system to the moving block system. Movement authorities (indicating whether a train is allowed to pass) will be transmitted from the interlocking system/RBC to the vehicles.

Our threat analysis identified a range of vulnerabilities, presenting significant risks to the security and integrity of future railway systems. One critical concern is unauthorized access with intrusions into key systems that could potentially lead to data breaches or manipulation. This risk is closely tied to data integrity, where the alteration of data could result in incorrect system behavior or compromised decision-making. Attacks on the digital capture of the real environment pose a significant threat to the safety of the system, including passengers, staff and all mechanical systems. Additionally, Denial-of-Service (DoS) attacks are recognized as a major threat, capable of overwhelming system resources and disrupting operations on a large scale. With the increasing use of wireless communication systems, jamming attacks as a sub-category of DoS attacks will become more frequent. Malware infections are also a serious vulnerability, as they could undermine system integrity by enabling unauthorized control or data theft. Our analysis further revealed the risks of physical attacks, which, through tampering with hardware or infrastructure, could directly compromise the safety and reliability of railway operations. Moreover, the manipulation of safe localization systems, which is critical for accurate positioning of trains, poses a direct threat to operational safety. Attacks targeting machine learning systems, which support automation and predictive maintenance, could severely impact their functionality and decision-making capabilities, potentially leading to safety issues. Similarly, the manipulation of machine-to-machine communication networks could undermine the reliability of data exchanges between interconnected systems. Finally, the emergence of quantum computing presents an unprecedented challenge, as its ability to break current cryptographic methods could render existing security protocols obsolete. Collectively, these findings underscore the need for advanced technological defenses, comprehensive security policies, and continuous monitoring to safeguard the resilience and security of future railway infrastructures [37].

We discovered that these threats impact 14 consequences that we categorized into four groups: (1) Financial Damage, (2) Reputational Damage, (3) Laws and Regulations, and (4) Miscellaneous. All consequences are shown in Fig. 10.

Violation of physical integrity ranges from people, including passengers and staff, are getting hurt to multiple deaths. Privacy is mostly violated against passengers as their data is being processed. However, the privacy can be violated by an operator or outside parties depending on the use-case. The railway system is a critical infrastructure and if its functionality is disrupted on a large scale through a threat, we speak of the disruption of a critical service. Obstruction of punishments involves attacks that help a person being undiscovered while commiting a crime, like manipulating cameras so that the crime is not filmed. Attacks that lead to mass panic, for example, are covered through the inciting chaos consequence. The other consequences are self-explanatory [37].

Fig. 10

Consequences due to threats on the railway system

Fig. 11

Risk graph evaluation of ETCS Train Protection. The color coding of the nodes identifies Leaf Nodes (green) and countermeasures (blue). The color coding of the node attributes in the upper right corner underlines the severity of a result even without knowing the value range for this attribute (neon green: negligible, light green: low, yellow: medium/moderate, light red: severe, dark red: critical / very high). Nodes in yellow describe an attack vector that is described in more detail in another document and are handled here like Leaf Nodes / basic actions

Returning to the example use case of ETCS Train Protection, we analyzed the use case regarding threats resulting in the attack graph shown in Fig. 11. For this use case, we identified four possible consequences: (1) Reputational damage to the operator, (2) financial damage to the operator, (3) the disruption of a critical service, and (4) the violation of physical integrity. Our definition of the consequence node “Violation of Physical Integrity” is that harm is done to passengers or personnel. Hence, if an accident or crash happens due to a cyber attack, the consequences can be very critical and multiple persons can be severly harmed or killed, resulting in the very high impact values of 5 for this consequence.

Starting on the left top of Fig. 11, one possible attack goal would be stopping trains on the open route, leading to reputational and financial damage to the operator as well as a disruption of a critical service. This can be achieved by either inserting the emergency stop by spoofing the data radio transmission (GSM-R or FRMCS) or by jamming the transmission. The other three attack vectors can all lead to a financial damage to the operator, the disruption of a critical service, and the violation of physical integrity. The second attack vector is to forge a Movement Authority by spoofing the data radio again and forging the authenticity of a data telegram. Furthermore, ETCS also employs train integrity systems, which could be manipulated by jamming the digital train rear disc or by compromising the Fibre Optic Sensing (FOS) unit. The final identified attack goal is to manipulate the safe localization of trains. In ETCS Level 2 without signals, we could manipulate the existing train detection systems. In other cases, the attack is more complex and consists of multiple steps in order to manipulate all systems that are in place. Therefore, it is necessary to (1) compromise the FOS unit, (2) forge the balise telegram, (3) spoof the global navigation satellite system, and (4) manipulate the odometry.

In this case, all the attack vectors would lead to a financial damage to the operator as well as the disruption of a critical service. However, the impact varies depending on the attack and the consequence. Reputational damage is only connected to stopping trains as passengers immediately notice it, and the operator is likely to be directly blamed for the stop. Other attacks might also have consequences regarding the operator’s reputation, but we omitted these connections because, in our opinion, the other consequences are more important and as it is not as certain that a reputational damage will arise.

Several defense mechanisms were identified to mitigate the risks arising from these attacks. Digital signatures and security monitoring can be used to mitigate spoofing attacks and manipulations of the train detection system. Jamming attacks can only be mitigated by increasing the resilience of the used systems. The authenticity of data telegrams is usually ensured by using cryptographic algorithms and as the threat might arise from the use of a specific algorithm or the use of an old version, it is necessary to ensure the updateability of algorithms promptly. Further, it might help to implement a secure storage for critical or cryptographic contents, like keys or seeds, that are used to ensure authenticity.

Generally, after using the AttackGraphs to identify threats and risks, we utilized countermeasure nodes to identify technologies and methods to mitigate the risks. As the railway system is very complex and several sub-systems are interconnected, we tried to find countermeasures that can cover large basis of threats. Furthermore, even if the countermeasure is formally the same, the implementation might be different depending on the use case. For example, we identified threats to the digital capture of the environment and as the capturing of the environment can differ from use case to use case, so does the implementation of the countermeasure to secure its integrity. This resulted in a list of 49 desired countermeasures to reduce the risk to a minimal and acceptable level for all 21 use cases. Further details on countermeasures can be found in [37].

During this process, 21 Risk Assessment Graphs with more than 900 nodes in total (including the Countermeasure Nodes) were created, with the largest graph containing more than 70 nodes. It is worth mentioning that if paths were the exact same for different use cases, the attack path was at least once completely evaluated and depicted, whereas it was shortened in other use cases and referred to the graph with the completely expanded path. Furthermore, countermeasures could be used for different attack paths, which resulted in two options for depicting them. The countermeasure node could have multiple relations to attack paths, or the countermeasure node appears multiple times in the same graph. This is dependent on the specific graph and was decided regarding readability issues. Additionally, some countermeasure nodes do not contain only one countermeasure, as only the combination of countermeasures would be sufficient to ensure security and the attack can not be mitigated with a stand-alone measure.

For clarity and readability, node labels in the graphs should remain short and comprehensive. Additional explanations can be stored in optional hidden attributes, ensuring that detailed context is available without cluttering the visualization. This improves both usability and consistency while reducing the need for external documentation.

We measured the effort required to construct and analyze the Risk Assessment Graphs in our case study. The creation of each graph required approximately 30–60 minutes, and the assignment of node attributes and consequence impact values took an additional 30–60 minutes. The modeling process became increasingly efficient over time, as recurring nodes and patterns allowed values to be reused or transferred across graphs. To reduce errors and ensure consistency, we employed a two-team approach: one team generated the graphs, while a separate team performed verification. Attribute and impact assignments were likewise carried out by one team and independently verified by another, with verification taking about 15 minutes per graph. To support consistency, we implemented a script that extracted all basic nodes and their values, enabling us to verify that naming conventions and value assignments remained correct across graphs. Consistency checks across multiple graphs currently require external XML scripts, as the tool does not support them directly. Graph construction, attribute assignment, and verification are manual, but all subsequent calculations, including feasibility and risk aggregation, are fully automated.

8 Evaluation

Based on prior work and requirements from OT standards, we define seven characteristics that are necessary for a graphical risk assessment process: (1) Attack vectors to represent the threat landscape; (2) Directed acyclic graph structure due to interdependencies; (3) Node attributes to evaluate the danger that originates from threats; (4) Dynamic connectors due to the complexity and dependencies of attacks/attack steps; (5) Edge attributes for attributes dependent on node connections, like the impact; (6) Countermeasure nodes to represent the existing system and to plan against attacks; and (7) Consequence nodes represent what a successful attack impacts. Section 3 discusses that none of the graphical security modeling frameworks from current literature provides all seven characteristics for graphical risk assessment. In Table 11, we compare foundational and prominent representatives regarding these characteristics. Further we compare them regarding their complexity and automation capabilities. Complexity refers to the level of expertise, mathematical formalism, and modeling effort required to construct and apply the method, ranging from low (intuitive, accessible to non-experts) to very high (requiring advanced probabilistic or formal methods). Automation capabilities describe the extent to which models can be generated or parameterized automatically: manual (fully hand-crafted), semi-automatic (partially supported through libraries, vulnerability databases, or tools, but requiring expert input), and full automation possible (end-to-end construction and parameterization feasible given a sufficiently detailed system description).

Attack Trees [6] build a basis for graph-based cybersecurity assessments. They originally were created to display attack vectors only, but they can easily be extended to include node attributes for more evaluation. Attack Trees are generally considered low complexity, as they use a simple hierarchical decomposition that is easy to understand for non-experts. Their construction is often manual, but many tools now allow semi-automatic or even fully automatic generation of trees from system descriptions and vulnerability databases, e.g., CVEs.

While OWA trees [41] stand out as they at least partially provide dynamic connectors and edge attributes. OWA trees and cryptographic DAGs [8] are the only models not providing node attributes. OWA Trees add Ordered Weighted Averaging operators for likelihood or impact aggregation, increasing their complexity to a moderate level because they require mathematical formulation and expert input to define weights. While the aggregation itself can be automated, weight assignment keeps them in the semi-automatic category. Cryptographic DAGs are high complexity models designed for formal cryptographic protocol analysis. They demand strong expertise and are not general-purpose. Limited semi-automation is possible if protocols are available in formal specification, but otherwise modeling is manual.

For the last couple of decades, researchers have also been focusing on Bayesian networks for the purposes of security modeling. Bayesian attack graphs were first introduced by Liu and Man [9] in 2005 to analyze network vulnerability scenariosare, and are a fusion of (general) attack trees and (computational procedures) of Bayesian networks. Subsequently, calculating general security metrics regarding information system networks [45, 46] and capturing dynamic behavior [47] was also made possible. Although Bayesian attack graphs allow for assigning values to nodes and for performing computations using the graphs, they do not allow for a dynamic selection of connectors and for including countermeasures. Bayesian Networks are high complexity probabilistic models as their expressiveness comes at the cost of defining conditional probability tables, which grows combinatorially with the number of parent nodes. Automation is possible if large datasets exist (structure or parameter learning), but in OT domains such data is rarely available, making them mostly semi-automatic. Bayesian Attack Graphs are of very high complexity, as they combine attack graph structure with Bayesian inference. They can be generated partly from configuration or vulnerability data, but probability values usually require manual calibration, so they remain semi-automatic.

Table 11 Risk Assessment Graphs provide all seven identified characteristics, whereas existing graphical security modeling frameworks from current literature provide at most five characteristics. A $\checkmark$ indicates that the characteristic is supported, ($\checkmark$) that it is partially supported or only in an extended version, and otherwise that it is not supported.

Besides AND-OR gates, which follow a strictly Boolean logic, Security Activity Graphs (SAGs) [43] also include split gates, which allow one activity to be used in several parent activities. However, SAGs lack the ability to represent the consequences of threats and edge attributes, which are both necessary to calculate a risk value. While including computation rules to simplify countermeasure selection through cumulative voting, Countermeasure Graphs [44] do not include cybersecurity risk based calculation methods. This limitation could at least partially be addressed by adjusting the threat level introduced in the methodology. However, the threat level value is determined by the subjective assessment of the graph creator rather than by calculations over meaningful attributes, thereby raising validity issues. Security Activity Graphs and Countermeasure Graphs fall into the moderate to high complexity range, since they model not only attacks but also defensive activities and countermeasure effects. Some semi-automation is possible using vulnerability or countermeasure libraries, but relations and impacts must be manually specified.

BDMPs are a security modeling framework, which can also be used to perform risk assessment [14] by offering a wide range of node attributes, including time-domain metrics, such as mean-time to success, attack tree-related metrics, such as costs of attacks, Boolean indicators, such as specific requirements, and risk assessment tools, such as sensibility graphs. However, the lack of edge attributes, in addition to usability issues with respect to leaf nodes and connectors [48], render BDMPs impractical for risk assessment as we intend to use it. BDMPs are very high complexity models that combine Boolean attack logic with Markov processes for dynamic behavior. Tool support, e.g., KB3 provides some assistance, but the need for detailed timing and probability data means they are still only semi-automatically constructible in practice.

The most relevant framework regarding our research question is the Boolean Logic Driven Markov Processes. However, even this one falls short when it comes to attributes, especially edge attributes, and it is not possible to represent consequences either. Hence, we defined Risk Assessment Graphs to provide all seven characteristics. Their complexity can be compared to those of OWA Trees or Countermeasure Graphs and is ranked moderate. The attack graphs can be created using vulnerability databases, like CVEs, and the value assessment can be automated using scoring systems, like CVSS. Later requires further research how well these values can be used or transformed for OT systems and regulations.

Furthermore, as presented in Section 7, we evaluated the Risk Assessment Graph framework in the project “Forecast of security requirements and evaluation of possible security concepts for the railway system” provided by the German Center for Rail Traffic Research (DZSF) at the Federal Railway Authority (EBA). The project aimed to identify research and standardization demands for security measures of future railway systems. In order to achieve this goal, 21 use cases were created, describing how future technologies can be utilized as well as their connections, data flows, and benefits. These use cases built the basis for a further security analysis, which was done using Attack Graphs. First, an Attack Graph for each use case was created to identify the threats and vulnerabilities. Then, a risk assessment was performed using the process described in Section 5.1. Next, security measures to mitigate the threats and vulnerabilities were researched and attached to the Risk Assessment Graphs until the risk was reduced to an acceptable level. The security measures were then further investigated to determine the technological level and applicability to the specific railway system as well as their coverage by standards. We identified whether the standards applicable to the use cases already demand the necessary countermeasures.

As shown with the exemplary use case of Section 7, Risk Assessment Graphs also scale for multiple use cases and graphs with a reasonable size for realistic applications. The Risk Assessment Graphs were created using a plugin tool for diagrams.net that is publicly available on GitHub¹¹. This tool aims to provide a user-friendly development and visualization of attack graphs. It supports the annotation of nodes and connectors with attributes and performs the calculation of the functions as presented in Section 4. Risk analysts estimate the attribute values of Leaf Nodes and Countermeasure Nodes while the tool aggregates the values towards the Consequence Nodes to present the resulting risk according to the chosen standard (see examples in Section 6). Hence, the tool provides the possibility to dynamically update and adapt the attributes and adding and deleting nodes, whereby the tool automatically recalucates the risk values. Leading to a better representation of the evolving security landscape. Reacting to changing threat landscapes and analyzing the influence of an individual estimation on the resulting risk can be done with the tool because it re-calculates after any value is changed. During the creation of the graphs, at least two separate expert teams ensure quality assurance. The first team created an attack graph, and the second team validated it. This process was applied to the creation of attack graphs, to the risk ratings, and to the defense mechanisms. The Attack Graphs are publicly available¹². The graphs, use cases, and results from this project are presented in detail in [35,36,37].

Regarding usability, we found the Attack Graphs to be much more transparent than alternatives like tables. Especially using the tool helps as it is also implemented to highlight parent nodes and the attack path with the highest risk. This makes it easy to follow which path needs to be mitigated to reduce the risk level. However, countermeasures can defend against multiple attacks. For larger graphs, duplicating the node is sometimes better than having multiple outgoing edges that cross over the complete graph for better visibility.

The scalability analysis highlights both strengths and current limitations of the framework. While calculations and risk aggregation are performed automatically once basic values are assigned, graph construction, attribute assignment, and verification are still predominantly manual. This manual workload not only increases the time required but also introduces the potential for inconsistencies across different graphs. Although we mitigated this risk with a two-team verification process and XML-based validation scripts, full integration of consistency checks into the tool remains a desirable improvement. Furthermore, verification of identical values across recurring nodes could be automated with relatively simple scripting support, but would remain an external tool as long as graphs are saved as separate files. As noted in the related work, several methods for automatic graph generation exist, provided that a sufficiently detailed system description is available. In our project, only general system documentation was accessible, which precluded the use of these methods. Another limitation lies in the manual assignment of node and impact values, which currently requires substantial analyst effort and introduces potential for inconsistency. To overcome this, we are currently working on automating the derivation of node attributes from Common Vulnerability Scoring System (CVSS) scores, thereby reducing manual workload and error potential in future applications.

9 Conclusion

This article presented that the entire process of risk assessment can be performed using a graphical solution, enhancing clarity for all stakeholders and adaptability regarding changed conditions. We showed that our framework enables the replication of the risk assessment process visually and is also compatible with existing risk assessment standards, like the ISO/SAE 21434 or the CLC/TS 50701. We further verified this framework in our research project “Forecast of security requirements and evaluation of possible security concepts for the railway system”, financed by the German Centre of Rail Traffic Research¹³, by creating 21 graphs of varying sizes in the domain of railway systems. The Risk Assessment Graphs¹² and the plugin tool¹¹ for diagrams.net¹⁴ with which they were created are publicly available. Using our framework enables a continuous evaluation and re-evaluation of the risk landscape, including changing systems, countermeasures, and attacker capabilities.

The Risk Assessment Graphs defined in this work provide all seven characteristics for graphical risk assessment: (1) attack vectors, (2) directed acyclic graph structure, (3) node attributes, (4) dynamic connectors, (5) edge attributes, (6) countermeasure nodes, and(7) consequence nodes. The Risk Assessment Graphs were further evaluated in the research project. There, we created 21 graphs of various sizes for future railway systems, using the risk assessment process to identify the need for further research and standardization of countermeasures.

A limitation of a graphical solution is that there is no direct way to include detailed explanations. Furthermore, especially for larger graphs, the structure is not as organized as there are a lot of connections. Resulting in at least some work effort to rearrange the nodes and edges or to double some nodes. Table-based solutions are usually able to cross-reference data, which should also be possible for graph-based solutions, but is not that intuitive and, at least in our developed tool, has not been implemented yet, neither within one graph nor between multiple graphs.

As we move forward, we recognize the potential for further advancements in the field of risk assessment using Risk Assessment Graphs. Future research may focus on incorporating real-time threat intelligence feeds and exploring the integration of automation for continuous risk monitoring to reduce the burden on analysts. Therefore, we want to investigate the possibility of connecting the graphs with the Common Vulnerability and Exposure (CVE) system and enable automatic suggestions to incorporate suitable CVE numbers, similar to Klement et al. [49]. From the connected CVEs, we want to automatically generate the appropriate attribute values by taking the Common Vulnerability Scoring System (CVSS) scores. These measures would simplify the creation process as well as the uniformity between graphs created by different analysts. We also want to reduce the burden of maintaining the graphs by incorporating an update mechanism for the CVSS scores.

Furthermore, we explore the possibility of automatically simplifying the model for better scalability and ease of interpretation. This can include automatically cutting off sub-graphs and linking them via a specific node. The sub-graph is then treated separately and the values of the root node are passed on over the linking node. Automatically separating sub-graphs can improve the ease of interpretation by dividing big graphs into smaller ones. For this, the drawio feature of pages could be utilized to keep all components in one file. Whereas the scalability can be improved by extracting sub-graphs that are used for multiple scenarios or use cases into a separate linked file.

Another interesting feature for future research is the use of machine learning in order to estimate attribute values. However, that might not always be possible. E.g., if systems under development are analyzed, no historical data on vulnerabilities might be available. Furthermore, machine learning models trained on historical data may not capture the evolving threat landscape. In both cases, one has to resort to expert opinions.

In conclusion, our graphical solution using Risk Assessment Graphs represents a significant step toward a robust and efficient cyber risk assessment. By harnessing the power of visual representations, we aim to strengthen OT cybersecurity defenses, ultimately ensuring the resilience and trustworthiness of modern computer systems in the face of evolving threats.