💻 computer science

Integrating Network and Attack Graphs for Service-Centric Impact Analysis

This paper proposes a novel probabilistic multilayer modeling framework that integrates attack graphs with network topology to enable service-centric impact analysis, offering a cohesive view of attack propagation and cumulative risks in complex enterprise environments.

Original authors: Joni Herttuainen, Vesa Kuikka, Kimmo K. Kaski

Published 2026-05-27

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Joni Herttuainen, Vesa Kuikka, Kimmo K. Kaski

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a massive, complex city (your company's computer network) filled with different neighborhoods (services like email, databases, and web servers). Now, imagine a thief trying to break in.

Traditional security methods often look at the city in two separate ways:

The Map: They look at the roads and bridges (the network) to see how easy it is to get from Point A to Point B.
The Locks: They look at the broken windows and unlocked doors (vulnerabilities) on individual buildings to see how easy it is to break in.

The problem is, thieves don't just pick a lock or drive down a road; they do both at the same time. They need a broken window and a clear road to get to the next building.

This paper introduces a new way to look at the whole city at once. The authors built a "Super-Map" that combines the road network with the list of broken locks. This allows them to calculate exactly how likely a thief is to move from one building to another and, more importantly, how much damage they could do to the city's services (like stopping the mail delivery or stealing the bank's data).

Here is a breakdown of their approach using simple analogies:

1. The Two Layers of the City

The authors created a model with two main layers:

The Infrastructure Layer (The Roads): This represents the physical connections between computers. If a road is blocked (a network failure or a firewall), the thief can't cross it, even if the door is unlocked.
The Attack Layer (The Locks): This represents the specific weaknesses in the software. Some locks are rusty and easy to pick (high "exploitability"), while others are heavy and hard to break (high "impact").

By stacking these layers, they can see the full picture: Can the thief get to the bank vault? Only if the road is open AND the vault door is weak.

2. Measuring the Damage (The "Impact" Metrics)

The authors didn't just ask, "Can the thief get in?" They asked, "If they get in, how bad is it?" They created three specific ways to measure this:

The "Foothold" Score (Inbound Impact): Imagine the thief has just broken into the mailroom. How much damage have they already caused to get there? This measures the cumulative damage of the path they took to reach a specific service.
The "Domino" Score (Outbound Impact): Once the thief is in the mailroom, how many other buildings can they reach from there? This measures how much future damage a specific service could cause if it gets compromised.
The "Total Chaos" Score (Node-wise Impact): If a specific building (like the Database Server) is completely taken over, what is the total maximum damage possible? This sums up all the potential destruction that specific location could cause.

3. Testing the City (The Case Study)

