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
- Public endpointEntry
- Vulnerable workloadHop
- Attached build roleHop
- Choke point
- Assumed administrator roleHop
- Customer data storeTarget
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
- InventoryResources and identities in every in-scope account, subscription, and project.
- Designate the targetsHigh-value data and control-plane resources, each with an owner.
- Collect native evidencePolicy, trust, network, vulnerability, data-context records.
- Model the crossingsCross-account, cross-project, and workload-identity relationships.
- Keep the states apartModeled, observed, and validated are three different claims.
- PrioritizeEntry feasibility, target value, evidence confidence, choke-point leverage.
- RecalculateAfter identity, network, workload, and data-location changes.
Primary sources
- CISACloud Security Technical Reference Architecture
- MITRE ATT&CKValid Accounts: Cloud Accounts (T1078.004)
- AWSIAM Access Analyzer findings
- AWSHow Network Access Analyzer works
- MicrosoftSecurity explorer and attack paths in Microsoft Defender for Cloud
- Google CloudOverview of attack exposure scores and attack paths