<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD Journal Publishing DTD v2.3 20070202//EN" "journalpublishing.dtd">
<article article-type="research-article" dtd-version="2.3" xml:lang="EN" xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">
<front>
<journal-meta>
<journal-id journal-id-type="publisher-id">Front. Complex Syst.</journal-id>
<journal-title>Frontiers in Complex Systems</journal-title>
<abbrev-journal-title abbrev-type="pubmed">Front. Complex Syst.</abbrev-journal-title>
<issn pub-type="epub">2813-6187</issn>
<publisher>
<publisher-name>Frontiers Media S.A.</publisher-name>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="publisher-id">1620260</article-id>
<article-id pub-id-type="doi">10.3389/fcpxs.2025.1620260</article-id>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Complex Systems</subject>
<subj-group>
<subject>Original Research</subject>
</subj-group>
</subj-group>
</article-categories>
<title-group>
<article-title>Network modelling in analysing cyber-related graphs</article-title>
<alt-title alt-title-type="left-running-head">Kuikka et al.</alt-title>
<alt-title alt-title-type="right-running-head">
<ext-link ext-link-type="uri" xlink:href="https://doi.org/10.3389/fcpxs.2025.1620260">10.3389/fcpxs.2025.1620260</ext-link>
</alt-title>
</title-group>
<contrib-group>
<contrib contrib-type="author" corresp="yes">
<name>
<surname>Kuikka</surname>
<given-names>Vesa</given-names>
</name>
<xref ref-type="corresp" rid="c001">&#x2a;</xref>
<xref ref-type="author-notes" rid="fn1">
<sup>&#x2020;</sup>
</xref>
<uri xlink:href="https://loop.frontiersin.org/people/2884682/overview"/>
<role content-type="https://credit.niso.org/contributor-roles/methodology/"/>
<role content-type="https://credit.niso.org/contributor-roles/visualization/"/>
<role content-type="https://credit.niso.org/contributor-roles/conceptualization/"/>
<role content-type="https://credit.niso.org/contributor-roles/validation/"/>
<role content-type="https://credit.niso.org/contributor-roles/writing-original-draft/"/>
<role content-type="https://credit.niso.org/contributor-roles/Writing - review &#x26; editing/"/>
<role content-type="https://credit.niso.org/contributor-roles/formal-analysis/"/>
<role content-type="https://credit.niso.org/contributor-roles/software/"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Pyk&#xe4;l&#xe4;</surname>
<given-names>Lauri</given-names>
</name>
<role content-type="https://credit.niso.org/contributor-roles/Writing - review &#x26; editing/"/>
<role content-type="https://credit.niso.org/contributor-roles/writing-original-draft/"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Takko</surname>
<given-names>Tuomas</given-names>
</name>
<role content-type="https://credit.niso.org/contributor-roles/project-administration/"/>
<role content-type="https://credit.niso.org/contributor-roles/Writing - review &#x26; editing/"/>
<role content-type="https://credit.niso.org/contributor-roles/writing-original-draft/"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname>Kaski</surname>
<given-names>Kimmo K.</given-names>
</name>
<xref ref-type="author-notes" rid="fn1">
<sup>&#x2020;</sup>
</xref>
<uri xlink:href="https://loop.frontiersin.org/people/1489045/overview"/>
<role content-type="https://credit.niso.org/contributor-roles/funding-acquisition/"/>
<role content-type="https://credit.niso.org/contributor-roles/writing-original-draft/"/>
<role content-type="https://credit.niso.org/contributor-roles/supervision/"/>
<role content-type="https://credit.niso.org/contributor-roles/Writing - review &#x26; editing/"/>
</contrib>
</contrib-group>
<aff>
<institution>Department of Computer Science, Aalto University School of Science</institution>, <addr-line>Otakaari</addr-line>, <country>Finland</country>
</aff>
<author-notes>
<fn fn-type="edited-by">
<p>
<bold>Edited by:</bold> <ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/2163427/overview">Christian Beck</ext-link>, Queen Mary University of London, United Kingdom</p>
</fn>
<fn fn-type="edited-by">
<p>
<bold>Reviewed by:</bold> <ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/609385/overview">Maxi San Miguel</ext-link>, IFISC (CSIC-UIB), Spain</p>
<p>
<ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/2037532/overview">Claudio Castellano</ext-link>, Istituto dei Sistemi Complessi (ISC-CNR), Italy</p>
</fn>
<corresp id="c001">&#x2a;Correspondence: Vesa Kuikka, <email>vesa.kuikka@aalto.fi</email>
</corresp>
<fn fn-type="other" id="fn1">
<label>
<sup>&#x2020;</sup>
</label>
<p>ORCID: Vesa Kuikka, <ext-link ext-link-type="uri" xlink:href="http://orcid.org/0000-0002-3677-816X">orcid.org/0000-0002-3677-816X</ext-link>; Kimmo K. Kaski, <ext-link ext-link-type="uri" xlink:href="http://orcid.org/0000-0002-3805-9687">orcid.org/0000-0002-3805-9687</ext-link>
</p>
</fn>
</author-notes>
<pub-date pub-type="epub">
<day>16</day>
<month>09</month>
<year>2025</year>
</pub-date>
<pub-date pub-type="collection">
<year>2025</year>
</pub-date>
<volume>3</volume>
<elocation-id>1620260</elocation-id>
<history>
<date date-type="received">
<day>29</day>
<month>04</month>
<year>2025</year>
</date>
<date date-type="accepted">
<day>26</day>
<month>08</month>
<year>2025</year>
</date>
</history>
<permissions>
<copyright-statement>Copyright &#xa9; 2025 Kuikka, Pyk&#xe4;l&#xe4;, Takko and Kaski.</copyright-statement>
<copyright-year>2025</copyright-year>
<copyright-holder>Kuikka, Pyk&#xe4;l&#xe4;, Takko and Kaski</copyright-holder>
<license xlink:href="http://creativecommons.org/licenses/by/4.0/">
<p>This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY). The use, distribution or reproduction in other forums is permitted, provided the original author(s) and the copyright owner(s) are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these terms.</p>
</license>
</permissions>
<abstract>
<p>To improve the resilience of the computer network infrastructure against cyber attacks or causal influences and find ways to mitigate their impact, we need to understand their structure and dynamics. Here, we propose a novel network-based influence-spreading modelling approach to investigate event trajectories or paths in attack and causal graphs with directed, weighted, cyclic and/or acyclic paths. In our model, we can perform probabilistic analyses that extend beyond traditional methods to visualise cyber-related graphs. The model uses a probabilistic method to combine paths that join within the graph. This analysis includes vulnerabilities, services, and exploitabilities. To demonstrate the applicability of our model, we present three cyber-related use cases: two attack graphs and one causal graph. This model can serve cyber analysts as a tool to produce quantitative metrics for prioritising tasks, summarising statistics, or analysing large-scale graphs.</p>
</abstract>
<kwd-group>
<kwd>attack modelling technique</kwd>
<kwd>network modelling</kwd>
<kwd>attack graph</kwd>
<kwd>causal graph</kwd>
<kwd>directed acyclic graph</kwd>
</kwd-group>
<counts>
<page-count count="16"/>
</counts>
<custom-meta-wrap>
<custom-meta>
<meta-name>section-at-acceptance</meta-name>
<meta-value>Complex Networks</meta-value>
</custom-meta>
</custom-meta-wrap>
</article-meta>
</front>
<body>
<sec id="s1">
<title>1 Introduction</title>
<p>Cyber attacks are unauthorised actions against computer network infrastructure to exploit vulnerabilities in target systems, while cyber threats refer to potential adversarial events in which an attacker could exploit vulnerabilities (<xref ref-type="bibr" rid="B18">Li and Liu, 2021</xref>). Typically, a cyber attack can consist of a number of actions, events, or steps required for the attacker to gain access or sufficient privileges to achieve the objective of an attack, e.g., denial of service (DOS) or the delivery and use of malware. A common approach to classifying these steps has been through various frameworks such as the cyber kill chain (<xref ref-type="bibr" rid="B9">Hutchins et al., 2011</xref>). At a more technical level, potential or real cyber attacks have often been modelled as directed graph structures. Among these graph-based methods, attack graphs and their variants are often used to represent cyber attacks (<xref ref-type="bibr" rid="B15">Lallie et al., 2020</xref>; <xref ref-type="bibr" rid="B19">Liu et al., 2012</xref>; <xref ref-type="bibr" rid="B32">Wachter, 2023</xref>; <xref ref-type="bibr" rid="B35">Zeng et al., 2019</xref>; <xref ref-type="bibr" rid="B36">Zenitani, 2023</xref>). There are two commonly used forms of attack graphs: the first is a directed graph with nodes representing network states and edges (links) representing exploits, while the second uses nodes to represent pre- or post-conditions of an exploit and edges to show the consequences. In addition, knowledge-based methods are used to model attack concepts and vulnerability details (<xref ref-type="bibr" rid="B4">Alserhani, 2015</xref>; <xref ref-type="bibr" rid="B24">Qi et al., 2023</xref>; <xref ref-type="bibr" rid="B29">Sikos, 2023</xref>).</p>
<p>In order to understand, analyse, and visualise the sequence of events of a successful cyber attack, we will here use attack modelling techniques (AMTs). There are three main categories of AMT: (i) methods based on use cases like misuse or security use cases, (ii) temporal methods based on, e.g., cyber kill chains, and (iii) methods based on graphs (<xref ref-type="bibr" rid="B15">Lallie et al., 2020</xref>). Here, we will focus on graph-based models as they enable cyber analysts and researchers to formulate and use different metrics, both quantitative and qualitative, to optimise and prioritise defensive efforts (<xref ref-type="bibr" rid="B15">Lallie et al., 2020</xref>). Graph-based cyber attack modelling can be conducted at various technological levels, including applications, services, or entire computer networks. To achieve this, mappings from technical micro-service levels to higher clustering levels can be accomplished using technical configuration repositories.</p>
<p>In the literature, the term <italic>attack graph</italic> has been used to refer to a variety of modelling approaches (<xref ref-type="bibr" rid="B32">Wachter, 2023</xref>), which present a taxonomy of these models based on analysing 70 attack graph formalisms. This taxonomy uses a hierarchical categorisation with two top-level categories: sequential models and causal dependency models. Sequential models represent attack steps and paths formed by them, while causal dependency models focus on cause-effect relationships. Based on node semantics, sequential models are further categorised into asset-oriented, vulnerability-/exploit-oriented, and condition-/attribute-oriented types.</p>
<p>Our research approach will focus on network modelling, as it provides a range of methods and tools for analysing cyber-related graphs from different perspectives and aggregation levels. One recent approach involves modelling network structure and influence flow at a detailed level of nodes and links (<xref ref-type="bibr" rid="B2">Almiala et al., 2023</xref>; <xref ref-type="bibr" rid="B13">Kuikka and Kaski, 2024</xref>; <xref ref-type="bibr" rid="B14">Kuikka et al., 2022</xref>). This network model uses Markov processes and applies probability theory to assess the combined effects from multiple sources. Our method for evaluating the effects of various joining paths in both acyclic and cyclic (<xref ref-type="bibr" rid="B17">Levner and Tsadikovich, 2024</xref>) graphs extends the probabilistic techniques discussed in the literature (<xref ref-type="bibr" rid="B5">Carter et al., 2014</xref>; <xref ref-type="bibr" rid="B8">Homer et al., 2013</xref>; <xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>; <xref ref-type="bibr" rid="B33">Wang et al., 2008</xref>). In this study, we calculate the combined effect of multiple alternative paths in a graph by using the theorem of non-mutually exclusive events from probability theory. Details of the model and its corresponding algorithm can be found in (<xref ref-type="bibr" rid="B14">Kuikka et al., 2022</xref>). In general, our probabilistic modelling approach serves as an integrated, graph-based methodology or framework for analysing various types of influence spreading processes, including cyber attacks. The integration of modelling and analysis metrics within the same probabilistic framework makes our approach self-consistent, distinguishing it from other graph-based methods.</p>
<p>In this study, we present the modelling of cyber-related graphs through three use cases and demonstrate how the model can be applied to examine the exploitability, causality, and incomplete graph information in the computer network and services system. The first use case (<xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>) involves a directed acyclic graph in which the states of the system are represented as nodes and the vulnerabilities as links between the nodes, forming an attack graph. The exploitability of a vulnerability is interpreted as the probability of a successful exploit (i.e., traversability of a link). In the network model, these probabilities are assigned to link weights, which are derived using general CVSS scoring data (Common Vulnerability Scoring System) (<xref ref-type="bibr" rid="B21">NIST, 2012</xref>) and adjusted with a scaling factor. The second use case (<xref ref-type="bibr" rid="B3">Alsaheel et al., 2021</xref>) demonstrates a larger network structure of services and applications, illustrating how exploitability metrics can be utilised to produce aggregate security metrics concerning vulnerability and service levels. The third use case (<xref ref-type="bibr" rid="B3">Alsaheel et al., 2021</xref>; <xref ref-type="bibr" rid="B11">Jiang et al., 2017</xref>) involves two types of nodes, namely, attack entities and non-attack entities identified by an attack investigation tool using natural language processing and deep learning. This use case illustrates how our model can address inaccuracies in results from threat analysis tools.</p>
<p>These use cases demonstrate how different categorisations can be applied within the model. Because the model presents metrics as probabilities, it aids in forming a consistent understanding of the situation from various perspectives. Additionally, our model introduces novel methods for analysing cyber-related graphs. It employs a probabilistic technique to merge multiple alternative paths&#x2014;both cyclic and acyclic&#x2014;within a graph. The model uses a detailed model to consider all potential paths through the nodes of the network and defines new metrics to estimate the exploitability and impacts. For instance, it can be used to evaluate the impact of eliminating certain vulnerabilities across services or protecting targeted services within the system. Therefore, our model could serve as a valuable aid for cyber analysts and those designing cyber-secure systems. Based on our model, it is possible to develop a visualisation and analysis tool that allows cyber analysts to leverage various model outputs and metrics for real-world mitigation planning. This tool could include enterprise-specific assessments related to exploitability and impact values. As a result, analysts could perform what-if analyses and inspect specific parts of networks and systems.</p>
<p>In <xref ref-type="sec" rid="s3">Section 3</xref>, we will present our network modelling method and analysis metrics. The pseudo-algorithms of our influence spreading model are reproduced in the supplementary material from our earlier study (<xref ref-type="bibr" rid="B14">Kuikka et al., 2022</xref>). In <xref ref-type="sec" rid="s2">Section 2</xref>, we review related research on attack graphs and metrics used to assess the impacts of cyber attacks. In <xref ref-type="sec" rid="s4">Section 4</xref>, we describe the data and networks of the use cases on which the model is demonstrated. In <xref ref-type="sec" rid="s5">Section 5</xref>, we will explain how the model can be used to obtain new results in analysing cyber-related graphs through the three use cases. In <xref ref-type="sec" rid="s6">Section 6</xref>, we will discuss the applications of our graph-based methods in analysing cyber vulnerabilities and attacks, and present concluding remarks.</p>
</sec>
<sec id="s2">
<title>2 Related work</title>
<p>Several reviews have been published about attack graphs and related cybersecurity methods and models to analyse them (<xref ref-type="bibr" rid="B15">Lallie et al., 2020</xref>; <xref ref-type="bibr" rid="B32">Wachter, 2023</xref>; <xref ref-type="bibr" rid="B35">Zeng et al., 2019</xref>; <xref ref-type="bibr" rid="B36">Zenitani, 2023</xref>). The review in (<xref ref-type="bibr" rid="B15">Lallie et al., 2020</xref>) provides a description of a theory of cyber attacks and how elements of attack graphs and attack trees are represented and visualised. The study in (<xref ref-type="bibr" rid="B32">Wachter, 2023</xref>) presents the state of research on the representation and analysis of cyber attacks using attack graph formalisms and proposing a classification based on an analysis of models regarding graph semantics, agents involved, and analytical features. This study also investigates which formalisms enable automatic attack graph generation from raw or processed data input.</p>
<p>The review in (<xref ref-type="bibr" rid="B36">Zenitani, 2023</xref>) presents a recent summary of studies on attack graphs, by focusing on key concepts such as exploit dependency and/or rules (<xref ref-type="bibr" rid="B17">Levner and Tsadikovich, 2024</xref>), monotonicity, and handling cycles. The study in (<xref ref-type="bibr" rid="B35">Zeng et al., 2019</xref>) describes the key concepts, generation methods, and computation tasks of attack graphs. Also, it summarises various analysis methods, including graph-based, Bayesian network-based, Markov model-based, cost-optimisation, and uncertainty analysis methods. In the attack graph analysis, there is a need to quantify the levels of threats, vulnerabilities, exploits, and impact, each with appropriate metrics. For example, in enterprise environments, system security metrics (<xref ref-type="bibr" rid="B23">Pendleton et al., 2016</xref>) and network attack graph metrics (<xref ref-type="bibr" rid="B22">Noel and Jajodia, 2017</xref>) have been proposed to evaluate and compare the threats and impacts of cyber attacks.</p>
<p>In the literature (<xref ref-type="bibr" rid="B27">Shakarian et al., 2015</xref>), an Independent Cascade (IC) model has been proposed as a way to describe influence maximisation. This model assumes that nodes activate their neighbours independently on the basis of a fixed probability rather than multi-step logical relationships, as in the case of our influence spreading model. A key difference is that the IC model does not consider joining paths, like our present model does by following the probabilistic rule of mutually non-exclusive events. This can result in a more realistic evaluation of the overall risk for the enterprise network and services. Our probabilistic method also allows us to calculate expected cumulative and non-cumulative impact values, as well as the circular effects of attack propagation.</p>
<p>The present study is related to two earlier works: one by <xref ref-type="bibr" rid="B30">Stergiopoulos et al. (2022)</xref> and another by <xref ref-type="bibr" rid="B3">Alsaheel et al. (2021)</xref>. The data for the first two use cases are adapted from (<xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>), while the data for the third use case comes from (<xref ref-type="bibr" rid="B3">Alsaheel et al., 2021</xref>). The study in (<xref ref-type="bibr" rid="B3">Alsaheel et al., 2021</xref>) presents a sequence-based learning approach to investigate attacks, whereas (<xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>) proposes an automatic analysis of attack graphs to facilitate risk mitigation and prioritisation using probabilistic methods. Our method uses probability-based path combination, which complements the approach outlined in (<xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>). In that approach, single paths, as well as those with minimum and maximum exploitability and impact values, are assessed. However, our method is well suited for the comprehensive evaluation of enterprise networks. In contrast, the single path method allows for a detailed analysis of individual attack paths. Both techniques can be used together to examine different aspects of cyber attacks. Moreover, in enterprise-scale networks, analysing single paths can be computationally resource-intensive due to the vast number of potential combinations. Relying solely on subjective judgment to limit the set of possible paths may not produce accurate results.</p>
<p>Although there are a number of studies using graph-based cyber attacks modelling, a comprehensive approach applicable to various levels of applications and services in enterprise networks is still lacking. In the present study, we introduce a probabilistic method to quantitatively analyse cyber-related graphs and identify strategies to improve the resilience of network infrastructure.</p>
</sec>
<sec id="s3">
<title>3 Attack graph model</title>
<p>Graphs related to cyber security, such as attack graphs and causal graphs, are mainly created to help visualise complexities of attack sequences and plan ways to prevent them (<xref ref-type="bibr" rid="B15">Lallie et al., 2020</xref>). These graphs are usually generated from large volumes of data for this purpose (<xref ref-type="bibr" rid="B28">Sheyner and Wing, 2003</xref>; <xref ref-type="bibr" rid="B31">Stojanovi&#x107; et al., 2020</xref>). Consequently, the resulting graphs typically contain a small number of nodes, ranging from a few to hundreds.</p>
<p>In our network-based modelling approach (<xref ref-type="bibr" rid="B14">Kuikka et al., 2022</xref>) we consider and analyse cyber attack processes from the point of view of influence spreading for finding ways to prevent or mitigate potential or ongoing attacks (<xref ref-type="bibr" rid="B7">Haque et al., 2021</xref>; <xref ref-type="bibr" rid="B26">Segovia-Ferreira et al., 2024</xref>). The model describes the network structure, including individual nodes and links. Influence spreads through a non-conserved process, moving from a node to all neighbouring nodes via directed links. In our model, the influence spreading can be assumed to take place via acyclic or cyclic Markov processes on a complex network structure. In the present study, the model describes attack propagation along self-avoiding paths, representing acyclic paths, and uses unrestricted paths to represent general propagation through either acyclic or cyclic paths.</p>
<p>The weights assigned to directed links represent the probabilities of successful attack propagation steps within a graph structure. Since the actual parameter values, including link weights and CVSS scores, can vary greatly in real environments, in this study, we employ a scaling factor to cover the full range of possible parameter values. This approach also enables what-if and sensitivity analyses to explore various attack scenarios and environments.</p>
<p>Our model is quite versatile as it offers different approaches to dealing with full breakthrough of nodes or self-avoiding paths. The first approach allows loops in the spreading process, while the second approach is better for examining connectivity between nodes. Loops consisting of a minimum of three nodes connected by links enable circular propagation of influence within the network structure. Both approaches yield similar results for directed acyclic graphs because the network lacks cyclic processes. In case of full breakthrough effects, a bidirectional link creates a cycle between the two nodes at each end of the link, resulting in recurring events in the network. Note that due to spreading, the effects are not limited to those nodes but spread throughout the network structure. In the case of self-avoiding paths, no recurring effects are permitted, and the process can propagate only in one direction along a path.</p>
<p>The method and corresponding algorithms proposed in our earlier article (<xref ref-type="bibr" rid="B14">Kuikka et al., 2022</xref>) are based on modelling network structure and spreading processes. This results in an <inline-formula id="inf1">
<mml:math id="m1">
<mml:mrow>
<mml:mi>N</mml:mi>
<mml:mo>&#xd7;</mml:mo>
<mml:mi>N</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> probability matrix <inline-formula id="inf2">
<mml:math id="m2">
<mml:mrow>
<mml:mi>C</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, where the number of nodes in the network is denoted by <inline-formula id="inf3">
<mml:math id="m3">
<mml:mrow>
<mml:mi>N</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>. The matrix elements represent directed spreading or connectivity probabilities from one node to another in the network with a connecting path between them. When spreading from branching paths, it occurs in all possible directions, and the probabilities concern the first arrival at the end nodes. Subsequently, this matrix is used to define various metrics for analysing the network structure and network flow process. Note that models other than our influence spreading model can generate the probability matrix. As the analysis is based on the probability matrix, it is independent of the method used to produce the probability matrix. These models could even be non-Markovian or include other event types besides mutually non-exclusive events (OR rule) used to combine multiple joining alternative paths (<xref ref-type="bibr" rid="B14">Kuikka et al., 2022</xref>).</p>
<p>In network analysis, we use two metrics to evaluate the importance of a node, namely, out-centrality and in-centrality, and they are defined differently from the standard closeness centrality measures in the literature. One reason for using different metrics is the limitations of standard metrics in describing detailed network structures, because they are defined based on the shortest paths between nodes, thus ignoring other alternative paths an attack could propagate (<xref ref-type="bibr" rid="B16">Landherr et al., 2010</xref>). We use the probability matrix as the basis of analysis, as it enables the separation of the network modelling from the analysis (<xref ref-type="bibr" rid="B14">Kuikka et al., 2022</xref>).</p>
<p>Next, we define the centrality measures for the subset of nodes <inline-formula id="inf4">
<mml:math id="m4">
<mml:mrow>
<mml:mi>V</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> in the network <inline-formula id="inf5">
<mml:math id="m5">
<mml:mrow>
<mml:mi>G</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> of <inline-formula id="inf6">
<mml:math id="m6">
<mml:mrow>
<mml:mi>N</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> nodes. (Note that in the case of the entire network <inline-formula id="inf7">
<mml:math id="m7">
<mml:mrow>
<mml:mi>V</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> &#x3d; <inline-formula id="inf8">
<mml:math id="m8">
<mml:mrow>
<mml:mi>G</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>). For the influence spreading through the network, we define the out-centrality of the source node <inline-formula id="inf9">
<mml:math id="m9">
<mml:mrow>
<mml:mi>s</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> by<disp-formula id="e1">
<mml:math id="m10">
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mi>C</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mfenced open="(" close=")">
<mml:mrow>
<mml:mi mathvariant="normal">o</mml:mi>
<mml:mi mathvariant="normal">u</mml:mi>
<mml:mi mathvariant="normal">t</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:msup>
<mml:mfenced open="(" close=")">
<mml:mrow>
<mml:mi>s</mml:mi>
</mml:mrow>
</mml:mfenced>
<mml:mo>&#x3d;</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mrow>
<mml:mi>N</mml:mi>
<mml:mo>&#x2212;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:mfrac>
<mml:mstyle displaystyle="true">
<mml:munder>
<mml:mrow>
<mml:mo>&#x2211;</mml:mo>
</mml:mrow>
<mml:mrow>
<mml:mtable class="subarray-c" columnalign="center">
<mml:mtr>
<mml:mtd>
<mml:mi>t</mml:mi>
<mml:mo>&#x2208;</mml:mo>
<mml:mi>V</mml:mi>
</mml:mtd>
</mml:mtr>
<mml:mtr>
<mml:mtd>
<mml:mi>s</mml:mi>
<mml:mo>&#x2260;</mml:mo>
<mml:mi>t</mml:mi>
</mml:mtd>
</mml:mtr>
</mml:mtable>
</mml:mrow>
</mml:munder>
</mml:mstyle>
<mml:mi>C</mml:mi>
<mml:mfenced open="(" close=")">
<mml:mrow>
<mml:mi>s</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:math>
<label>(1)</label>
</disp-formula>and the in-centrality of a target node <inline-formula id="inf10">
<mml:math id="m11">
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> by<disp-formula id="e2">
<mml:math id="m12">
<mml:mrow>
<mml:msup>
<mml:mrow>
<mml:mi>C</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mfenced open="(" close=")">
<mml:mrow>
<mml:mi mathvariant="normal">i</mml:mi>
<mml:mi mathvariant="normal">n</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:msup>
<mml:mfenced open="(" close=")">
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:mfenced>
<mml:mo>&#x3d;</mml:mo>
<mml:mfrac>
<mml:mrow>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mrow>
<mml:mi>N</mml:mi>
<mml:mo>&#x2212;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:mfrac>
<mml:mstyle displaystyle="true">
<mml:munder>
<mml:mrow>
<mml:mo>&#x2211;</mml:mo>
</mml:mrow>
<mml:mrow>
<mml:mtable class="subarray-c" columnalign="center">
<mml:mtr>
<mml:mtd>
<mml:mi>s</mml:mi>
<mml:mo>&#x2208;</mml:mo>
<mml:mi>V</mml:mi>
</mml:mtd>
</mml:mtr>
<mml:mtr>
<mml:mtd>
<mml:mi>s</mml:mi>
<mml:mo>&#x2260;</mml:mo>
<mml:mi>t</mml:mi>
</mml:mtd>
</mml:mtr>
</mml:mtable>
</mml:mrow>
</mml:munder>
</mml:mstyle>
<mml:mi>C</mml:mi>
<mml:mfenced open="(" close=")">
<mml:mrow>
<mml:mi>s</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:mfenced>
<mml:mo>.</mml:mo>
</mml:mrow>
</mml:math>
<label>(2)</label>
</disp-formula>Here, the out-centrality of a node is the average value of probabilities of spreading from the source node to all other nodes in <inline-formula id="inf11">
<mml:math id="m13">
<mml:mrow>
<mml:mi>V</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, while the in-centrality of a node is the average value of probabilities of spreading from all other nodes in <inline-formula id="inf12">
<mml:math id="m14">
<mml:mrow>
<mml:mi>V</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> to the target node. These centrality measures describe the physical properties of the network structure and the flow process. As <inline-formula id="inf13">
<mml:math id="m15">
<mml:mrow>
<mml:mi>C</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:mi>s</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>t</mml:mi>
</mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> is the probability of influence spreading from node <inline-formula id="inf14">
<mml:math id="m16">
<mml:mrow>
<mml:mi>s</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> to node <inline-formula id="inf15">
<mml:math id="m17">
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, the sum in <xref ref-type="disp-formula" rid="e1">Equation 1</xref> is interpreted as the expected value of the influenced nodes and the sum in <xref ref-type="disp-formula" rid="e2">Equation 2</xref> as the expected number of nodes that spread influence to the specified node. In the context of cyber-related graphs, influence spreading refers to the propagation of cyber attacks within the graph. In this study, we adopt the convention of setting the state value of the source node as zero and using the corresponding normalisation factor <inline-formula id="inf16">
<mml:math id="m18">
<mml:mrow>
<mml:mn>1</mml:mn>
<mml:mo>/</mml:mo>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:mi>N</mml:mi>
<mml:mo>&#x2212;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> and express the results as percentage values.</p>
<p>When dealing with cyber-related graphs, the out-centrality is a measure for assessing the potential effect of a cyber attack on other nodes within the network. On the other hand, in-centrality is useful for understanding how various cyber attacks can affect nodes in the network. Detailed information can be obtained by focusing on a subset of start and end nodes using <xref ref-type="disp-formula" rid="e1">Equations 1</xref>, <xref ref-type="disp-formula" rid="e2">2</xref>. Typically, the main focus is to explore vulnerabilities and the effect of a start node on an end node. However, multiple start nodes and end nodes can exist in one cyber-related graph.</p>
<p>Let us move on to discuss the metrics of exploitability and impact. The exploitability represents the probability of a successful cyber attack through a link, while impact describes its effect on the system, functionality, or operation. To assess the impact of different needs both at the technical and operational levels, the first step is to define the concept in the specific situation. The impact is calculated for the nodes and the exploitability is calculated for the links. We assume that the impact value does not influence the probabilities of propagation of the cyber attack. Therefore, impact values may not be expressed as probabilities and can have numerical values beyond the range of <inline-formula id="inf17">
<mml:math id="m19">
<mml:mrow>
<mml:mo stretchy="false">[</mml:mo>
<mml:mrow>
<mml:mn>0,1</mml:mn>
</mml:mrow>
<mml:mo stretchy="false">]</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula>. However, the impact values for different nodes are comparable, enabling us to calculate the desired sums for paths or network structures.</p>
<p>When assessing vulnerabilities, there are two main approaches: the General CVSS scoring (Common Vulnerability Scoring System) (<xref ref-type="bibr" rid="B21">NIST, 2012</xref>) or a custom evaluation method in which organisations supplement or override CVSS with their own risk assessments. The empirical CVSS scoring system provides a quantitative way to capture key characteristics of a vulnerability, resulting in scores that indicate its severity (the impact on a system) and exploitability (the ease of exploitation) (<xref ref-type="bibr" rid="B20">Mell et al., 2007</xref>). These metrics adhere to international standards for measuring cybersecurity risks. By using either CVSS or a custom evaluation, organisations can prioritise patches and mitigation strategies based on the potential impact of each vulnerability. We demonstrate the use of the CVSS scoring system in our first use case. In our second use case, since the general CVSS scores are uniformly high across all vulnerabilities, we focus on illustrating the network structure of services and applications and, therefore, use equal values for the vulnerability characteristics of all vulnerabilities. Furthermore, it is important to note that the general CVSS method may not accurately reflect the actual risk in a specific organisation or environment. The equations and algorithms used to score the base, temporal, and environmental metric groups are detailed in (<xref ref-type="bibr" rid="B20">Mell et al., 2007</xref>). Additional information on the origin and testing of these equations can be found at (<xref ref-type="bibr" rid="B6">FIRST, 2025</xref>).</p>
<p>Our approach is based on the use of link weights as probabilities to represent successful exploits. The exploitability metric measures the current state of exploit techniques or code availability. When easily accessible exploit code is publicly available, it increases the number of potential attackers, including unskilled ones, increasing the severity of vulnerabilities. The following equation illustrates how the factors <inline-formula id="inf18">
<mml:math id="m20">
<mml:mrow>
<mml:mi>A</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>s</mml:mi>
<mml:mi>s</mml:mi>
<mml:mi>V</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>r</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, <inline-formula id="inf19">
<mml:math id="m21">
<mml:mrow>
<mml:mi>A</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>s</mml:mi>
<mml:mi>s</mml:mi>
<mml:mi>C</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>m</mml:mi>
<mml:mi>p</mml:mi>
<mml:mi>l</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>x</mml:mi>
<mml:mi>i</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>y</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>, and <inline-formula id="inf20">
<mml:math id="m22">
<mml:mrow>
<mml:mi>A</mml:mi>
<mml:mi>u</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>h</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>n</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>a</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>n</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> describe the accessibility and complexity of the vulnerability, and whether additional conditions are needed to exploit it. The exploitability metric is defined as follows (<xref ref-type="bibr" rid="B20">Mell et al., 2007</xref>):<disp-formula id="e3">
<mml:math id="m23">
<mml:mrow>
<mml:mtable class="aligned">
<mml:mtr>
<mml:mtd columnalign="right">
<mml:mi>E</mml:mi>
<mml:mi>x</mml:mi>
<mml:mi>p</mml:mi>
<mml:mi>l</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>i</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>a</mml:mi>
<mml:mi>b</mml:mi>
<mml:mi>i</mml:mi>
<mml:mi>l</mml:mi>
<mml:mi>i</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>y</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>20</mml:mn>
<mml:mo>&#x2217;</mml:mo>
<mml:mi>A</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>s</mml:mi>
<mml:mi>s</mml:mi>
</mml:mtd>
<mml:mtd columnalign="left">
<mml:mi>V</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>r</mml:mi>
</mml:mtd>
</mml:mtr>
<mml:mtr>
<mml:mtd columnalign="right">
<mml:mo>&#x2217;</mml:mo>
<mml:mi>A</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>s</mml:mi>
<mml:mi>s</mml:mi>
<mml:mi>C</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>m</mml:mi>
<mml:mi>p</mml:mi>
<mml:mi>l</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>x</mml:mi>
<mml:mi>i</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>y</mml:mi>
</mml:mtd>
<mml:mtd columnalign="left">
<mml:mo>&#x2217;</mml:mo>
<mml:mi>A</mml:mi>
<mml:mi>u</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>h</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>n</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>a</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>i</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>n</mml:mi>
<mml:mo>.</mml:mo>
</mml:mtd>
</mml:mtr>
</mml:mtable>
</mml:mrow>
</mml:math>
<label>(3)</label>
</disp-formula>
</p>
<p>Impact metric measures the potential consequences of exploiting a vulnerability of an IT asset. These impacts are independently defined based on the degree of loss in three key areas, namely, confidentiality, integrity, and availability. The present analysis can be further extended to consider specific business impacts by incorporating relevant effects in <xref ref-type="disp-formula" rid="e5">Equation 5</xref>. The total impact metric is defined as follows (<xref ref-type="bibr" rid="B20">Mell et al., 2007</xref>):<disp-formula id="e4">
<mml:math id="m24">
<mml:mrow>
<mml:mtable class="aligned">
<mml:mtr>
<mml:mtd columnalign="right">
<mml:mi>I</mml:mi>
<mml:mi>m</mml:mi>
<mml:mi>p</mml:mi>
<mml:mi>a</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>t</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>10.41</mml:mn>
</mml:mtd>
<mml:mtd columnalign="left">
<mml:mo>&#x2217;</mml:mo>
<mml:mfenced open="(" close="">
<mml:mrow>
<mml:mn>1</mml:mn>
<mml:mo>&#x2212;</mml:mo>
<mml:mfenced open="(" close=")">
<mml:mrow>
<mml:mn>1</mml:mn>
<mml:mo>&#x2212;</mml:mo>
<mml:mi>C</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>n</mml:mi>
<mml:mi>f</mml:mi>
<mml:mi>I</mml:mi>
<mml:mi>m</mml:mi>
<mml:mi>p</mml:mi>
<mml:mi>a</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mfenced>
</mml:mtd>
</mml:mtr>
<mml:mtr>
<mml:mtd columnalign="right"/>
<mml:mtd columnalign="left">
<mml:mo>&#x2217;</mml:mo>
<mml:mfenced open="" close=")">
<mml:mrow>
<mml:mfenced open="(" close=")">
<mml:mrow>
<mml:mn>1</mml:mn>
<mml:mo>&#x2212;</mml:mo>
<mml:mi>I</mml:mi>
<mml:mi>n</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>e</mml:mi>
<mml:mi>g</mml:mi>
<mml:mi>I</mml:mi>
<mml:mi>m</mml:mi>
<mml:mi>p</mml:mi>
<mml:mi>a</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:mfenced>
<mml:mo>&#x2217;</mml:mo>
<mml:mfenced open="(" close=")">
<mml:mrow>
<mml:mn>1</mml:mn>
<mml:mo>&#x2212;</mml:mo>
<mml:mi>A</mml:mi>
<mml:mi>v</mml:mi>
<mml:mi>a</mml:mi>
<mml:mi>i</mml:mi>
<mml:mi>l</mml:mi>
<mml:mi>I</mml:mi>
<mml:mi>m</mml:mi>
<mml:mi>p</mml:mi>
<mml:mi>a</mml:mi>
<mml:mi>c</mml:mi>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:mfenced>
</mml:mrow>
</mml:mfenced>
<mml:mo>.</mml:mo>
</mml:mtd>
</mml:mtr>
</mml:mtable>
</mml:mrow>
</mml:math>
<label>(4)</label>
</disp-formula>In a network structure, a node can be targeted by different cyber attack paths from the source node through various links directed to the target node. In an attack graph, these may involve the same vulnerability. However, if different vulnerabilities can be exploited on one node, we calculate the weighted average value for the node or use the maximum impact of alternative exploits. We define a vector <inline-formula id="inf21">
<mml:math id="m25">
<mml:mrow>
<mml:mi>I</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> with elements representing the impact values for the nodes in the network. The impact of a cyber attack from the start nodes <inline-formula id="inf22">
<mml:math id="m26">
<mml:mrow>
<mml:mi>S</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> to the end nodes <inline-formula id="inf23">
<mml:math id="m27">
<mml:mrow>
<mml:mi>T</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> can be defined as:<disp-formula id="e5">
<mml:math id="m28">
<mml:mrow>
<mml:mi mathvariant="script">I</mml:mi>
<mml:mfenced open="(" close=")">
<mml:mrow>
<mml:mi>S</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>T</mml:mi>
<mml:mo>;</mml:mo>
<mml:mi>I</mml:mi>
</mml:mrow>
</mml:mfenced>
<mml:mo>&#x3d;</mml:mo>
<mml:mstyle displaystyle="true">
<mml:munder>
<mml:mrow>
<mml:mo>&#x2211;</mml:mo>
</mml:mrow>
<mml:mrow>
<mml:mtable class="subarray-c" columnalign="center">
<mml:mtr>
<mml:mtd>
<mml:mi>i</mml:mi>
<mml:mo>&#x2208;</mml:mo>
<mml:mi>S</mml:mi>
</mml:mtd>
</mml:mtr>
<mml:mtr>
<mml:mtd>
<mml:mi>j</mml:mi>
<mml:mo>&#x2208;</mml:mo>
<mml:mi>T</mml:mi>
</mml:mtd>
</mml:mtr>
</mml:mtable>
</mml:mrow>
</mml:munder>
</mml:mstyle>
<mml:mi>C</mml:mi>
<mml:mfenced open="(" close=")">
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:mfenced>
<mml:msub>
<mml:mrow>
<mml:mi>I</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>,</mml:mo>
</mml:mrow>
</mml:math>
<label>(5)</label>
</disp-formula>where the matrix <inline-formula id="inf24">
<mml:math id="m29">
<mml:mrow>
<mml:mi>C</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> consists of elements <inline-formula id="inf25">
<mml:math id="m30">
<mml:mrow>
<mml:mi>C</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>j</mml:mi>
</mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula> that represent the probabilities of successful attacks from node <inline-formula id="inf26">
<mml:math id="m31">
<mml:mrow>
<mml:mi>i</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> to node <inline-formula id="inf27">
<mml:math id="m32">
<mml:mrow>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> via alternative paths. The impact value on the end node alone includes the last exploit on the path. The impact value of <xref ref-type="disp-formula" rid="e5">Equation 5</xref> can be calculated for specific events, including effects on specific services or aspects of security. Additionally, <xref ref-type="disp-formula" rid="e5">Equation 5</xref> can be utilised to analyse the impact of exploits by determining the decrease in the impact value after mitigating vulnerabilities.</p>
<p>When all elements of vector <inline-formula id="inf28">
<mml:math id="m33">
<mml:mrow>
<mml:mi>I</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> are set to one, we obtain a quantity that describes the attack propagation from the source node set <inline-formula id="inf29">
<mml:math id="m34">
<mml:mrow>
<mml:mi>S</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> to the target node set <inline-formula id="inf30">
<mml:math id="m35">
<mml:mrow>
<mml:mi>T</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> in the network. In this way, the impact value in <xref ref-type="disp-formula" rid="e5">Equation 5</xref> is linked to the out- and in-centrality metrics in <xref ref-type="disp-formula" rid="e1">Equations 1</xref>, <xref ref-type="disp-formula" rid="e2">2</xref>. Therefore, the centrality measures and the impact measure in <xref ref-type="disp-formula" rid="e5">Equation 5</xref> are defined consistently with each other. Combining the alternative paths using probabilistic methods allows us to calculate accurate metrics based on <xref ref-type="disp-formula" rid="e3">Equations 3</xref> and <xref ref-type="disp-formula" rid="e4">4</xref> for real-world cyber attacks and different classifications.</p>
<p>As a further characteristic measure, one can calculate a cumulative impact for an individual attack path, as done in (<xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>). In our model approach, the cumulative impact along a path is calculated by summing up the products of propagation probabilities and node impacts according to <xref ref-type="disp-formula" rid="e5">Equation 5</xref>. Once again, the impact on the end node only includes the impact on that node.</p>
<p>In summary, four kinds of impact metrics can be calculated: cumulative impacts along individual paths or all alternative paths, and non-cumulative impacts on the end nodes through individual or all alternative paths. In this study, we prefer metrics that combine alternative paths using a probability theory approach and methods. The factors <inline-formula id="inf31">
<mml:math id="m36">
<mml:mrow>
<mml:msub>
<mml:mrow>
<mml:mi>C</mml:mi>
</mml:mrow>
<mml:mrow>
<mml:mi>i</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>j</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</inline-formula> in <xref ref-type="disp-formula" rid="e5">Equation 5</xref> account for the effects of all potential alternative paths. This approach allows for the definition of new metrics in analysing cyber events from different perspectives and categorisations. In the next section, we provide examples of this through use cases.</p>
</sec>
<sec id="s4">
<title>4 Use case data</title>
<p>For this study, we chose three different graph structures, described in <xref ref-type="table" rid="T1">Table 1</xref> to serve as our use cases.</p>
<table-wrap id="T1" position="float">
<label>TABLE 1</label>
<caption>
<p>Summary of the use case graphs.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="center">Graph</th>
<th align="center">Description</th>
<th align="center">Nodes</th>
<th align="center">Links</th>
<th align="center">References</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="center">Multi-cloud Enterprise Network</td>
<td align="center">Netflix OSS microservice system</td>
<td align="center">18</td>
<td align="center">25</td>
<td align="center">
<xref ref-type="bibr" rid="B30">Stergiopoulos et al. (2022)</xref>
</td>
</tr>
<tr>
<td align="center">Netflix OSS</td>
<td align="center">Netflix OSS microservice system</td>
<td align="center">21</td>
<td align="center">94</td>
<td align="center">
<xref ref-type="bibr" rid="B30">Stergiopoulos et al. (2022)</xref>
</td>
</tr>
<tr>
<td align="center">ATLAS, Pony campaign attack</td>
<td align="center">Recovered sequences and a causal graph</td>
<td align="center">39</td>
<td align="center">65</td>
<td align="center">
<xref ref-type="bibr" rid="B3">Alsaheel et al., 2021</xref>, <xref ref-type="bibr" rid="B11">Jiang et al., 2017</xref>
</td>
</tr>
</tbody>
</table>
</table-wrap>
<sec id="s4-1">
<title>4.1 Use case 1: Multi-cloud enterprise network</title>
<p>The graph for the Multi-cloud Enterprise Network from (<xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>) represents the network topology of two cloud infrastructures connected to the Internet behind an external firewall. The first cloud server hosts three virtual machines, all connected to a virtual switch. The second cloud server hosts a public network and a private network. External users can access a web server, and internal users can access the SQL server from inside the local network. Each server in this topology represents a realistic vendor-specific system with a set of real-world CVE vulnerabilities, with the impacts of exploitation extracted from the CVE database.</p>
</sec>
<sec id="s4-2">
<title>4.2 Use case 2: netflix OSS architecture</title>
<p>
<xref ref-type="bibr" rid="B10">Ibrahim et al. (2019)</xref> used a combination of tools to construct attack graphs for microservice architectures, consisting of a Docker host running various interconnected containers. The network topology was extracted from the docker-compose configuration files that define the orchestration of the services and details about the connections between containers, published ports, and any privileged access granted to containers. Vulnerabilities were scanned from the Docker images using the vulnerability scanning software Clair, producing a list of CVEs with textual descriptions and attack vectors for each image. The topology and vulnerability data were used as input for the final attack graph generation process. Attack pre- and postcondition parsing was performed by matching the attack vectors of the vulnerabilities by keyword matching (<xref ref-type="bibr" rid="B1">Aksu et al., 2018</xref>).</p>
</sec>
<sec id="s4-3">
<title>4.3 Use case 3: pony APT (advanced persistent threat) campaign</title>
<p>In the research conducted on the Pony APT campaign (CVE-2017-0199) (<xref ref-type="bibr" rid="B11">Jiang et al., 2017</xref>), the methodology was based on the work by <xref ref-type="bibr" rid="B3">Alsaheel et al. (2021)</xref>, describing a framework for constructing &#x201d;attack stories&#x201d; from audit logs. Their approach involved several steps. First, a platform independent causal graph representation was constructed using various system audit logs, including DNS records, web objects, processes, file accesses, and network connections. This graph was then abstracted using optimisation techniques to reduce its complexity. Specifically, nodes and edges that were not reachable from the attack nodes or attack symptom nodes were removed, repeated edges between entities were reduced to only the first occurrence, and nodes and edges referring to the same type of event were combined.</p>
<p>Next, the process of attack sequence construction took place. All &#x201c;attack entities&#x201d; from the causal graph were obtained, and subsets consisting of two or more attack entities were formed. The neighbourhood graph for each entity within these subsets was extracted, followed by retrieving time-stamped events for each neighbourhood graph. Sequences were labelled attack sequences if they consisted exclusively of attack events, which means that both the source and destination nodes were associated with attacks. Following this, sequence lemmatisation was performed. This involved transforming sequences into a textual representation using a general vocabulary of 30 words, divided into four types: process, file, network, and actions. To balance the dataset, non-attack sequences were undersampled, and attack sequences were oversampled by mutating existing attack sequences. Finally, the sequences were embedded and modelled, followed by an investigation of attack and recovery of &#x201c;attack stories&#x201d;. In the resulting processed graph, the semantic interpretations of nodes and edges are connected to system states inferred from the audit logs. The nodes represent processes (i.e., executables), files or IP addresses. The edges between them in turn represent actions or events between the entities, like <monospace>read</monospace>, <monospace>write</monospace>, <monospace>execute</monospace>, or <monospace>connect</monospace>.</p>
<p>The ATLAS approach thus focuses on reconstructing the attack story from observed system behaviours, with nodes and edges closely tied to actual system events and entities as recorded in the audit logs. Currently, the calculations treat all nodes in the graph equivalently, even in the use case where the graph nodes represent different entity types. A potential direction for further study is to treat different entities in the multiplex graph as distinct and perform the calculations separately for each node class.</p>
</sec>
</sec>
<sec sec-type="results" id="s5">
<title>5 Results</title>
<p>In this section, we present the results of our attack graph model for three different use cases. The first use case presents a small directed acyclic attack graph (<xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>). The second use case is a more complex attack graph from (<xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>) and finally, the third use case is a causal graph that was generated by an attack investigation tool using natural language processing and deep learning (<xref ref-type="bibr" rid="B3">Alsaheel et al., 2021</xref>).</p>
<sec id="s5-1">
<title>5.1 Use case 1: Multi-cloud enterprise network</title>
<p>We use a multi-cloud enterprise network as the first use case to demonstrate our modelling method. The network topology and vulnerabilities are adopted from (<xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>). The first cloud server hosts three virtual machines: a Mail server, a Web server, and a DNS server, and the second cloud server consists of public and private networks. The public network hosts an SQL server and a NAT gateway server, and the private network hosts an Admin server and three virtual machines (VMs). Users outside the network can access the Web server, and employees within the same LAN can access the SQL server through their workstations.</p>
<p>
<xref ref-type="fig" rid="F1">Figure 1</xref> shows the attack graph on the Multi-cloud Enterprise Network that consists of directed links representing the exploits and nodes representing the states. These kinds of networks are directed acyclic graphs (DAGs), i.e., without cycles (<xref ref-type="bibr" rid="B12">Kordy et al., 2014</xref>).</p>
<fig id="F1" position="float">
<label>FIGURE 1</label>
<caption>
<p>Use Case 1: Attack graph Multi-cloud Enterprise Network (<xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>).</p>
</caption>
<graphic xlink:href="fcpxs-03-1620260-g001.tif">
<alt-text content-type="machine-generated">Network diagram illustrating nodes labeled with server and workstation roles, connected by directional paths. Nodes include Start, End, WebServer, MailServer, and others. Paths are marked with green labels like E18, E19, showing various routes between nodes, indicating relationships and flow within the network.</alt-text>
</graphic>
</fig>
<p>The systems have vulnerabilities that are listed in the CVE vulnerabilities database (<xref ref-type="bibr" rid="B20">Mell et al., 2007</xref>). The attacker&#x2019;s goal is to compromise a virtual machine in the private network or the database in the public network by gaining root access. The attacker can take different paths in the attack graph.</p>
<p>In <xref ref-type="table" rid="T2">Table 2</xref>, we show the impact and exploitability values calculated for vulnerabilities in the attack graph (<xref ref-type="fig" rid="F1">Figure 1</xref>). The third column of this table shows the list of links in the attack graph for each vulnerability. In this context, impacts are associated with the properties of vulnerabilities (or edges), while in <xref ref-type="disp-formula" rid="e5">Equation 5</xref> and <xref ref-type="fig" rid="F1">Figure 1</xref>, successful cyber attacks affect services (or nodes). Our model treats nodes as representations of network states; therefore, all exploits of vulnerabilities that occur on the same node are assumed to have the same impact. If this does not hold, the construction of the attack graph is not consistent, and additional network states (or nodes) should be added to the attack graph.</p>
<table-wrap id="T2" position="float">
<label>TABLE 2</label>
<caption>
<p>Exploitability and impact values calculated from <xref ref-type="disp-formula" rid="e3">Equations 3</xref>, <xref ref-type="disp-formula" rid="e4">4</xref> for vulnerabilities in the attack graph of <xref ref-type="fig" rid="F1">Figure 1</xref> (<xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>).</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="center">Vulnerability</th>
<th align="center">Expl./10</th>
<th align="left">Impact</th>
<th align="left">Links</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="center">-</td>
<td align="center">1</td>
<td align="left">-</td>
<td align="left">E1,E2</td>
</tr>
<tr>
<td align="center">CVE-2010-3847</td>
<td align="center">0.339258</td>
<td align="left">10.00085</td>
<td align="left">E3,E4,E20</td>
</tr>
<tr>
<td align="center">CVE-2003-0693</td>
<td align="center">0.99968</td>
<td align="left">10.00085</td>
<td align="left">E5,E6</td>
</tr>
<tr>
<td align="center">CVE-2007-4752</td>
<td align="center">0.99968</td>
<td align="left">6.442977</td>
<td align="left">E7</td>
</tr>
<tr>
<td align="center">CVE-2001-0439</td>
<td align="center">0.99968</td>
<td align="left">6.442977</td>
<td align="left">E8</td>
</tr>
<tr>
<td align="center">CVE-2008-4050</td>
<td align="center">0.85888</td>
<td align="left">10.00085</td>
<td align="left">E9,E10</td>
</tr>
<tr>
<td align="center">CVE-2008-0015</td>
<td align="center">0.85888</td>
<td align="left">10.00085</td>
<td align="left">E11,E12,E21, E22,E23</td>
</tr>
<tr>
<td align="center">CVE-2009-1918</td>
<td align="center">0.99968</td>
<td align="left">10.00085</td>
<td align="left">E13,E16</td>
</tr>
<tr>
<td align="center">CVE-2018-7841</td>
<td align="center">0.99968</td>
<td align="left">6.442977</td>
<td align="left">E14,E18</td>
</tr>
<tr>
<td align="center">CVE-2004-0840</td>
<td align="center">0.99968</td>
<td align="left">10.00085</td>
<td align="left">E15</td>
</tr>
<tr>
<td align="center">CVE-2008-5416</td>
<td align="center">0.7952</td>
<td align="left">10.00085</td>
<td align="left">E17,E19</td>
</tr>
<tr>
<td align="center">CVE-2001-1030</td>
<td align="center">0.99968</td>
<td align="left">6.442977</td>
<td align="left">E24</td>
</tr>
<tr>
<td align="center">CVE-2009-1535</td>
<td align="center">0.99968</td>
<td align="left">6.442977</td>
<td align="left">E25</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>In <xref ref-type="fig" rid="F2">Figure 2</xref>, we illustrate the non-cumulative impact values of successful cyber attacks from the start node one to other nodes in the graph. For example, the node 7 has a lower impact than nodes <inline-formula id="inf32">
<mml:math id="m37">
<mml:mrow>
<mml:mn>6,14</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, and 17 because the vulnerability CVE-2007-4752 from the start node to node 7 has a relatively low impact value. On the other hand, node 10 has a high impact value because the vulnerability CVE-2008-0015, which affects nodes 7 and 12 and is propagated to node 10. As a numerical example, the value of the expected non-cumulative impact of node 10 is <inline-formula id="inf33">
<mml:math id="m38">
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:mn>0.859</mml:mn>
<mml:mo>&#x2b;</mml:mo>
<mml:mn>0.859</mml:mn>
<mml:mo>&#x2212;</mml:mo>
<mml:mn>0.859</mml:mn>
<mml:mo>&#xd7;</mml:mo>
<mml:mn>0.859</mml:mn>
</mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
<mml:mo>&#xd7;</mml:mo>
<mml:mn>10.0</mml:mn>
<mml:mo>&#x2248;</mml:mo>
<mml:mn>0.98</mml:mn>
<mml:mo>&#xd7;</mml:mo>
<mml:mn>10</mml:mn>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>9.8</mml:mn>
</mml:math>
</inline-formula>. The corresponding value of the expected cumulative impact is <inline-formula id="inf34">
<mml:math id="m39">
<mml:mrow>
<mml:mn>3</mml:mn>
<mml:mo>&#xd7;</mml:mo>
<mml:mn>6.44</mml:mn>
<mml:mo>&#x2b;</mml:mo>
<mml:mn>9.8</mml:mn>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>29.1</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>. This example illustrates how the probabilistic model is applied to calculate expected impacts, and the distinction between non-cumulative and cumulative impacts. The effects on other end nodes can be explained similarly according to <xref ref-type="disp-formula" rid="e5">Equation 5</xref>. In this numerical example and <xref ref-type="fig" rid="F2">Figure 2</xref>, we have used a scaling factor of <inline-formula id="inf35">
<mml:math id="m40">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> to emphasise the main idea. If a scaling factor is also used, then all exploitability values in <xref ref-type="table" rid="T2">Table 2</xref> are multiplied by the scaling factor to get the link weights in the attack graph model.</p>
<fig id="F2" position="float">
<label>FIGURE 2</label>
<caption>
<p>Impacts of successful cyber attacks from the start node one of <xref ref-type="fig" rid="F1">Figure 1</xref> to other nodes in the graph. The impact values calculated from <xref ref-type="disp-formula" rid="e5">Equation 5</xref> are highlighted with node colours and sizes.</p>
</caption>
<graphic xlink:href="fcpxs-03-1620260-g002.tif">
<alt-text content-type="machine-generated">Flowchart depicting a directed network graph with numbered nodes connected by arrows. Nodes are in shades of red and pink, with nodes 6, 17, 14, and 18 prominently larger. Arrows indicate directional relationships between nodes, forming a complex interconnected pattern.</alt-text>
</graphic>
</fig>
<p>In our model, we use out-centrality and in-centrality metrics to analyse the propagation of attacks from potential start nodes to potential end nodes. In <xref ref-type="fig" rid="F1">Figure 1</xref>, node one is the start node and node 18 is the end node, but there could be other nodes where the attack chain can start or end. For example, let us consider database servers (dbServer) as the attacker&#x2019;s goal, like in (<xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>). <xref ref-type="disp-formula" rid="e1">Equations 1</xref> and <xref ref-type="disp-formula" rid="e2">2</xref> define out-centrality and in-centrality metrics as expected values over the whole network structure, not just for possible start and end nodes. There are a few reasons for this. Initially, the start and end nodes might change depending on the situation, or this information may not be available. Furthermore, complete metric data provide details about the structure of the attack graph, which can be used to plan mitigation actions against unknown attack scenarios. In addition, it is straightforward to define metrics for a subset of start nodes and a subset of end nodes similarly to <xref ref-type="disp-formula" rid="e5">Equation 5</xref>.</p>
<p>The out-centrality (<xref ref-type="disp-formula" rid="e1">Equation 1</xref>) and in-centrality (<xref ref-type="disp-formula" rid="e2">Equation 2</xref>) values for the 18 nodes of the Multi-cloud network are shown in <xref ref-type="fig" rid="F3">Figure 3</xref>. The results are shown for the four link weight values <inline-formula id="inf36">
<mml:math id="m41">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.2</mml:mn>
<mml:mo>,</mml:mo>
<mml:mn>0.5</mml:mn>
<mml:mo>,</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, and 1. As the link weights are interpreted as probabilities of successfully exploiting vulnerabilities, lower link weight values correspond to reduced probabilities.</p>
<fig id="F3" position="float">
<label>FIGURE 3</label>
<caption>
<p>Out- and in-centrality values of the Multi-cloud Enterprise Network of 18 nodes in <xref ref-type="fig" rid="F1">Figure 1</xref> from <xref ref-type="disp-formula" rid="e1">Equations 1</xref>, <xref ref-type="disp-formula" rid="e2">2</xref>, respectively. The histograms show the effects of using weighted link values according to the exploitability of vulnerabilities. Link weights are calculated by multiplying the Exploitability values from <xref ref-type="table" rid="T2">Table 2</xref>, which are based on the CVSS score values, with the scaling factors <inline-formula id="inf37">
<mml:math id="m42">
<mml:mrow>
<mml:mi>w</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>.</p>
</caption>
<graphic xlink:href="fcpxs-03-1620260-g003.tif">
<alt-text content-type="machine-generated">Two bar charts compare out-centrality and in-centrality values for nodes one to eighteen. Each chart displays data for weights 0.2, 0.5, 0.8, and 1, with varying heights indicating differences in centrality across nodes. Nodes one and fourteen have the highest out-centrality, while node eighteen shows the highest in-centrality.</alt-text>
</graphic>
</fig>
<p>The out-centrality and in-centrality values depicted in <xref ref-type="fig" rid="F3">Figure 3</xref> illustrate the typical characteristics of directed acyclic networks. Node 1 (Start) has the highest out-centrality, while node 18 (End) has the highest in-centrality. The out-centrality values tend to be more varied than the in-centrality values, as structures near the source nodes and high link weights boost propagation more than structures near target nodes. We also observe that the number of potential alternative paths affects the out-centrality and in-centrality values. Nodes <inline-formula id="inf38">
<mml:math id="m43">
<mml:mrow>
<mml:mn>7,12,14</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, and 15 have high out-centrality values because paths originating from these nodes have many alternatives. Similarly, multiple alternative paths leading to an end node increase its in-centrality value.</p>
<p>When planning, the mitigation actions are optimised based on detailed network modelling and the order of actions can change depending on the exploitability or link weight values of vulnerabilities. Additionally, skilled attackers may utilise longer attack path lengths because their probability of success remains high even with multiple consecutive exploits.</p>
</sec>
<sec id="s5-2">
<title>5.2 Use case 2: Netflix OSS architecture</title>
<p>The second use case is a combination of containers provided by Netflix, consisting of the Spring cloud ecosystem (<xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>). <xref ref-type="table" rid="T3">Table 3</xref> provides descriptions of the 21 nodes in the NetflixOSS attack graph, the topology of which is depicted in <xref ref-type="fig" rid="F4">Figure 4</xref>.</p>
<table-wrap id="T3" position="float">
<label>TABLE 3</label>
<caption>
<p>List of nodes in the NetflixOSS attack graph in <xref ref-type="fig" rid="F4">Figure 4</xref>.</p>
</caption>
<table>
<thead valign="top">
<tr>
<th align="center">Node</th>
<th align="center">Description</th>
<th align="left">Node</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody valign="top">
<tr>
<td align="center">1</td>
<td align="center">Config service (Admin priv)</td>
<td align="left">12</td>
<td align="left">Service b (Admin priv)</td>
</tr>
<tr>
<td align="center">2</td>
<td align="center">Config service (User priv)</td>
<td align="left">13</td>
<td align="left">Service b (User priv)</td>
</tr>
<tr>
<td align="center">3</td>
<td align="center">Eureka (Admin priv)</td>
<td align="left">14</td>
<td align="left">Service c (Admin priv)</td>
</tr>
<tr>
<td align="center">4</td>
<td align="center">Eureka (User priv)</td>
<td align="left">15</td>
<td align="left">Service c (User priv)</td>
</tr>
<tr>
<td align="center">5</td>
<td align="center">Hystrix dashboard (Admin priv)</td>
<td align="left">16</td>
<td align="left">Spring cloud dasboard (Admin priv)</td>
</tr>
<tr>
<td align="center">6</td>
<td align="center">Hystrix dashboard (User priv)</td>
<td align="left">17</td>
<td align="left">Spring cloud dasboard (User priv)</td>
</tr>
<tr>
<td align="center">7</td>
<td align="center">Outside (Admin priv)</td>
<td align="left">18</td>
<td align="left">Turbine (Admin priv)</td>
</tr>
<tr>
<td align="center">8</td>
<td align="center">rabbitmq (Admin priv)</td>
<td align="left">19</td>
<td align="left">Turbine (User priv)</td>
</tr>
<tr>
<td align="center">9</td>
<td align="center">rabbitmq (User priv)</td>
<td align="left">20</td>
<td align="left">Zuul (Admin priv)</td>
</tr>
<tr>
<td align="center">10</td>
<td align="center">Service (Admin priv)</td>
<td align="left">21</td>
<td align="left">Zuul (User priv)</td>
</tr>
<tr>
<td align="center">11</td>
<td align="center">Service (User priv)</td>
<td align="left"/>
<td align="left"/>
</tr>
</tbody>
</table>
</table-wrap>
<fig id="F4" position="float">
<label>FIGURE 4</label>
<caption>
<p>Use Case 2: Attack graph NetflixOSS from (<xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>). Nodes are described in <xref ref-type="table" rid="T3">Table 3</xref>.</p>
</caption>
<graphic xlink:href="fcpxs-03-1620260-g004.tif">
<alt-text content-type="machine-generated">Network diagram displaying interconnected nodes labeled with numbers from one to twenty-one. Each node is connected by arrows labeled with CVE identifiers, indicating relationships or dependencies. Arrows vary in direction, showing complex interconnections between vulnerabilities.</alt-text>
</graphic>
</fig>
<p>In <xref ref-type="fig" rid="F5">Figure 5</xref>, we show the out-centrality and in-centrality values of the NetflixOSS attack graph (<xref ref-type="bibr" rid="B30">Stergiopoulos et al., 2022</xref>) for four link weight values, and they are found to increase monotonically as the link weight increases. However, the growth rate is slow for low link weights, then increases, and finally slows down again with high link weights due to saturation effects. CVSS scoring (<xref ref-type="bibr" rid="B20">Mell et al., 2007</xref>) values are not used in this use case as they have almost equal values in this scenario.</p>
<fig id="F5" position="float">
<label>FIGURE 5</label>
<caption>
<p>Out-centrality and in-centrality values for the 21 nodes of the NetflixOSS example network network in <xref ref-type="fig" rid="F4">Figure 4</xref> for four different link weight values.</p>
</caption>
<graphic xlink:href="fcpxs-03-1620260-g005.tif">
<alt-text content-type="machine-generated">Bar graphs compare out-centrality and in-centrality of nodes numbered one to twenty-one. Each graph shows data for weights of zero point two, zero point five, zero point eight, and one in different colors. Out-centrality peaks at node four, while in-centrality peaks around nodes three and twenty.</alt-text>
</graphic>
</fig>
<p>The out-centrality and in-centrality in <xref ref-type="fig" rid="F5">Figure 5</xref> illustrate the two aspects of the NetflixOSS attack graph. The out-centrality values for the 21 nodes of the graph indicate that nodes <inline-formula id="inf39">
<mml:math id="m44">
<mml:mrow>
<mml:mn>3,4,7,10,11,20</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, and 21 are positioned at the beginning of possible attack chains, while nodes <inline-formula id="inf40">
<mml:math id="m45">
<mml:mrow>
<mml:mn>1,2,5,6,8,9,18</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, and 19 are at the end of the attack chains. The node seven is identified as the start node of the graph as it has a hundred per cent out-centrality value for the link weight values <inline-formula id="inf41">
<mml:math id="m46">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>. Nodes <inline-formula id="inf42">
<mml:math id="m47">
<mml:mrow>
<mml:mn>12,13,14,15,16</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, and 17 are in the intermediary positions within the attack chains, which can be used to prioritise protective actions or mitigate the impacts of the ongoing cyber attacks.</p>
<p>In <xref ref-type="fig" rid="F6">Figure 6</xref>, the average percentage of exploited nodes is shown when a node&#x2019;s vulnerabilities are mitigated. The results are displayed for link weight values <inline-formula id="inf43">
<mml:math id="m48">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.2</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, <inline-formula id="inf44">
<mml:math id="m49">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.5</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, and <inline-formula id="inf45">
<mml:math id="m50">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> when the start node is 7. Here the effects are computed as average effects on other nodes. The dotted lines illustrate the average percentage of exploited nodes when the nodes are not protected. The relationship between the link weights of the nodes and the average effect on the network is not linear. For instance, the link weight of <inline-formula id="inf46">
<mml:math id="m51">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.2</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> results in only about 10 per cent exploitation in the network. Meanwhile, the link weights of <inline-formula id="inf47">
<mml:math id="m52">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.5</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> and <inline-formula id="inf48">
<mml:math id="m53">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> lead to approximately sixty and ninety per cent exploitation levels, respectively.</p>
<fig id="F6" position="float">
<label>FIGURE 6</label>
<caption>
<p>The average percentage values of exploited nodes in the NetflixOSS example network in <xref ref-type="fig" rid="F4">Figure 4</xref> when a node is protected. The effects are calculated as average effects on other nodes. The results are shown for link weight values of <inline-formula id="inf49">
<mml:math id="m54">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.2</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, <inline-formula id="inf50">
<mml:math id="m55">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.5</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, and <inline-formula id="inf51">
<mml:math id="m56">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>. The start node of the attack is 7. The dotted lines show the average percentage of exploited nodes when nodes are not protected.</p>
</caption>
<graphic xlink:href="fcpxs-03-1620260-g006.tif">
<alt-text content-type="machine-generated">Line graph showing percentage of exploited nodes versus protected node numbers. Three lines represent different weights: blue for \( w = 0.8 \), orange for \( w = 0.5 \), and green for \( w = 0.2 \). The blue line hovers around 80-90%, orange fluctuates near 50-60%, and green stays below 10%.</alt-text>
</graphic>
</fig>
<p>A significant decrease in the number of exploited nodes is seen when the vulnerabilities of the nodes <inline-formula id="inf52">
<mml:math id="m57">
<mml:mrow>
<mml:mn>3,4,20</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, and 21 in the graph are mitigated. This is expected because these nodes are at the beginning of potential attack chains starting from node 7. The impact is bigger when the links have higher weights. Nodes that come right after the start node become more important when the link weight values (exploitability) increase.</p>
<p>When it comes to addressing vulnerabilities, it may be more useful to focus on eliminating vulnerabilities related to services rather than just protecting individual nodes in the attack graph. Next, we compare how out-centrality and in-centrality values decrease when vulnerabilities in services are protected. The comparison will be performed by taking the difference between the unprotected and protected results. Next, we calculate out-centrality (<xref ref-type="disp-formula" rid="e1">Equation 1</xref>) and in-centrality (<xref ref-type="disp-formula" rid="e2">Equation 2</xref>) results for all nodes in the attack graph in <xref ref-type="fig" rid="F4">Figure 4</xref>. In these calculations, we assume that the cyber attack starts at node <inline-formula id="inf53">
<mml:math id="m58">
<mml:mrow>
<mml:mi>s</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> in <xref ref-type="disp-formula" rid="e1">Equation 1</xref> or nodes <inline-formula id="inf54">
<mml:math id="m59">
<mml:mrow>
<mml:mi>t</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> in <xref ref-type="disp-formula" rid="e2">Equation 2</xref> with certainty. If the attack starts from the first node in the attack graph in <xref ref-type="fig" rid="F4">Figure 4</xref>, then the relevant results focus solely on node 7.</p>
<p>
<xref ref-type="fig" rid="F7">Figure 7</xref> shows these differences (i.e., decrease) for nodes <inline-formula id="inf55">
<mml:math id="m60">
<mml:mrow>
<mml:mn>1</mml:mn>
<mml:mo>&#x2212;</mml:mo>
<mml:mn>21</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> after mitigating all the vulnerabilities in the services indicated in the legend. For this example, the link weight is <inline-formula id="inf56">
<mml:math id="m61">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> to represent a skilled perpetrator. Looking at the out-centrality histogram in <xref ref-type="fig" rid="F7">Figure 7</xref>, we observe that 4&#xa0;bars stand out: Zuul and Eureka services have decreased by 95% and 85% for the out-centrality of node 7, and Eureka services also show a significant decrease for the out-centrality values of node 20 (by 85%) and for node 21 (by 88%).</p>
<fig id="F7" position="float">
<label>FIGURE 7</label>
<caption>
<p>Out-centrality and in-centrality differences (i.e., decrease) for nodes 1 to 21 in <xref ref-type="fig" rid="F4">Figure 4</xref> after mitigating vulnerabilities in services indicated in the legend (link weight <inline-formula id="inf57">
<mml:math id="m62">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>).</p>
</caption>
<graphic xlink:href="fcpxs-03-1620260-g007.tif">
<alt-text content-type="machine-generated">Bar charts comparing out-centrality and in-centrality decrease (w=0.8) for nodes 1 to 21. The top chart shows out-centrality, while the bottom shows in-centrality. Nodes and services are color-coded, including Zuul, Eureka, ServiceA, Service, ServiceC, SpringCloud, Turbine, HystrixDashboard, ConfigService, and Rabbitmq. Data ranges on the vertical axis show percentage decreases up to 100%.</alt-text>
</graphic>
</fig>
<p>The in-centrality values shown in <xref ref-type="fig" rid="F7">Figure 7</xref> indicate that protecting services at the nodes leads to a decrease in the in-centrality values of these particular nodes. For example, Turbine services have a significant impact on nodes 18 and 19. Furthermore, protecting Turbine services results in a substantial decrease in the in-centrality values of nodes 5 and 6. These effects result from nodes 18 and 19 denoting Turbine services states (see <xref ref-type="table" rid="T3">Table 3</xref>), while nodes 5 and 6 represent subsequent Hystrix dashboard states in the attack graph (<xref ref-type="fig" rid="F4">Figure 4</xref>). On the other hand, protecting services at the beginning of attack chains, such as Zuul and Eureka services, affects the in-centrality values of nodes 3 and 4. Services exploited later in the attack chains have no effect on these nodes.</p>
<p>
<xref ref-type="fig" rid="F8">Figure 8a</xref> illustrates the decrease of the in-centrality values from the start node seven to other nodes in the graph for the link weight of <inline-formula id="inf58">
<mml:math id="m63">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> after mitigating a vulnerability indicated on the horizontal axis. In the model (see <xref ref-type="sec" rid="s3">Section 3</xref>) these correspond to a decrease in the matrix element values <inline-formula id="inf59">
<mml:math id="m64">
<mml:mrow>
<mml:mi>C</mml:mi>
<mml:mrow>
<mml:mo stretchy="false">(</mml:mo>
<mml:mrow>
<mml:mi>s</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>t</mml:mi>
</mml:mrow>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:math>
</inline-formula>, for <inline-formula id="inf60">
<mml:math id="m65">
<mml:mrow>
<mml:mi>s</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>7</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> and <inline-formula id="inf61">
<mml:math id="m66">
<mml:mrow>
<mml:mi>t</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>1,2,3,4,5,6,8</mml:mn>
<mml:mo>,</mml:mo>
<mml:mo>&#x2026;</mml:mo>
<mml:mo>,</mml:mo>
<mml:mi>N</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula>. By mitigating the vulnerabilities CVE-2017-7376 and CVE-2017-13,090, a significant decrease in the in-centrality values for several nodes can be achieved. Results at the node level indicate that CVE-2017-7376 significantly affects the in-centralities of nodes <inline-formula id="inf62">
<mml:math id="m67">
<mml:mrow>
<mml:mn>1,2,4,11,13,17</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, and 21, with smaller effects on the other nodes. On the other hand, the vulnerability CVE-2017&#x2013;13,090 has a major impact on nodes 14 and 18, but with minor effects on the other nodes.</p>
<fig id="F8" position="float">
<label>FIGURE 8</label>
<caption>
<p>
<bold>(a)</bold> Probability differences (decrease) of the in-centralities from the attack start node seven to other nodes (link weight <inline-formula id="inf63">
<mml:math id="m68">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>) after mitigating a vulnerability from the network. Vulnerabilities are indicated on the horizontal axis. <bold>(b)</bold> Probability differences (decrease) of the in-centralities from the attack start node seven to other nodes (link weight <inline-formula id="inf64">
<mml:math id="m69">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>) after removing all vulnerabilities from a server. Servers are indicated on the horizontal axis. Summaries generated from the model <bold>(a)</bold> when the entire network is protected against a single vulnerability or <bold>(b)</bold> a server is protected against all its vulnerabilities.</p>
</caption>
<graphic xlink:href="fcpxs-03-1620260-g008.tif">
<alt-text content-type="machine-generated">Two bar charts show data labeled &#x22;Decrease from Node 7 to Other Nodes&#x22; with weights of 0.8. Chart (a) displays data for various CVEs, and chart (b) shows services like Zuul, Eureka, and Rabbitmq. Each bar represents different nodes, numbered from 1 to 21, with varying heights indicating decrease levels.</alt-text>
</graphic>
</fig>
<p>
<xref ref-type="fig" rid="F8">Figure 8b</xref> illustrates the decrease in the in-centrality values from the start node seven to other nodes in the graph for the link weight of <inline-formula id="inf65">
<mml:math id="m70">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> after mitigating vulnerabilities in the services indicated on the horizontal axis. Zuul and Eureka are the most effective services to be protected, as they are at the beginning of attack chains. In <xref ref-type="fig" rid="F9">Figure 9a</xref> we show the summary of the decrease in the average out-centrality from the start node seven to other nodes for the link weight <inline-formula id="inf66">
<mml:math id="m71">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> after mitigating the vulnerabilities. The four most important vulnerabilities in this order are CVE-2017-7376, CVE-2017-13,090, CVE-2017-1000116, and CVE-2005-2541. <xref ref-type="fig" rid="F9">Figure 9b</xref> shows the corresponding results for the services. The most important services are Zuul and Eureka as we have already seen in <xref ref-type="fig" rid="F8">Figure 8b</xref>.</p>
<fig id="F9" position="float">
<label>FIGURE 9</label>
<caption>
<p>
<bold>(a)</bold> A specific vulnerability removed from the attack graph indicated on the legend (Summary from <xref ref-type="fig" rid="F8">Figure 8a</xref>). <bold>(b)</bold> Vulnerabilities removed from specific servers/services indicated on legend (Summary from <xref ref-type="fig" rid="F8">Figure 8b</xref>). Relative effects after removing a vulnerability from the network or all vulnerabilities from a server. As an example, the results are shown for the link weight value <inline-formula id="inf67">
<mml:math id="m72">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>.</p>
</caption>
<graphic xlink:href="fcpxs-03-1620260-g009.tif">
<alt-text content-type="machine-generated">Two pie charts compare cybersecurity aspects. Chart (a) shows the distribution of different CVEs affecting vulnerability mitigation, with CVE-2017-7376 making up the largest portion. Chart (b) illustrates the distribution of protection services with Zuul being the largest segment, followed by Eureka and ConfigService.</alt-text>
</graphic>
</fig>
</sec>
<sec id="s5-3">
<title>5.3 Use case 3: Pony APT campaign</title>
<p>The third use case involves a causal graph generated in (<xref ref-type="bibr" rid="B3">Alsaheel et al., 2021</xref>) using an attack investigation tool. This tool integrates natural language processing and deep learning techniques into data analysis to model sequence-based attack and non-attack entities.</p>
<p>
<xref ref-type="fig" rid="F10">Figure 10</xref> depicts attack and non-attack entities detected by the ATLAS investigation tool (<xref ref-type="bibr" rid="B3">Alsaheel et al., 2021</xref>). The original attack entities are indicated by the red colour and the original non-attack entities by the green colour (<xref ref-type="bibr" rid="B3">Alsaheel et al., 2021</xref>). The blue line shows the extended set of attack nodes reachable from start nodes eight or nine by following all alternative paths in the graph. The red line shows the minimum set of nodes restricted to the original set of attack nodes.</p>
<fig id="F10" position="float">
<label>FIGURE 10</label>
<caption>
<p>Use Case 3: Attack entities are identified based on the connections within the graph structure. The original attack entities are highlighted in red, while the original non-attacks are marked in green. The blue line represents the extended set of attack nodes detected by our network modelling method, whereas the red line indicates the minimum set of reachable nodes confined to the original set of attack nodes. The list of nodes is provided in the table from (<xref ref-type="bibr" rid="B3">Alsaheel et al., 2021</xref>).</p>
</caption>
<graphic xlink:href="fcpxs-03-1620260-g010.tif">
<alt-text content-type="machine-generated">Network diagram illustrating interactions between nodes, numbered 1 to 39, connected by arrows representing different actions like &#x22;request,&#x22; &#x22;bind,&#x22; &#x22;send,&#x22; etc. Nodes are color-coded in green and red. The diagram is enclosed by a red and blue boundary. A table below lists entities corresponding to node numbers, detailing filenames and IP addresses.</alt-text>
</graphic>
</fig>
<p>In <xref ref-type="fig" rid="F11">Figure 11</xref> we show the out- and in-centrality values for the 39 nodes of the ATLAS causal graph for four different link weight values. The histograms in <xref ref-type="fig" rid="F11">Figure 11</xref> are similar to those in <xref ref-type="fig" rid="F5">Figure 5</xref>, but there are some differences. When comparing the ATLAS and NetflixOSS graphs, we can observe that the out-centrality and in-centrality values for the ATLAS causal graph for low link weight values are much smaller. Additionally, the centrality values for higher link weight values are roughly half of the Netflix results. These differences are attributed to the higher density and higher mean node degree of the NetflixOSS graph compared to the ATLAS graph.</p>
<fig id="F11" position="float">
<label>FIGURE 11</label>
<caption>
<p>Out-centrality and in-centrality values for the 39 nodes of the ATLAS causal graph in <xref ref-type="fig" rid="F10">Figure 10</xref> for four different link weight values.</p>
</caption>
<graphic xlink:href="fcpxs-03-1620260-g011.tif">
<alt-text content-type="machine-generated">Bar charts showing out-centrality and in-centrality for nodes 1 to 39 with weights of 0.2, 0.5, 0.8, and 1. The out-centrality chart highlights high values for nodes 3, 8, and 36, while the in-centrality chart shows peaks for nodes 8, 9, 28, 36, and 37. Different bar colors represent various weights.</alt-text>
</graphic>
</fig>
<p>
<xref ref-type="fig" rid="F12">Figure 12</xref> illustrates the percentage of exploited nodes in the ATLAS causal graph when one of the 39 nodes is protected. The results are presented for three link weight values: <inline-formula id="inf68">
<mml:math id="m73">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.2</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, <inline-formula id="inf69">
<mml:math id="m74">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.5</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, and <inline-formula id="inf70">
<mml:math id="m75">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>. The start node is node eight or node 9. The effects are calculated as average values on the other nodes. The dotted lines represent the average percentage of the exploited nodes when no nodes are protected. Compared to <xref ref-type="fig" rid="F6">Figure 6</xref> results, we observe more fluctuations but with smaller amplitude. Mitigating vulnerabilities in the nodes 1, 2, 16, 15, 34 or 12 has the largest effects of protecting against the attack. Similarly to the case of <xref ref-type="fig" rid="F11">Figure 11</xref>, the lower density causes the curves to be lower compared to those of <xref ref-type="fig" rid="F6">Figure 6</xref>, and the ratios between the curves turn out to be different.</p>
<fig id="F12" position="float">
<label>FIGURE 12</label>
<caption>
<p>The average percentage values of exploited nodes in the ATLAS causal graph in <xref ref-type="fig" rid="F10">Figure 10</xref> when a node is protected. The effects are calculated as average effects on other nodes. The results are shown for the link weight values <inline-formula id="inf71">
<mml:math id="m76">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.2</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, <inline-formula id="inf72">
<mml:math id="m77">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.5</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, and <inline-formula id="inf73">
<mml:math id="m78">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>. The start node is 8 or 9. The dotted lines show the average percentage values of exploited nodes when nodes are not protected. In the table, nodes are ordered according to their criticality for <inline-formula id="inf74">
<mml:math id="m79">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> (blue curve).</p>
</caption>
<graphic xlink:href="fcpxs-03-1620260-g012.tif">
<alt-text content-type="machine-generated">Line graph showing the percentage of exploited nodes based on protected nodes from 1 to 39, with starting node 8. Three lines represent w values: w=0.8 (blue), w=0.5 (orange), and w=0.2 (green). The blue line consistently stays around 50-60%, the orange line around 10-20%, and the green line near 0%. A table below lists node numbers with corresponding percentages for each w value.</alt-text>
</graphic>
</fig>
<p>Use case 3 illustrates how our model can analyse incomplete graph information. The original attack graph produced by the investigation tool (<xref ref-type="bibr" rid="B3">Alsaheel et al., 2021</xref>) is indicated by the red line in <xref ref-type="fig" rid="F10">Figure 10</xref>. However, more nodes can be accessed from starting nodes eight or 9. Consequently, the original attack graph can be extended by including these additional nodes, some of which have been classified as non-attack nodes (in green) by the investigation tool. This enlarged attack graph is shown by the blue line in <xref ref-type="fig" rid="F10">Figure 10</xref>. Certain nodes remain outside of this node set, with five identified as attack nodes (in red). This suggests that the actual attack graph could even be larger, and it is important to also consider these outlying nodes of <xref ref-type="fig" rid="F10">Figure 10</xref>.</p>
<p>
<xref ref-type="fig" rid="F10">Figure 10</xref> also presents a table that lists the nodes together with their effects when protected. As an example, the link weight value of <inline-formula id="inf75">
<mml:math id="m80">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula> is used for all links in the graph. When an attack starts from node eight or 9, the average percentage of exploited nodes in the graph is <inline-formula id="inf76">
<mml:math id="m81">
<mml:mrow>
<mml:mn>35.6</mml:mn>
<mml:mi>%</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> when no nodes are protected. When node one is protected, <inline-formula id="inf77">
<mml:math id="m82">
<mml:mrow>
<mml:mn>0.0</mml:mn>
<mml:mi>%</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> of the nodes are exploited, and when node two is protected, <inline-formula id="inf78">
<mml:math id="m83">
<mml:mrow>
<mml:mn>2.1</mml:mn>
<mml:mi>%</mml:mi>
</mml:mrow>
</mml:math>
</inline-formula> are exploited. This outcome is attributed to the critical positions of these nodes within the graph structure. In the table of <xref ref-type="fig" rid="F10">Figure 10</xref>, the tool&#x2019;s classified attack nodes are indicated in red, non-attack nodes in blue, and non-reachable nodes (both attack and non-attack) in black. When prioritising mitigation measures, nodes 22 and 15 have significant effects on the extended graph, although they have not been recognised as attack nodes by the investigative tool.</p>
<p>In contrast to the networks in use cases 1 and 2, the ATLAS causal graph (<xref ref-type="fig" rid="F10">Figure 10</xref>) has a loop between the nodes <inline-formula id="inf79">
<mml:math id="m84">
<mml:mrow>
<mml:mn>15,22</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, and 24, and bidirectional links between the nodes 10 and 11, and between the nodes 30 and 31. In our model, we assume that due to a loop and bi-directionality, circular and recurrent effects are possible. <xref ref-type="fig" rid="F13">Figure 13</xref> illustrates the circular effects in the ATLAS causal graph for three different link weight values. The histogram shows a difference between two situations, namely, one with circular effects and the other with only self-avoiding paths in the network structure. The effects vary according to the weight values of the links. They are low when the link weights are <inline-formula id="inf80">
<mml:math id="m85">
<mml:mrow>
<mml:mi>w</mml:mi>
<mml:mo>&#x3d;</mml:mo>
<mml:mn>0.2</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, peak at higher link weights, and gradually slow down due to saturation effects for high link weight values.</p>
<fig id="F13" position="float">
<label>FIGURE 13</label>
<caption>
<p>Circular Effects in the ATLAS causal graph of <xref ref-type="fig" rid="F10">Figure 10</xref> for three different link weight values. The bars in the histograms show differences between two calculations: full breakthrough propagation and self-avoiding paths between nodes.</p>
</caption>
<graphic xlink:href="fcpxs-03-1620260-g013.tif">
<alt-text content-type="machine-generated">Two bar charts display centrality analysis for an atlas, highlighting circular effects. The top chart shows out-centrality, and the bottom one shows in-centrality. Nodes are represented on the x-axis, while percentages are on the y-axis. Colors indicate weights: yellow for 0.2, green for 0.5, and blue for 0.8. Peaks in both charts occur at different nodes, emphasizing varying centralities.</alt-text>
</graphic>
</fig>
<p>To summarise, it turns out that for the attack graph with one loop and two bidirectional links, the out-centrality values are increased. Furthermore, nodes <inline-formula id="inf81">
<mml:math id="m86">
<mml:mrow>
<mml:mn>1,2,8</mml:mn>
</mml:mrow>
</mml:math>
</inline-formula>, and 9 have increasing out-centrality values because they are at the beginning of attack paths that can reach the loop nodes 15, 22 or 24. Upon examining the graph in <xref ref-type="fig" rid="F12">Figure 12</xref>, we conclude that the in-centrality values of nodes 5, 7, 10, 11, 12, 13, and 23 have increased due to the circular effects of the loop, and the in-centrality values of nodes 28, 29 and 33 have increased due to the recurrent effects between nodes 30 and 31 by the two bidirectional links.</p>
</sec>
</sec>
<sec id="s6">
<title>6 Concluding remarks</title>
<p>In cybersecurity analysis of computer networks and service systems, it is natural to take a graph-based approach. Until recently, cyber-related graphs, such as attack graphs, have been created manually or generated by scanning network configurations to identify vulnerabilities and compute potential attack paths. In this case, the analysis of an attack graph involves examining individual paths that an attacker could take and evaluating the risk associated with each path.</p>
<p>In the present study, we have introduced a novel probabilistic graph-based analysis approach to investigate the structural and dynamic properties of the attack and causal graphs. This approach has previously been used in our research to model the spread of influence in complex networks. Here, we are applying this methodology for the first time to analyse the propagation of attacks and causal influences. In this context, out-centrality and in-centrality measures are used to identify critical nodes in the graph. The documented exploitability values of vulnerabilities mimic the probability of propagation of attacks or causal influences on possible paths or sequences of actions that an attacker or influencer can follow to achieve a particular objective, such as compromising a critical asset in a network. Similarly, the documented impact values of vulnerabilities are used to demonstrate the model in analysing cumulative and individual impacts of attacks.</p>
<p>Future research could focus on multilayer modelling of enterprise infrastructure and attack graphs. Additional areas of interest could include the integration of real-time attack graph generation and the exploration of hybrid approaches that combine machine learning or anomaly detection methods. Recently, there has emerged a variety of studies on AI-driven techniques in cybersecurity (<xref ref-type="bibr" rid="B25">Salem et al., 2024</xref>) and intrusion detection (<xref ref-type="bibr" rid="B34">Por et al., 2024</xref>). These approaches offer new opportunities to be integrated with the probabilistic methods discussed in this study.</p>
<p>In summary, we have developed a new method for analysing alternative paths within an attack graph and calculating their combined exploitability and impact. This approach differs from the previous methods since our approach offers a probabilistic framework to assess the combined effects of the entire attack graph, rather than focusing solely on the maximum or minimum scenarios. We have applied our model by presenting results related to functional services based on identified vulnerabilities. Additionally, this method can be extended to analyse multiple attack graphs simultaneously in a network structure. For higher levels of abstraction and summaries, it is essential to consistently aggregate alternative attack or causal effect paths within the model. This integrated perspective improves understanding of the situation and helps prioritise mitigation efforts. Thus, our model could be a versatile tool in the hands of cyber analysts.</p>
</sec>
</body>
<back>
<sec sec-type="data-availability" id="s7">
<title>Data availability statement</title>
<p>The original contributions presented in the study are included in the article/<xref ref-type="sec" rid="s13">Supplementary Material</xref>, further inquiries can be directed to the corresponding author.</p>
</sec>
<sec sec-type="author-contributions" id="s8">
<title>Author contributions</title>
<p>VK: Methodology, Visualization, Conceptualization, Validation, Writing &#x2013; original draft, Writing &#x2013; review and editing, Formal Analysis, Software. LP: Writing &#x2013; review and editing, Writing &#x2013; original draft. TT: Project administration, Writing &#x2013; review and editing, Writing &#x2013; original draft. KK: Funding acquisition, Writing &#x2013; original draft, Supervision, Writing &#x2013; review and editing.</p>
</sec>
<sec sec-type="funding-information" id="s9">
<title>Funding</title>
<p>The author(s) declare that no financial support was received for the research and/or publication of this article.</p>
</sec>
<sec sec-type="COI-statement" id="s10">
<title>Conflict of interest</title>
<p>The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.</p>
</sec>
<sec sec-type="ai-statement" id="s11">
<title>Generative AI statement</title>
<p>The author(s) declare that no Generative AI was used in the creation of this manuscript.</p>
<p>Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.</p>
</sec>
<sec sec-type="disclaimer" id="s12">
<title>Publisher&#x2019;s note</title>
<p>All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.</p>
</sec>
<sec sec-type="supplementary-material" id="s13">
<title>Supplementary material</title>
<p>The Supplementary Material for this article can be found online at: <ext-link ext-link-type="uri" xlink:href="https://www.frontiersin.org/articles/10.3389/fcpxs.2025.1620260/full#supplementary-material">https://www.frontiersin.org/articles/10.3389/fcpxs.2025.1620260/full&#x23;supplementary-material</ext-link>
</p>
<supplementary-material xlink:href="DataSheet1.pdf" id="SM1" mimetype="application/pdf" xmlns:xlink="http://www.w3.org/1999/xlink"/>
</sec>
<ref-list>
<title>References</title>
<ref id="B1">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Aksu</surname>
<given-names>M. U.</given-names>
</name>
<name>
<surname>Bicakci</surname>
<given-names>K.</given-names>
</name>
<name>
<surname>Dilek</surname>
<given-names>M. H.</given-names>
</name>
<name>
<surname>Ozbayoglu</surname>
<given-names>A. M.</given-names>
</name>
<name>
<surname>Tatli</surname>
<given-names>E. &#x131;.</given-names>
</name>
</person-group> (<year>2018</year>). <article-title>Automated generation of attack graphs using NVD</article-title>. <source>Proc. Eighth ACM Conf. Data Appl. Secur. Priv.</source>, <fpage>135</fpage>&#x2013;<lpage>142</lpage>. <pub-id pub-id-type="doi">10.1145/3176258.3176339</pub-id>
</citation>
</ref>
<ref id="B2">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Almiala</surname>
<given-names>I.</given-names>
</name>
<name>
<surname>Aalto</surname>
<given-names>H.</given-names>
</name>
<name>
<surname>Kuikka</surname>
<given-names>V.</given-names>
</name>
</person-group> (<year>2023</year>). <article-title>Influence spreading model for partial breakthrough effects on complex networks</article-title>. <source>Phys. A Stat. Mech. its Appl.</source> <volume>630</volume>, <fpage>129244</fpage>. <pub-id pub-id-type="doi">10.1016/j.physa.2023.129244</pub-id>
</citation>
</ref>
<ref id="B3">
<citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname>Alsaheel</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Nan</surname>
<given-names>Y.</given-names>
</name>
<name>
<surname>Ma</surname>
<given-names>S.</given-names>
</name>
<name>
<surname>Yu</surname>
<given-names>L.</given-names>
</name>
<name>
<surname>Walkup</surname>
<given-names>G.</given-names>
</name>
<name>
<surname>Celik</surname>
<given-names>Z. B.</given-names>
</name>
<etal/>
</person-group> (<year>2021</year>). &#x201c;<article-title>{Atlas}: a sequence-based learning approach for attack investigation</article-title>,&#x201d; in <source>30th USENIX security symposium (USENIX security 21)</source>, <fpage>3005</fpage>&#x2013;<lpage>3022</lpage>. <comment>Available online at: <ext-link ext-link-type="uri" xlink:href="https://www.usenix.org/conference/usenixsecurity21/presentation/alsaheel">https://www.usenix.org/conference/usenixsecurity21/presentation/alsaheel</ext-link>.</comment>
</citation>
</ref>
<ref id="B4">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Alserhani</surname>
<given-names>F. M.</given-names>
</name>
</person-group> (<year>2015</year>). <article-title>Knowledge-based model to represent security information and reason about multi-stage attacks</article-title>. <source>Lect. Notes Bus. Inf. Process.</source> <volume>27</volume>, <fpage>482</fpage>&#x2013;<lpage>494</lpage>. <pub-id pub-id-type="doi">10.1007/978-3-319-19243-7_44</pub-id>
</citation>
</ref>
<ref id="B5">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Carter</surname>
<given-names>K. M.</given-names>
</name>
<name>
<surname>Idika</surname>
<given-names>N.</given-names>
</name>
<name>
<surname>Streilein</surname>
<given-names>W. W.</given-names>
</name>
</person-group> (<year>2014</year>). <article-title>Probabilistic threat propagation for network security</article-title>. <source>IEEE Trans. Inf. forensics Secur.</source> <volume>9</volume> (<issue>9</issue>), <fpage>1394</fpage>&#x2013;<lpage>1405</lpage>. <pub-id pub-id-type="doi">10.1109/TIFS.2014.2334272</pub-id>
</citation>
</ref>
<ref id="B6">
<citation citation-type="web">
<collab>FIRST</collab> (<year>2025</year>). <article-title>Common vulnerability scoring system sig (forum of incident response and security teams)</article-title>. <comment>Available online at: <ext-link ext-link-type="uri" xlink:href="https://www.first.org/cvss/">https://www.first.org/cvss/</ext-link>.</comment>
</citation>
</ref>
<ref id="B7">
<citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname>Haque</surname>
<given-names>M. A.</given-names>
</name>
<name>
<surname>Shetty</surname>
<given-names>S.</given-names>
</name>
<name>
<surname>Gold</surname>
<given-names>K.</given-names>
</name>
<name>
<surname>Krishnappa</surname>
<given-names>B.</given-names>
</name>
</person-group> (<year>2021</year>). &#x201c;<article-title>Realizing cyber-physical systems resilience frameworks and security practices</article-title>,&#x201d; in <source>Security in cyber-physical systems: foundations and applications</source>, <fpage>1</fpage>&#x2013;<lpage>37</lpage>. <pub-id pub-id-type="doi">10.1007/978-3-030-67361-1_1</pub-id>
</citation>
</ref>
<ref id="B8">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Homer</surname>
<given-names>J.</given-names>
</name>
<name>
<surname>Zhang</surname>
<given-names>S.</given-names>
</name>
<name>
<surname>Ou</surname>
<given-names>X.</given-names>
</name>
<name>
<surname>Schmidt</surname>
<given-names>D.</given-names>
</name>
<name>
<surname>Du</surname>
<given-names>Y.</given-names>
</name>
<name>
<surname>Rajagopalan</surname>
<given-names>S. R.</given-names>
</name>
<etal/>
</person-group> (<year>2013</year>). <article-title>Aggregating vulnerability metrics in enterprise networks using attack graphs</article-title>. <source>J. Comput. Secur.</source> <volume>21</volume> (<issue>4</issue>), <fpage>561</fpage>&#x2013;<lpage>597</lpage>. <pub-id pub-id-type="doi">10.3233/JCS-130475</pub-id>
</citation>
</ref>
<ref id="B9">
<citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname>Hutchins</surname>
<given-names>E. M.</given-names>
</name>
<name>
<surname>Cloppert</surname>
<given-names>M. J.</given-names>
</name>
<name>
<surname>Amin</surname>
<given-names>R. M.</given-names>
</name>
</person-group>(<year>2011</year>). &#x201c;<article-title>Intelligence-driven computer network defense informed by analysis of adversary campaigns and intrusion kill chains</article-title>,&#x201d; in <source>Proceedings of the 6th international conference on information warfare and security (ICIW 2011)</source>. <publisher-loc>Washington, DC</publisher-loc>: <publisher-name>Academic conferences and publishing international limited</publisher-name>. <comment>Available online at: <ext-link ext-link-type="uri" xlink:href="https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/LM-White-Paper-Intel-Driven-Defense.pdf">https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/LM-White-Paper-Intel-Driven-Defense.pdf</ext-link>
</comment>
</citation>
</ref>
<ref id="B10">
<citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname>Ibrahim</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Bozhinoski</surname>
<given-names>S.</given-names>
</name>
<name>
<surname>Pretschner</surname>
<given-names>A.</given-names>
</name>
</person-group> (<year>2019</year>). &#x201c;<article-title>Attack graph generation for microservice architecture</article-title>,&#x201d; in <source>Proceedings of the 34th ACM/SIGAPP symposium on applied computing</source>, <fpage>1235</fpage>&#x2013;<lpage>1242</lpage>. <pub-id pub-id-type="doi">10.1145/3297280.3297401</pub-id>
</citation>
</ref>
<ref id="B11">
<citation citation-type="web">
<person-group person-group-type="author">
<name>
<surname>Jiang</surname>
<given-names>G.</given-names>
</name>
<name>
<surname>Mohandas</surname>
<given-names>R.</given-names>
</name>
<name>
<surname>Leathery</surname>
<given-names>J.</given-names>
</name>
<name>
<surname>Berry</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Galang</surname>
<given-names>L.</given-names>
</name>
</person-group> (<year>2017</year>). <article-title>CVE-2017-0199: in the Wild attacks leveraging HTA handler &#x2014; mandiant</article-title>. <comment>Available online at: <ext-link ext-link-type="uri" xlink:href="https://cloud.google.com/blog/topics/threat-intelligence/cve-2017-0199-hta-handler/">https://cloud.google.com/blog/topics/threat-intelligence/cve-2017-0199-hta-handler/</ext-link>.</comment>
</citation>
</ref>
<ref id="B12">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Kordy</surname>
<given-names>B.</given-names>
</name>
<name>
<surname>Pi&#xe8;tre-Cambac&#xe9;d&#xe8;s</surname>
<given-names>L.</given-names>
</name>
<name>
<surname>Schweitzer</surname>
<given-names>P.</given-names>
</name>
</person-group> (<year>2014</year>). <article-title>Dag-based attack and defense modeling: don&#x2019;t miss the forest for the attack trees</article-title>. <source>Comput. Sci. Rev.</source> <volume>13-14</volume>, <fpage>1</fpage>&#x2013;<lpage>38</lpage>. <pub-id pub-id-type="doi">10.1016/j.cosrev.2014.07.001</pub-id>
</citation>
</ref>
<ref id="B13">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Kuikka</surname>
<given-names>V.</given-names>
</name>
<name>
<surname>Kaski</surname>
<given-names>K. K.</given-names>
</name>
</person-group> (<year>2024</year>). <article-title>Detailed-level modelling of influence spreading on complex networks</article-title>. <source>Sci. Rep.</source> <volume>14</volume> (<issue>28069</issue>), <fpage>28069</fpage>. <pub-id pub-id-type="doi">10.1038/s41598-024-79182-9</pub-id>
<pub-id pub-id-type="pmid">39543173</pub-id>
</citation>
</ref>
<ref id="B14">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Kuikka</surname>
<given-names>V.</given-names>
</name>
<name>
<surname>Aalto</surname>
<given-names>H.</given-names>
</name>
<name>
<surname>Ij&#xe4;s</surname>
<given-names>M.</given-names>
</name>
<name>
<surname>Kaski</surname>
<given-names>K. K.</given-names>
</name>
</person-group> (<year>2022</year>). <article-title>Efficiency of algorithms for computing influence and information spreading on social networks</article-title>. <source>Algorithms</source> <volume>15</volume> (<issue>8</issue>), <fpage>262</fpage>. <pub-id pub-id-type="doi">10.3390/a15080262</pub-id>
</citation>
</ref>
<ref id="B15">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Lallie</surname>
<given-names>H. S.</given-names>
</name>
<name>
<surname>Debattista</surname>
<given-names>K.</given-names>
</name>
<name>
<surname>Bal</surname>
<given-names>J.</given-names>
</name>
</person-group> (<year>2020</year>). <article-title>A review of attack graph and attack tree visual syntax in cyber security</article-title>. <source>Comput. Sci. Rev.</source> <volume>35</volume>, <fpage>100219</fpage>. <pub-id pub-id-type="doi">10.1016/j.cosrev.2019.100219</pub-id>
</citation>
</ref>
<ref id="B16">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Landherr</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Friedl</surname>
<given-names>B.</given-names>
</name>
<name>
<surname>Heidemann</surname>
<given-names>J.</given-names>
</name>
</person-group> (<year>2010</year>). <article-title>A critical review of centrality measures in social networks</article-title>. <source>Bus. and Inf. Syst. Eng.</source> <volume>2</volume> (<issue>6</issue>), <fpage>371</fpage>&#x2013;<lpage>385</lpage>. <pub-id pub-id-type="doi">10.1007/s12599-010-0127-3</pub-id>
</citation>
</ref>
<ref id="B17">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Levner</surname>
<given-names>E.</given-names>
</name>
<name>
<surname>Tsadikovich</surname>
<given-names>D.</given-names>
</name>
</person-group> (<year>2024</year>). <article-title>Fast algorithm for cyber-attack estimation and attack path extraction using attack graphs with and/or nodes</article-title>. <source>Algorithms</source> <volume>17</volume> (<issue>11</issue>), <fpage>504</fpage>. <pub-id pub-id-type="doi">10.3390/a17110504</pub-id>
</citation>
</ref>
<ref id="B18">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Li</surname>
<given-names>Y.</given-names>
</name>
<name>
<surname>Liu</surname>
<given-names>Q.</given-names>
</name>
</person-group> (<year>2021</year>). <article-title>A comprehensive review study of cyber-attacks and cyber security; emerging trends and recent developments</article-title>. <source>Energy Rep.</source> <volume>7</volume>, <fpage>8176</fpage>&#x2013;<lpage>8186</lpage>. <pub-id pub-id-type="doi">10.1016/j.egyr.2021.08.126</pub-id>
</citation>
</ref>
<ref id="B19">
<citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname>Liu</surname>
<given-names>C.</given-names>
</name>
<name>
<surname>Singhal</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Wijesekera</surname>
<given-names>D.</given-names>
</name>
</person-group> (<year>2012</year>). &#x201c;<article-title>Using attack graphs in forensic examinations</article-title>,&#x201d; in <source>2012 seventh international conference on availability, reliability and security</source>, <fpage>596</fpage>&#x2013;<lpage>603</lpage>. <pub-id pub-id-type="doi">10.1109/ARES.2012.58</pub-id>
</citation>
</ref>
<ref id="B20">
<citation citation-type="web">
<person-group person-group-type="author">
<name>
<surname>Mell</surname>
<given-names>P.</given-names>
</name>
<name>
<surname>Scarfone</surname>
<given-names>K.</given-names>
</name>
<name>
<surname>Romanosky</surname>
<given-names>S.</given-names>
</name>
</person-group> (<year>2007</year>). <article-title>A complete guide to the common vulnerability scoring system version 2.0</article-title>. <comment>Available online at: <ext-link ext-link-type="uri" xlink:href="https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=51198">https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id&#x3d;51198</ext-link>.</comment>
</citation>
</ref>
<ref id="B21">
<citation citation-type="journal">
<collab>NIST</collab> (<year>2012</year>). <article-title>Nist sp 800-30: guide for conducting risk assessments (joint task force transformation initiative working group and others)</article-title>. <pub-id pub-id-type="doi">10.6028/NIST.SP.800-30r1</pub-id>
</citation>
</ref>
<ref id="B22">
<citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname>Noel</surname>
<given-names>S.</given-names>
</name>
<name>
<surname>Jajodia</surname>
<given-names>S.</given-names>
</name>
</person-group> (<year>2017</year>). &#x201c;<article-title>A suite of metrics for network attack graph analytics</article-title>,&#x201d; in <source>Network security metrics</source> (<publisher-name>Springer International Publishing</publisher-name>), <fpage>141</fpage>&#x2013;<lpage>176</lpage>. <pub-id pub-id-type="doi">10.1007/978-3-319-66505-4_7</pub-id>
</citation>
</ref>
<ref id="B23">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Pendleton</surname>
<given-names>M.</given-names>
</name>
<name>
<surname>Garcia-Lebron</surname>
<given-names>R.</given-names>
</name>
<name>
<surname>Cho</surname>
<given-names>J.-H.</given-names>
</name>
<name>
<surname>Xu</surname>
<given-names>S.</given-names>
</name>
</person-group> (<year>2016</year>). <article-title>A survey on systems security metrics</article-title>. <source>ACM Comput. Surv. (CSUR)</source> <volume>49</volume> (<issue>4</issue>), <fpage>1</fpage>&#x2013;<lpage>35</lpage>. <pub-id pub-id-type="doi">10.1145/3005714</pub-id>
</citation>
</ref>
<ref id="B24">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Qi</surname>
<given-names>Y.</given-names>
</name>
<name>
<surname>Gu</surname>
<given-names>Z.</given-names>
</name>
<name>
<surname>Li</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Zhang</surname>
<given-names>X.</given-names>
</name>
<name>
<surname>Shafiq</surname>
<given-names>M.</given-names>
</name>
<name>
<surname>Mei</surname>
<given-names>Y.</given-names>
</name>
<etal/>
</person-group> (<year>2023</year>). <article-title>Cybersecurity knowledge graph enabled attack chain detection for cyber-physical systems</article-title>. <source>Comput. Electr. Eng.</source> <volume>108</volume>, <fpage>108660</fpage>. <pub-id pub-id-type="doi">10.1016/j.compeleceng.2023.108660</pub-id>
</citation>
</ref>
<ref id="B25">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Salem</surname>
<given-names>A. H.</given-names>
</name>
<name>
<surname>Azzam</surname>
<given-names>S. M.</given-names>
</name>
<name>
<surname>Emam</surname>
<given-names>O. E.</given-names>
</name>
<name>
<surname>Abohany</surname>
<given-names>A. A.</given-names>
</name>
</person-group> (<year>2024</year>). <article-title>Advancing cybersecurity: a comprehensive review of ai-driven detection techniques</article-title>. <source>J. Big Data</source> <volume>11</volume> (<issue>1</issue>), <fpage>105</fpage>. <pub-id pub-id-type="doi">10.1186/s40537-024-00957-y</pub-id>
</citation>
</ref>
<ref id="B26">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Segovia-Ferreira</surname>
<given-names>M.</given-names>
</name>
<name>
<surname>Rubio-Hernan</surname>
<given-names>J.</given-names>
</name>
<name>
<surname>Cavalli</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Garcia-Alfaro</surname>
<given-names>J.</given-names>
</name>
</person-group> (<year>2024</year>). <article-title>A survey on cyber-resilience approaches for cyber-physical systems</article-title>. <source>ACM Comput. Surv.</source> <volume>56</volume> (<issue>8</issue>), <fpage>1</fpage>&#x2013;<lpage>37</lpage>. <pub-id pub-id-type="doi">10.1145/365295</pub-id>
</citation>
</ref>
<ref id="B27">
<citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname>Shakarian</surname>
<given-names>P.</given-names>
</name>
<name>
<surname>Bhatnagar</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Aleali</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Shaabani</surname>
<given-names>E.</given-names>
</name>
<name>
<surname>Guo</surname>
<given-names>R.</given-names>
</name>
</person-group> (<year>2015</year>). &#x201c;<article-title>The independent cascade and linear threshold models</article-title>,&#x201d; in <source>Diffusion in social networks</source> (<publisher-name>Springer International Publishing</publisher-name>), <fpage>35</fpage>&#x2013;<lpage>48</lpage>. <pub-id pub-id-type="doi">10.1007/978-3-319-23105-1_4</pub-id>
</citation>
</ref>
<ref id="B28">
<citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname>Sheyner</surname>
<given-names>O.</given-names>
</name>
<name>
<surname>Wing</surname>
<given-names>J.</given-names>
</name>
</person-group> (<year>2003</year>). &#x201c;<article-title>Tools for generating and analyzing attack graphs</article-title>,&#x201d; in <source>International symposium on formal methods for components and objects</source>, <fpage>344</fpage>&#x2013;<lpage>371</lpage>. <pub-id pub-id-type="doi">10.1007/978-3-540-30101-1_17</pub-id>
</citation>
</ref>
<ref id="B29">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Sikos</surname>
<given-names>L. F.</given-names>
</name>
</person-group> (<year>2023</year>). <article-title>Cybersecurity knowledge graphs</article-title>. <source>Knowl. Inf. Syst.</source> <volume>65</volume> (<issue>9</issue>), <fpage>3511</fpage>&#x2013;<lpage>3531</lpage>. <pub-id pub-id-type="doi">10.1007/s10115-023-01860-3</pub-id>
</citation>
</ref>
<ref id="B30">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Stergiopoulos</surname>
<given-names>G.</given-names>
</name>
<name>
<surname>Dedousis</surname>
<given-names>P.</given-names>
</name>
<name>
<surname>Gritzalis</surname>
<given-names>D.</given-names>
</name>
</person-group> (<year>2022</year>). <article-title>Automatic analysis of attack graphs for risk mitigation and prioritization on large-scale and complex networks in industry 4.0</article-title>. <source>Int. J. Inf. Secur.</source> <volume>21</volume> (<issue>1</issue>), <fpage>37</fpage>&#x2013;<lpage>59</lpage>. <pub-id pub-id-type="doi">10.1007/s10207-020-00533-4</pub-id>
</citation>
</ref>
<ref id="B31">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Stojanovi&#x107;</surname>
<given-names>B.</given-names>
</name>
<name>
<surname>Hofer-Schmitz</surname>
<given-names>K.</given-names>
</name>
<name>
<surname>Kleb</surname>
<given-names>U.</given-names>
</name>
</person-group> (<year>2020</year>). <article-title>Apt datasets and attack modeling for automated detection methods: a review</article-title>. <source>Comput. and Secur.</source> <volume>92</volume>, <fpage>101734</fpage>. <pub-id pub-id-type="doi">10.1016/j.cose.2020.101734</pub-id>
</citation>
</ref>
<ref id="B32">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Wachter</surname>
<given-names>J.</given-names>
</name>
</person-group> (<year>2023</year>). <article-title>Graph models for cybersecurity &#x2013; a survey</article-title>.</citation>
</ref>
<ref id="B33">
<citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname>Wang</surname>
<given-names>L.</given-names>
</name>
<name>
<surname>Islam</surname>
<given-names>T.</given-names>
</name>
<name>
<surname>Long</surname>
<given-names>T.</given-names>
</name>
<name>
<surname>Singhal</surname>
<given-names>A.</given-names>
</name>
<name>
<surname>Jajodia</surname>
<given-names>S.</given-names>
</name>
</person-group> (<year>2008</year>). &#x201c;<article-title>An attack graph-based probabilistic security metric</article-title>,&#x201d; in <source>Data and applications security XXII: 22nd annual IFIP WG 11.3 working conference on data and applications security London, UK, july 13-16, 2008 proceedings 22</source>, <fpage>283</fpage>&#x2013;<lpage>296</lpage>. <pub-id pub-id-type="doi">10.1007/978-3-540-70567-3_22</pub-id>
</citation>
</ref>
<ref id="B34">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Yee Por</surname>
<given-names>L.</given-names>
</name>
<name>
<surname>Dai</surname>
<given-names>Z.</given-names>
</name>
<name>
<surname>Juan Leem</surname>
<given-names>S.</given-names>
</name>
<name>
<surname>Chen</surname>
<given-names>Y.</given-names>
</name>
<name>
<surname>Yang</surname>
<given-names>J.</given-names>
</name>
<name>
<surname>Binbeshr</surname>
<given-names>F.</given-names>
</name>
<etal/>
</person-group> (<year>2024</year>). <article-title>A systematic literature review on ai-based methods and challenges in detecting zero-day attacks</article-title>. <source>IEEE Access</source> <volume>12</volume>, <fpage>144150</fpage>&#x2013;<lpage>144163</lpage>. <pub-id pub-id-type="doi">10.1109/ACCESS.2024.3455410</pub-id>
</citation>
</ref>
<ref id="B35">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Zeng</surname>
<given-names>J.</given-names>
</name>
<name>
<surname>Wu</surname>
<given-names>S.</given-names>
</name>
<name>
<surname>Chen</surname>
<given-names>Y.</given-names>
</name>
<name>
<surname>Zeng</surname>
<given-names>R.</given-names>
</name>
<name>
<surname>Wu</surname>
<given-names>C.</given-names>
</name>
</person-group> (<year>2019</year>). <article-title>Survey of attack graph analysis methods from the perspective of data and knowledge processing</article-title>. <source>Secur. Commun. Netw.</source> <volume>2019</volume> (<issue>1</issue>), <fpage>1</fpage>&#x2013;<lpage>16</lpage>. <pub-id pub-id-type="doi">10.1155/2019/2031063</pub-id>
</citation>
</ref>
<ref id="B36">
<citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname>Zenitani</surname>
<given-names>K.</given-names>
</name>
</person-group> (<year>2023</year>). <article-title>Attack graph analysis: an explanatory guide</article-title>. <source>Comput. and Secur.</source> <volume>126</volume>, <fpage>103081</fpage>. <pub-id pub-id-type="doi">10.1016/j.cose.2022.103081</pub-id>
</citation>
</ref>
</ref-list>
</back>
</article>