Home / Path Analysis

Path Analysis

Defender-first definition: Path analysis is the practice of turning an attack model into computable reachability, then using the resulting paths to decide what to log, what to harden, and what to test safely. The output is not a diagram. The output is a prioritized list of paths, chokepoints, evidence hooks, and control breakpoints.

Most security programs already have partial models: threat scenarios in documents, procedures in runbooks, and technique mappings in ATT&CK coverage dashboards. Path analysis connects these fragments into a single question: given the environment, what can an attacker reach next, and which controls break the highest impact paths with the least operational cost.

A Practical Workflow

To keep path analysis usable, run it like an engineering loop. You define scope, compute reachability, and then validate what matters most.

  1. Define the objective: the crown-jewel outcome and the safety and availability constraints.
  2. Build the model: start with the Composer or a small hand-built graph. Focus on prerequisites, actions, and postconditions that you can validate.
  3. Normalize primitives: choose node and edge types that stay stable across tools and teams.
  4. Compute paths: enumerate feasible sequences, identify chokepoints, and find minimal sets of controls that break high-impact paths.
  5. Attach evidence: for every critical node and edge, record what telemetry can confirm it, and what baseline can falsify it.
  6. Validate safely: use read-only checks, staging, replay, or controlled testing to reduce uncertainty without disrupting operations.
  7. Operationalize: map to detections, mitigations, and response playbooks, then track coverage by path segments.
  8. Maintain: refresh site facts on a cadence aligned with change management (zoning, access paths, firmware, remote access).

Attack Trees

Attack trees decompose a goal into alternative sub goals until you reach concrete actions. They are excellent for design-time reasoning and stakeholder communication because they expose assumptions and show what must be true for a branch to succeed.

Attack Graphs

Attack graphs represent states and transitions. A node is a capability, privilege, condition, or operational state. An edge is an action that becomes possible when prerequisites hold, producing postconditions that change what is reachable next. When your question involves reachability, pivot points, or multi-stage progression, graphs are the right abstraction.

Graph Primitives and a Practical Schema

Remember the separation that keeps graphs computable: facts (assets, identities, network paths), rules (what actions become possible), and constraints (what is plausible in the environment). Defender-first graphs add evidence hooks on every critical element, meaning logs, telemetry, baselines, or tests that can confirm or falsify that part of the model.

A minimal portable representation often includes: node type (capability, privilege, condition, asset state), node scope (zone, asset, account), edge action, edge prerequisites, and attached observables and mitigations. This stays tool-agnostic while remaining actionable.

Path Analysis Computations

Most teams do not need exotic mathematics to get value. Start with reachability and then add one or two computations that match your objective.

  • Reachability: forward traversal to compute what becomes possible after each transition.
  • Top paths: enumerate a bounded set (for example k shortest or k highest impact) to keep analysis and validation manageable.
  • Chokepoints: identify nodes or edges that sit on many high-value paths, often found via centrality or path intersection.
  • Break sets: approximate the smallest set of defensive changes that breaks the most high-impact paths (a useful control placement view).
  • Uncertainty handling: treat weakly evidenced prerequisites as probabilistic or as separate branches, and prioritize validation to collapse uncertainty quickly.

From Composer Output to Paths

The Composer emits a chain of prerequisites, actions, observables, and mitigations. Converting to a graph is usually a mapping step: prerequisites become incoming conditions, actions become edges, postconditions become new reachable states, and observables attach as evidence that the edge fired or the state changed.

In OT and CPS contexts, add two layers during conversion: (1) reachability across zones and conduits, and (2) process constraints that limit how control changes can manifest. This prevents the model from assuming transitions that are cyber-possible but process-impossible.

Scoring and Prioritization

In path analysis, the highest priority items are rarely the most dramatic vulnerabilities. Prioritize by what changes reachability. Practical ranking factors include chokepoints, prerequisite complexity, physical or safety impact, and defensive leverage, meaning which control breaks the most high-impact paths.

For OT and cyber-physical systems, add a physics-informed impact lens. Some transitions cause a small cyber change but a large process consequence due to interlocks, timing, ramp limits, load sharing, or protective logic. These are high priority even when the cyber step looks ordinary.

OT and Cyber-Physical Extensions

In OT and cyber-physical systems, a pure cyber graph is incomplete. Extend nodes with plant roles (engineering workstation, HMI, historian, controller, safety controller) and extend edges with protocol semantics, timing realities, and safety requirements. Most importantly, connect cyber transitions to operational states that can propagate through the process.

Physics-informed constraints behave like guardrails: conservation relationships, timing bounds, rate limits, permitted operating envelopes, and controller logic. When you treat these as constraints on state evolution, the model becomes a defensible representation of what can plausibly happen, how quickly it can happen, and what telemetry should move as a result.

