Attack Path Analysis Explained

Attack path analysis maps the chains of steps an attacker could take from a foothold to something you care about, then shows which single fixes break the most chains. It answers a question that finding lists cannot: not “what is weak?” but “what does the weakness lead to?” This explainer covers how the method works, what data it needs, how to read the output, and where it misleads.

What it is

An attack path is an ordered sequence of steps from an entry point to a target. Each step relies on a specific weakness, misconfiguration, permission or trust relationship. Attack path analysis models the environment as a graph so those sequences can be found and ranked.

• Nodes are things an attacker can occupy or reach: hosts, user and service identities, cloud roles, applications, data stores.

• Edges are the relationships that let an attacker move from one node to the next: a permission, a network route, a stored credential, a trust between accounts, an exploitable flaw.

• Weights describe how hard, likely or detectable each move is. They are optional, and they are where threat intelligence enters.

• Targets are the assets whose compromise would matter to the business. Without a defined target there is no path to analyze, only a map.

Why lists of findings miss it

A vulnerability scan, a cloud posture report and an identity review each produce findings. Each finding is a node. Attackers do not work node by node. They use edges, and they combine findings that no one scored together.

Two consequences follow. A set of findings that each rate medium or low can combine into a direct route to a critical asset. And a critical flaw on a system with no route to anything valuable may deserve less urgency than its score suggests. Neither case is visible from a list sorted by severity.

Entry points are real and varied. In Verizon’s most recent Data Breach Investigations Report, exploitation of vulnerabilities overtook stolen credentials as the most common initial access vector, at 31% of breaches in the study period. Both are valid starting nodes. A path model should start from each of them, not from one.

How the analysis works

1. Define targets. Start from the assets and processes the business cannot lose, such as payment systems, identity administration, customer data, operational control systems or the backup infrastructure. Two or three well-chosen targets beat a long list.

2. Define starting points. Typical ones are an internet-facing service, a phished employee, a compromised supplier connection, a stolen cloud key and a malicious insider. Each yields different paths.

3. Collect and normalize data. Pull identity, permission, network, configuration, vulnerability and asset data into one model. Most of the effort goes here.

4. Build the graph and compute paths. Tools do this at scale, but the logic is simple: find routes from each starting point to each target through the available edges.

5. Find the choke points. These are the nodes or edges that many paths share. Closing one removes many routes at once.

6. Validate and fix. Confirm the highest-risk paths by hand or with testing, close the choke points, and run the analysis again to see what changed.

A worked example

This is a hypothetical scenario. It describes no real incident or organization.

An attacker targets a company’s customer data store in a cloud environment. The table shows one path and the technique each step uses, mapped to MITRE ATT&CK.

No step contains a critical vulnerability. Listed alone, each finding would rate medium or lower. Taken together they reach customer data in five moves.

The choke point is step 4. The permission that lets an ordinary account attach roles also sits on other paths. Removing it breaks this chain and several others, which is a better return than hardening five separate items. Shortening session lifetime or binding sessions to devices would also cut step 2, and that would be a second, independent fix.

How it differs from adjacent methods

Attack path analysis is often confused with other practices. They answer different questions and work best together.

What data it needs

Where threat intelligence fits

Without weights, every edge looks equally likely, and the output is a large and unranked set of paths. Threat intelligence supplies the weights. MITRE ATT&CK is a knowledge base of adversary tactics and techniques built from real-world observations, and it gives analysts a shared vocabulary for edges. If the actors that target your sector favor session theft and cloud role abuse, paths using those techniques should rank above paths that need rare exploits.

Treat the weighting as judgment informed by evidence, not as measurement. Intelligence shows what adversaries have done. It does not guarantee what they will do next.

Limits and how it misleads

• A missing path can mean missing data. If the model cannot see a trust relationship, it will report no route where one exists. Absence of paths is not proof of safety.

• Assigned is not effective. Permissions interact with policies, conditions and boundaries. Models that read only assignments overstate or understate real reach.

• The environment changes faster than the graph. Cloud and identity change daily. A path map is stale unless it refreshes.

• People and process are hard to model. Help desk resets, approvals and informal trust do not appear as edges unless someone adds them.

• Path counts can overwhelm. Thousands of paths are not a plan. The value lies in choke points and the shortest routes to the few targets that matter.

• Output needs validation. Confirm high-risk paths with testing before spending engineering time on them.

Measures worth tracking

These are suggestions, not standards. Pick a few and track the trend rather than the absolute number.

• Number of distinct paths to each defined target.

• Length of the shortest path to each target. Short paths are the dangerous ones.

• Number of choke points, and how many have been closed.

• Share of paths with at least one step covered by tested detection.

• Time from discovering a high-risk path to closing it.

Using this explainer

Start with one target and two starting points. Build the graph from identity and cloud permission data first, since that is where the most surprising paths usually appear. Find the choke points, fix the cheapest high-impact one, and run the analysis again. If the path count drops, the method is working. If it does not, the data model is the first thing to question.

Sources

1. MITRE, ATT&CK knowledge base. https://attack.mitre.org/

2. Verizon, Data Breach Investigations Report. https://www.verizon.com/business/resources/reports/dbir/