Attack Path Analysis

Attack path analysis treats an environment as connected resources and relationships rather than isolated security findings. Resources include identities, virtual machines, applications, secrets, and data stores. Relationships describe capabilities such as reaching a network endpoint, assuming a role, retrieving a credential, or modifying a workload. A path connects an entry point to an objective, such as stealing sensitive records or obtaining administrative access.

The distinction between a possible path and an observed path is essential. Configuration analysis can show that a compromised workload might access a secret and use it to reach a database. That does not prove an attacker performed those actions. Incident investigation must corroborate each significant step using audit events, authentication records, network metadata, application logs, or forensic artifacts. Record confirmed facts separately from hypotheses and document gaps in visibility.

In the cloud, paths often cross identity and management interfaces rather than following network connections alone. An attacker holding a stolen API credential might assume a cross-account role and read object storage without accessing a virtual machine. Effective access depends on the applicable identity policies, resource policies, trust policies, organization controls, session restrictions, and explicit denies. Network reachability by itself does not establish authorization, and a permissive policy by itself does not establish successful exploitation.

For example, an alert might identify unusual activity by a workload role. Investigators can trace the role session to its originating instance, examine preceding application activity, and correlate subsequent role assumptions and storage access. On AWS, CloudTrail events can help reconstruct API activity, while Amazon Detective can help explore relationships and behavior around involved entities. Object-level access may require CloudTrail data events to have been configured; missing events must not be interpreted as proof that access never occurred.

For root cause analysis, work backward from the detected action to the initial access mechanism and enabling control failures, then forward to identify affected resources and persistence. A vulnerable application might explain credential exposure, an overly permissive role might explain further access, and inadequate monitoring might explain delayed detection. The first alert is not necessarily the first malicious action, and the identity recorded in an event is not necessarily the human responsible.

Containment should interrupt verified or high-risk paths while preserving evidence where feasible. Actions might include isolating a workload, restricting role trust, rotating exposed secrets, and invalidating affected sessions where supported. Disabling a long-term access key does not necessarily invalidate temporary credentials already issued from it. Preserve logs and relevant workload evidence, record response changes, and validate that remediation blocks the route without unnecessarily disrupting production.

The main trade-offs are analysis cost, telemetry coverage, and confidence. Detailed logging and relationship modeling improve investigations but increase storage, processing, and operational effort. Configuration changes can make a historical path differ from the current environment, while shared credentials and incomplete logs can obscure attribution. Prioritize paths by feasible access, asset sensitivity, and observed behavior rather than by vulnerability severity alone, and treat attack path analysis as an input to root cause analysis rather than a substitute for it.