To prove their method works, they used a real-world example of a large fiber-optic network (like a major utility company's backbone). They simulated a thief trying to move through this network.

What they found:

Entry Points Matter Most: Just like in a real heist, stopping the thief at the front door is usually the most effective strategy. If you secure the entry points (the "Direct Access" vulnerability), you stop the thief before they can even see the other buildings.
The "Hub" Problem: Some buildings are so central that even if they aren't the most valuable, they are the best "hubs" for the thief to jump from. Securing these hubs stops the thief from spreading to the rest of the city.
Network Traffic Matters: If the roads between buildings are heavily monitored (low probability of a thief crossing), the thief is less likely to move deep into the city. This means that in a highly monitored network, you don't need to worry as much about the back doors; you just need to make sure the front door is locked tight.

4. How to Fix the City (Mitigation)

The authors tested two ways to stop the thief:

Fixing the Locks (Patching): If you fix a specific broken window (vulnerability), does it stop the thief? They found that fixing the first broken window the thief encounters is usually the most effective way to stop the whole chain of events.
Adding Security Guards (Monitoring): Sometimes you can't fix a lock (maybe the software is old). In that case, you put a guard on the building. The study showed that putting guards on the entry buildings is the most effective way to stop the thief from moving deeper into the network.

The Bottom Line

This paper argues that to truly understand cyber risk, you can't just look at a list of software bugs or just look at a network diagram. You have to look at how the bugs and the roads work together.

Their new method acts like a "crystal ball" for security teams. It helps them answer:

"If we patch this specific hole, how much safer does the whole city become?"
"Which building should we guard first to stop a thief from reaching the bank?"

By combining the map of the roads with the list of broken locks, they provide a clearer, more actionable plan for protecting complex networks.

Technical Summary: Integrating Network and Attack Graphs for Service-Centric Impact Analysis

Problem Statement
Traditional cyberattack analysis methods often operate in isolation, focusing either on attack paths (attack graphs) or network topology without effectively capturing their interdependence. Existing approaches struggle to quantify how attacks propagate across interconnected services or to measure the cumulative impact of vulnerabilities on user-facing functionalities. While probabilistic models exist for estimating attack success and network resilience metrics exist for connectivity, few frameworks integrate these perspectives to provide a service-centric view of risk. This gap limits the ability of security planners to identify critical nodes and vulnerabilities that significantly influence attack outcomes in complex, multi-layered enterprise environments.

Methodology
The authors propose a novel probabilistic multilayer modelling framework that integrates attack graphs with communication network topology. The core of the methodology involves:

Graph Construction:
- Attack Graph: Represented as a Directed Acyclic Graph (DAG) where nodes denote attack states (e.g., privilege levels, file modifications) and directed edges represent exploits. Edge weights ( $p_E$ ) denote the likelihood of exploiting a vulnerability, derived from standard metrics like CVSS exploitability scores.
- Network Graph: Represents the communication infrastructure where nodes are network devices or servers and edges represent communication links. Edge weights ( $w_n$ ) denote the probability of successful communication or attack propagation between nodes.
- Integration: The two graphs are combined by grouping attack states according to the services they affect and mapping these groups to specific network nodes. Start and end states of the attack are connected to the relevant network nodes via directed links with a weight of 1.0.
Probabilistic Calculation:
- The framework calculates the combined probability of a successful attack step ( $p(i, j)$ ) as the product of the network-level connectivity probability ( $p_N$ ) and the vulnerability exploitability ( $p_E$ ): $p(i, j) = p_N(i, j) \times p_E(i, j)$ .
- $p_N$ is calculated using a Simple Contagion Algorithm, accounting for all non-intersecting paths between network nodes.
- The probability of reaching a specific state ( $P(i)$ ) is calculated assuming independent attack paths, using the formula $P(i) = 1 - \prod_{j \in A} [1 - P(j, i)]$ , where $A$ is the set of preceding states.
Impact Metrics:
The study introduces several quantitative metrics to assess risk at different levels:
- Expected Cumulative Impact ( $CE[I_i]$ ): The sum of expected impacts of all vulnerabilities on paths leading to a specific state.
- Node-wise Impact ($CNODE$): The sum of expected impacts of vulnerabilities affecting a specific service/node, independent of prior attack propagation.
- Cumulative Inbound Impact ($CIN$): The impact accumulated up to the point an attack gains a foothold in a service.
- Cumulative Outbound Impact ($COUT$): The total impact if a service is used as a stepping stone to reach further targets or achieve the attack goal.

Case Study and Results
The methodology was validated using a realistic case study involving a fiber-optic based enterprise network topology and an attack graph derived from a multi-cloud enterprise scenario.

Initial Analysis: With network links assumed fully reliable ( $w_n = 1.0$ ), the analysis identified Node 2 (VM Groups) as having the highest node-wise impact due to its large attack surface, despite having some less exploitable vulnerabilities. Node 7 (Admin Server) showed high inbound and outbound impact, indicating it is a critical transit point for high-impact attacks, even if its direct vulnerability count is lower.
Vulnerability Mitigation: Simulating the removal of individual vulnerabilities revealed that fixing entry-point vulnerabilities (e.g., DIRECT-ACCESS) and those appearing early in attack paths (e.g., CVE-2009-1535) yielded the highest reduction in cumulative impact. Vulnerabilities with high impact but low exploitability or those appearing late in the attack chain had less effect on the overall outcome.
Node Monitoring: Simulating enhanced monitoring (reducing exploitability by 80%) showed that securing entry nodes (Nodes 1, 4, 6, 8) significantly reduced the probability of deep network penetration. However, monitoring Node 2 was also highly effective due to the high number of attack paths traversing it.
Network Link Weight Variation: When network link weights ( $w_n$ ) were reduced to simulate stricter network monitoring or lower connectivity, the importance of early-stage vulnerabilities increased. The model demonstrated that in environments with low lateral movement probabilities, mitigating entry points becomes the most effective strategy, while the significance of vulnerabilities deep in the network (e.g., on Node 3) diminishes rapidly as the probability of reaching them drops.

Key Contributions and Significance
The paper claims the following contributions:

Integrated Framework: It provides a cohesive, service-centric modelling approach that combines attack propagation dynamics with network connectivity probabilities, addressing the limitation of analyzing these factors in isolation.
Quantitative Service-Level Metrics: The introduction of $CIN$, $COUT$, and $CNODE$ metrics allows for the quantification of both the impact of incoming attacks on a service and the potential for that service to propagate attacks to other parts of the system.
Actionable Insights for Mitigation: The study demonstrates that the framework can identify critical nodes and vulnerabilities that are not immediately obvious when looking at attack graphs or network topology alone. For instance, it highlights that a node with a small attack surface but high connectivity to critical assets (like Node 7) may require prioritized monitoring.
Scenario Analysis: The model effectively evaluates how different defense strategies (e.g., patching specific vulnerabilities vs. enhancing network-wide monitoring) alter the risk landscape, showing that the optimal mitigation strategy depends on the reliability of the underlying network.

The authors conclude that this approach advances the analysis of cyberattacks in complex networked environments by offering a more actionable view for risk assessment and mitigation planning, particularly in scenarios where understanding the interplay between service dependencies and network topology is crucial.