Fundamentals of Cybersecurity
Attack path analysis
Attack path analysis is the process of identifying and prioritizing sequences of weaknesses, permissions, reachability, and trust relationships that could let an attacker reach a target.
In plain terms
Attack path analysis maps and prioritizes those routes, combining weaknesses, permissions, and reachability. Seeing your environment the way an attacker would plan a journey through it, so you block the most dangerous routes.
Attack path analysis finds and ranks the routes an attacker could take to a target, stitching together weaknesses, permissions, reachability, and trust relationships. It examines how individual conditions combine into a practical route from an entry point to an objective. The objective may be privileged access, data theft, ransomware deployment, cloud control-plane access, fraud, persistence, or disruption.
The analysis is useful because attackers rarely depend on one isolated weakness. They chain conditions. A low-privilege account may access a workstation, the workstation may contain a cached credential, the credential may access a server, the server may reach a database, and the database may contain sensitive data. Each step may look manageable alone, but together they create a path to impact.
Attack path analysis connects technical domains. A path may involve network reachability, identity permissions, application vulnerabilities, cloud IAM policy, exposed secrets, endpoint configuration, trust relationships, SaaS grants, and operational process gaps. This makes it different from vulnerability ranking that looks only at CVSS score or patch status. The path view asks what an attacker can actually do from where they start.
The starting point should be realistic. Entry points may include phishing, stolen credentials, exposed remote access, public web applications, third-party access, compromised developer systems, leaked API keys, malicious OAuth apps, or vulnerable internet-facing services. A path that begins with an unrealistic assumption may still be interesting, but it should not drive priority ahead of plausible routes.
The target should be meaningful. Common targets include domain administrator privileges, cloud owner roles, sensitive databases, production deployment pipelines, backup consoles, identity provider administration, payment workflows, executive mailboxes, and regulated data stores. Defining targets helps separate important paths from theoretical movement that does not lead to material impact.
Evidence improves quality. Attack path analysis can use asset inventory, network scans, identity graphs, cloud permission analysis, vulnerability data, endpoint telemetry, configuration management, access reviews, and penetration test results. The strongest findings show concrete relationships: this identity can assume that role, this host can reach that port, this secret grants that access, or this trust relationship permits movement.
Prioritization should consider likelihood, impact, path length, exploitability, available controls, and remediation leverage. A path to production data through one exposed service and one overprivileged identity may deserve priority over dozens of isolated vulnerabilities. Fixing one control point may break many paths, which can be more efficient than addressing every node separately.
Attack path analysis should identify choke points. A choke point is a control or relationship that many paths depend on, such as a privileged group, jump server, shared deployment identity, flat network segment, unmanaged administrator workstation, or common secret store. Hardening a choke point can reduce broad risk. This is one reason graph-based analysis can be useful.
Cloud and identity environments make path analysis especially important. Permissions may be inherited, federated, temporary, or indirect. An identity may not be an administrator directly but may be able to create a function with a privileged role, modify a pipeline, read a secret, or grant itself access. Attack path analysis should examine effective permissions and escalation opportunities.
Validation matters. Some paths are technically possible on paper but blocked by runtime controls, conditional access, network restrictions, approval workflows, or missing credentials. Other paths look blocked but become possible through overlooked trust. Security teams should test high-priority paths through safe validation, penetration testing, purple team exercises, or detailed configuration review.
Remediation should be specific. Findings should name the step that can be broken: remove public exposure, restrict network reachability, reduce group membership, rotate a secret, enforce MFA, segment administration, remove a trust relationship, harden a workstation, or limit a cloud role. A useful path finding explains which change breaks the route and what residual risk remains.
Attack path analysis also supports communication. Leaders may not understand why a medium vulnerability matters, but they can understand a path from a public service to customer data. The path narrative helps connect technical fixes to business risk without exaggeration. The analysis should be repeated. Environments change as new services, permissions, integrations, vendors, and deployments appear. A path that was impossible last month may become possible after a cloud role change or network peering update. Continuous or periodic review keeps prioritization aligned with current architecture.
Attack path analysis should include defensive assumptions. A path may depend on a control failing, such as logging being disabled, MFA being bypassed, or a monitoring alert being ignored. Recording those assumptions helps teams decide whether to break the path by changing architecture, strengthening a control, or improving detection and response. Not every path must be eliminated if controls are strong and verified, but the rationale should be explicit.
The analysis can also guide security testing. Penetration tests and purple team exercises become more valuable when they validate high-priority paths rather than sampling random issues. Testing can confirm whether a path is feasible, whether alerts fire, whether containment is fast enough, and whether remediation actually breaks the route.
Attack path analysis gives defenders a practical view of how compromise can unfold. It helps teams move from isolated findings to risk-reducing action by showing which combinations of exposure, access, and trust create the most important routes to impact.