Attack Path Analysis for CTEM: How to Score Paths and Decide What to Fix

• What an attack path is and how it differs from a finding
• The five parts of every path
• How to score paths by feasibility and business impact
• Where analysis differs from mapping
• How to find the choke point that cuts many paths
• How to hand path findings to engineering teams
• Metrics that prove path risk is falling

A path is not a finding

A finding says a weakness exists on an asset. A path says that a weakness, combined with a permission and a network route, allows an attacker to move from somewhere they can reach to something you care about. Attackers do not exploit findings for their own sake, they walk paths. This is why two environments with identical vulnerability counts can carry radically different risk.

If your programme already maps paths, analysis is the next discipline: deciding which of the thousands of theoretically possible chains deserve engineering time this month. This article focuses on that decision. For building the graph itself, see the companion article on attack path mapping.

The five parts of a path

Scoring: feasibility against impact

The most practical scoring model uses two axes. Feasibility asks how hard the path is for a competent attacker, taking into account whether each hop needs a rare condition, a credential they must first steal, or a user action. Impact asks what the destination is worth in business terms. Neither axis is a CVSS score, and both should be agreed with the business rather than invented inside the security team.

1. 1Count the hops and note which ones require an attacker to obtain something they do not already have.
2. 2Mark any hop that depends on a known exploited vulnerability, because that removes uncertainty about capability.
3. 3Score impact from the destination asset, not from the entry point.
4. 4Reduce feasibility only where a control has been validated, not where one is assumed to exist.
5. 5Recalculate after every remediation, because closing one hop can reroute the path rather than remove it.

Analysis versus mapping

Find the choke point before you write tickets

Paths overlap. In most enterprises a handful of nodes appear in a disproportionate share of critical paths: a service account with broad rights, a jump host reachable from too many segments, a container role attached to every workload in a cluster. Fixing one of those nodes eliminates dozens of paths in a single change, which is a far better use of an engineering sprint than closing individual findings.

• Rank nodes by the number of critical paths that cross them
• Validate that the node is genuinely required, because graphs contain stale data
• Design the smallest change that removes the capability rather than the asset
• Model the change first, since removing a permission can break a production job
• Recount paths after the change and publish the reduction as the outcome

Handing path findings to engineering

Engineering teams reject path findings when they arrive as a diagram with no clear ask. Translate every path into the specific change on the specific asset the owning team controls, and state what the change removes. A ticket that says remove the local administrator group membership for the build service on these twelve hosts, which cuts eighteen paths to the payments database, gets scheduled. A screenshot of a graph does not.

How this fits the CTEM lifecycle

Path analysis strengthens prioritization and gives validation its targets. The validation stage then proves which hops are real, which feeds corrected feasibility scores back into the graph. Mobilization receives fewer, larger, better justified changes. The loop tightens with each cycle because the graph becomes more accurate every time a hop is tested.

How to measure success

• Define your crown jewel assets in writing before analysing any path.
• Score every path on feasibility and business impact rather than on component severity.
• Rank nodes by path frequency and fix choke points before individual findings.
• Validate the hops you intend to act on so scoring is based on evidence.
• Convert each path into a concrete change request owned by the team that controls the asset.
• Recount paths after each change and report the reduction as the programme outcome.

• Presenting a graph to executives instead of a ranked list of decisions.
• Scoring impact from the entry point rather than the destination.
• Assuming a control blocks a hop without testing it.
• Closing one hop without checking whether the path simply reroutes.
• Ignoring identity data, which is where most real paths live.
• Letting the graph go stale, so analysis is done on last quarter's environment.