Validation and Safe Testing

A path is only as good as its evidence. Validate facts via asset inventories, identity paths, and configuration baselines. Then validate the most consequential transitions with authorized, safety-aware tests. Where direct testing is risky, use staging environments, digital twins, replayable datasets, or read-only verification tasks that still reduce uncertainty.

From Model to Defense

Operationalize paths by mapping them to technique language (ATT&CK, CAPEC), then mapping detections and mitigations to your control catalog. Track coverage by path segments and validate with targeted, safe tests so the path set becomes a living measure of defensive posture, not a static report.

Key References

  1. Schneier: Attack Trees (1999)
  2. Sheyner, Jha, Wing: Automated Generation and Analysis of Attack Graphs (2002)
  3. Ou et al.: MulVAL (2005)
  4. MIT Lincoln Laboratory: Automated Generation and Analysis of Attack Graphs
  5. NIST SP 800-154: Guide to Data-Centric System Threat Modeling
  6. NIST SP 800-82: Guide to Industrial Control Systems Security
  7. MITRE ATT&CK for ICS
  8. MITRE D3FEND

FAQ

How is path analysis different from threat modeling?
Threat modeling frames what matters and what could go wrong. Path analysis takes one scoped scenario and computes reachable progressions so you can prioritize chokepoints, evidence, and defensive changes based on what becomes possible next.
When should I use a tree versus a graph?
Use a tree when you want to communicate alternative strategies and assumptions. Use a graph when privileges, identities, and network paths change the set of possible next steps and you want computed reachability and chokepoints.
What should a node represent?
Use nodes for stable, testable states: a capability, privilege, trust condition, or operational state that becomes true. Avoid overly tool-specific nodes unless you can justify them with evidence and keep them current.
How many paths should I enumerate?
Start bounded. Enumerate enough paths to cover the dominant strategies and constraints, then stop when additional paths stop changing your prioritization. Most value comes from the top paths and the chokepoints they share.
How do I handle uncertainty in prerequisites?
Mark weakly evidenced prerequisites explicitly and treat them as validation tasks. If a prerequisite is critical and uncertain, prioritize evidence collection before you invest in deeper computation or mitigations.
How do OT constraints change scoring?
OT adds safety and availability weighting and introduces feasibility constraints. Physics-informed bounds, timing, interlocks, and plant couplings can make a low-noise cyber step high-impact, and that should dominate prioritization.
How do I validate paths without disruptive testing?
Prefer non-invasive evidence: network inventories, configuration baselines, identity paths, historian trends, and read-only queries where permitted. Turn each critical assumption into a safe validation task with an evidence source and timestamp.
How do I keep paths from going stale?
Separate stable structure from site-specific facts. Version the structure, then refresh facts on a change-managed cadence: zoning, remote access methods, identity pathways, firmware, and procedures.
How do I model identities and privileges?
Make identity paths explicit: accounts, groups, trust relationships, and which credentials enable which transitions. Treat privilege escalation and lateral movement as postconditions that change reachability, not as vague narrative steps.
What is a chokepoint and how do I confirm it?
A chokepoint is a node or edge that sits on many high-impact paths. Confirm it by validating prerequisites and by checking that alternative routes are realistically blocked by zoning, access control, or operational constraints.
How do I represent segmentation and remote access?
Model segmentation as constraints on reachability between zones and conduits, and model remote access as explicit entry edges with evidence hooks such as VPN logs, jump host records, and vendor access policies.
How do I attach evidence to steps?
For each critical edge, record the telemetry that would show it happened and the baseline that would show it did not. Prefer stable sources like authentication logs, network flow, engineering workstation activity, and configuration snapshots.
How do I handle safety systems and interlocks in OT?
Represent safety functions as constraints and separate states. A path that ignores interlocks is not feasible. When safety controllers or bypass procedures are in scope, model them explicitly and treat validation as a safety-governed activity.
Can I use path analysis during incident response?
Yes. Use it to prune the search space. Start from observed evidence, compute plausible next reachability, then prioritize containment and collection around the most likely pivots and chokepoints.

Quick navigation

If your model cannot be validated, it is likely a narrative. If it can be validated, it can be improved.

Defensive artifacts

  • Path set: bounded list of feasible paths to the objective
  • Chokepoints: nodes and edges shared across high-impact paths
  • Evidence map: telemetry and baselines that confirm or falsify critical steps
  • Control breakpoints: the smallest changes that break the most critical paths
  • Safe validation plan: read-only checks, staging, and controlled tests

Companion hubs

  • AttackGraphs for graph-focused construction and scoring
  • Attack Modeling for workflows, templates, and operationalization
  • Composer to generate a scenario and export nodes, edges, and evidence hooks

Standards and resources

Contact