A cloud attack path is not a dramatic diagram of every theoretical possibility. It is a reviewable chain of relationships from an entry condition to a target that matters, with enough evidence to explain why each hop is reachable.
What cloud attack path analysis is
Cloud platforms are relationship-heavy. A workload has a network location and an execution identity; that identity inherits policies, assumes roles, calls APIs, and may reach data stores in another account. An issue matters far more when those relationships form a usable route to sensitive data or control-plane authority.
CISA's Cloud Security Technical Reference Architecture treats posture management, continuous monitoring, identity and access management, application protection, and data protection as connected capabilities.[1] Attack path analysis builds on that posture data and asks a narrower question: which combinations create reachable impact?
The anatomy of a cloud attack path
The entry condition can be network exposure, a leaked credential, a compromised developer account, or an application weakness. What turns it into a path is the identity it runs as. MITRE ATT&CK documents cloud accounts as valid-account access used for initial access, persistence, privilege escalation, and defense evasion.[2] A graph that models vulnerabilities but ignores who can call the next API misses the paths that matter most.
How graph analysis works
Nodes represent security-relevant objects
Accounts, subscriptions, projects, users, roles, service accounts, workloads, clusters, networks, secrets, storage, databases, findings, and designated high-value resources. Useful graphs keep the provider-native identifier on every node so a reviewer can trace any result back to its source.
Edges represent actions or reachability
Every edge answers a concrete question: can this principal assume that role, read that secret, reach that service, or modify that policy? AWS documents automated reasoning for both IAM access findings and network-path analysis.[3][4] Implementations differ by provider; the discipline does not. Each edge needs a reason and source evidence.
Paths are hypotheses until verified
Policy analysis proves that access is allowed under a model. It does not prove that credentials are available, that a runtime control will permit the request, or that the target holds the assumed data. Mature programs keep modeled, observed, and validated paths apart.
A practical prioritization model
| Signal | Question | Why it changes priority |
|---|---|---|
| Exposure | Can the entry point be reached from the internet or an untrusted network? | Reduces the access an attacker needs before the first hop. |
| Exploit confidence | Is the weakness suspected, reproducible, or validated? | Separates scanner possibility from demonstrated behavior. |
| Identity reach | Which roles or service accounts can the foothold use? | Determines how far the attacker can move through control-plane APIs. |
| Target value | Does the path reach sensitive data, production control, or a security boundary? | Connects technical reachability to business consequence. |
| Choke-point leverage | How many paths share the same risky edge? | Favors fixes that eliminate several routes at once. |
| Freshness | When were the assets, policies, and evidence last observed? | Cloud graphs age quickly when deployments and permissions change. |
Attack paths across AWS, Azure, and Google Cloud
Every major provider now exposes some form of relationship analysis. AWS IAM Access Analyzer evaluates policies; Network Access Analyzer evaluates network paths.[3][4] Microsoft Defender for Cloud traces attack paths from externally driven threats to critical targets such as databases holding sensitive data.[5] Google Cloud Security Command Center simulates paths and scores exposure around high-value resources.[6]
A multi-cloud program should not flatten these into generic labels. Keep each provider's identity semantics, resource hierarchy, conditional policies, and network constructs. Normalize the question — who can reach what, by which action, from which entry — not the details that make the answer trustworthy.
Choke-point remediation
The best fix is rarely the loudest vulnerability. It is the smallest justified change that removes a necessary edge: narrowing a role trust policy, dropping an unused permission, restricting public access, rotating an exposed secret, or moving sensitive data behind a stronger identity boundary.
- Prefer least-privilege changes that remove unnecessary reach without breaking the workload's required behavior.
- Count how many material paths a proposed change breaks, not how many alerts it closes.
- Record the owner and source configuration for the risky edge.
- Test the expected business path before and after remediation.
- Recompute the graph and verify that no equivalent route remains.
Cloud attack path program checklist
Inventory
Resources and identities in every in-scope account, subscription, and project.
Designate the targets
High-value data and control-plane resources, each with an owner.
Collect native evidence
Policy, trust, network, vulnerability, data-context records.
Model the crossings
Cross-account, cross-project, and workload-identity relationships.
Keep the states apart
Modeled, observed, and validated are three different claims.
Prioritize
Entry feasibility, target value, evidence confidence, choke-point leverage.
Recalculate
After identity, network, workload, and data-location changes.
Frequently asked questions
What is a cloud attack path?
A cloud attack path is an ordered set of reachable relationships that could let an attacker move from an initial foothold to a material target. A path can combine internet exposure, a workload weakness, credentials, IAM permissions, trust policies, network reachability, and access to sensitive data.
How is attack path analysis different from CSPM?
CSPM continuously identifies cloud configuration and posture issues. Attack path analysis connects selected issues with identity, network, workload, and data relationships to determine which combinations may create a route to a critical target. The practices complement each other.
What is a toxic combination in cloud security?
A toxic combination is a set of individually limited conditions that becomes materially risky when combined, such as public reachability, a vulnerable workload, an assumable role, and access to a sensitive data store. The combined path matters more than any isolated alert.
What is a choke point in an attack path?
A choke point is a relationship or control shared by one or more attack paths. Removing unnecessary public access, narrowing a role trust policy, reducing a permission, or isolating a data store can break several paths with one change.
Primary sources
- CISA. Cloud Security Technical Reference Architecture
- MITRE ATT&CK. Valid Accounts: Cloud Accounts (T1078.004)
- AWS. IAM Access Analyzer findings
- AWS. How Network Access Analyzer works
- Microsoft. Security explorer and attack paths in Microsoft Defender for Cloud
- Google Cloud. Overview of attack exposure scores and attack paths