Attack Graphs: Modeling How Compromise Spreads

The attack graph problem is not visualization. It is whether every edge describes a usable relationship in your environment now.

An attack graph connects systems, identities, permissions, vulnerabilities, sessions, and control planes to show how an intruder could move from a foothold to something the business cannot afford to lose. The drawing is the easy part. The hard part is proving that a source can reach a target, that an identity works there, and that the target grants enough authority for the next step.

Most programs already own fragments of this data. The network team has routes and firewall policy. Identity has group membership and delegated rights. Endpoint tools have sessions and software state. Vulnerability teams have findings. None of those lists, alone, explains how compromise spreads. The graph earns its keep when it joins the fragments and points to a repair an owner can verify.

What is an attack graph in cybersecurity?

An attack graph is a directed model of possible compromise. Nodes represent things or security states. Edges represent a transition an attacker may be able to make. A node might be a laptop, account, cloud role, server, application, secret, or backup system. An edge might mean can authenticate, can administer, can reach, can assume, can execute, or can read a credential.

The word possible needs discipline. A firewall rule that permits TCP 445 is one fact. It does not prove that an account can authenticate over SMB, that the account has useful rights, or that the service is listening. Each step needs its own evidence. Treating a permitted packet as a completed attack creates a noisy graph that nobody trusts.

Attack trees usually describe alternative ways to reach one goal. A graph can contain many starting points, targets, loops, shared dependencies, and routes. That structure exposes choke points. It also exposes blast radius: the set of assets or authorities reachable after one node is compromised.

Which nodes and edges belong in the graph?

Start with assets and identities that can change security outcomes. Include workstations, servers, network devices, applications, cloud resources, human accounts, service identities, groups, tokens, and management platforms. Mark critical targets with a business reason, not a color chosen by security. The asset criticality guide explains how availability, authority, data, build integrity, and recovery change impact.

Use edge names that state a testable claim. CAN_REACH should identify the protocol, port, source, destination, policy source, and observation time. CAN_ADMIN should identify the account, effective permission, target, and directory or local policy that grants it. HAS_SESSION should expire when the observed session ends or its evidence ages out.

Keep unknown separate from false. Missing firewall telemetry does not prove there is no route. A directory export from last month does not prove today's membership. An honest graph can say that an edge is observed, inferred, disproved under named conditions, or unknown. Collapsing those states into one line makes the picture cleaner and the decision worse.

Why does current breach data support path based defense?

Verizon published its 2026 Data Breach Investigations Report in May 2026. Its official report page says 31 percent of breaches started with software vulnerabilities and 48 percent involved ransomware. Those are not separate queues. An exposed vulnerable server can become the first node on a route to identity, virtualization, or backup control.

A graph also helps with detection. The Hopper research project evaluated a path model on 15 months of data covering more than 780 million internal logins. It reported a 94.5 percent detection rate across more than 300 realistic scenarios while producing fewer than nine alerts per day. The published Hopper study matters because it judged sequences, not isolated logons.

The data model cannot be frozen. MITRE released ATT&CK v19.2 on August 6, 2026 as its first Agile release. The ATT&CK v19.2 release notes added current groups and software between the usual larger releases. That change should alter how teams ingest threat facts. Store the ATT&CK version on mapped behaviors, monitor smaller releases, and recalculate affected paths when the source changes.

How do you build a minimum useful attack graph?

Pick five to ten targets whose loss would cause material harm. Starting with the whole estate usually produces a long integration project and no decision. For each target, work backward through the identities, management tools, network routes, sessions, deployment systems, and recovery dependencies that can change it.

1. Name the target, business owner, technical owner, and impact reason.
2. Collect effective identity rights, active sessions, network reach, exposed services, and current software state.
3. Create one edge per testable relationship. Attach its source, collection time, confidence state, and expiry.
4. Search from plausible entry nodes to each target, then inspect shared nodes and edges.
5. Ask the responsible team to confirm or reject each proposed repair and record the result.

Build around effective state, not policy intent. A firewall ticket says what someone approved. A connection test or current flow record says what the route allowed. A group standard says where administrators should log on. Session evidence says where they did. Both records are useful, but they answer different questions.

How do you query attack graph paths?

The following Cypher query looks for routes of one to six edges from an internet exposed asset to a critical asset. The relationship syntax follows the current Neo4j Cypher path documentation.

This is a triage query, not proof of compromise. Review the evidence on every returned edge. Add relationship properties for time, source, environment, and confidence before using a path to approve a disruptive change. Shortest is not always most likely either. A two hop route that requires a rare manual approval may be less usable than a four hop route built from standing credentials.

How should attack graphs rank repairs?

Do not rank only by path count. Ten theoretical routes with stale edges may matter less than one observed route to the backup controller. Rank with entry feasibility, identity strength, target impact, edge confidence, active exploitation, and the number of serious paths a repair removes.

Choke point math makes limited capacity visible. Suppose the graph contains 80 routes to three critical targets. Forty six use one support group, 19 use an open management port, and 15 share no edge. Removing stale support membership costs four change hours. Restricting the port costs eight. Fixing 61 routes for 12 hours of work is a better opening move than patching one ordinary node on one route, assuming the edge evidence is current.

Record the expected path reduction before the change and recalculate after it. A closed ticket is not a closed path. If the same access survives through a nested group, alternate protocol, cloud token, or deployment tool, the work changed configuration without changing reachability.

What does a worked attack graph decision look like?

A support engineer uses a shared local administrator account on 60 workstations. One workstation hosts an exposed application. The account can open a remote service on a management server. That server holds a deployment token accepted by the backup controller. A second route reaches the same management server from a build runner.

The vulnerable application deserves repair, but it is not the only decision. Replace the shared password with unique managed credentials. Deny support accounts on management servers. Restrict the deployment token to a noninteractive service context. Limit the controller to named management sources. The graph turns one patch task into four independent control options and shows which option removes the most routes.

Verification repeats the original tests. Confirm that the workstation no longer authenticates to the management server, the support identity no longer holds administrator rights there, the old token fails, and the controller accepts traffic only from approved sources. Then regenerate the graph. Keep the path closed only while those facts remain true.

When does an attack graph become stale?

Immediately after a material identity, network, deployment, cloud, or asset change. Add expiry by data type. Sessions may age in minutes. Flow evidence may need hours or days. Group membership should refresh after directory change events. Criticality can last longer, but ownership and service dependencies still need scheduled review.

Track collection coverage beside path counts. A drop from 200 routes to 20 looks excellent until someone notices that endpoint collection stopped on half the servers. Useful health measures include the share of edges with a current source, the share of critical targets with complete identity and network data, and the time between a source change and graph recalculation.

Code reachability has the same proof problem at a different layer. Our vulnerability reachability analysis guide shows why package presence, a possible call path, and a satisfied exploit condition are separate claims. Use that same discipline for infrastructure edges.

How should operators use the graph each week?

Review new paths to critical targets, expired edge evidence, high reach identities, broad management sources, and repairs that failed recalculation. Assign an owner to the relationship that should change. Security can explain the route. Infrastructure, identity, cloud, or application owners usually control the edge.

For active response, overlay observed logons, processes, connections, and token use on the possible graph. A new sequence across two known edges deserves more attention than an isolated familiar event. The lateral movement guide explains how source, identity, channel, and target evidence turn activity into a movement case.

Artemes approaches the decision with deep endpoint context and AI driven analysis, but the evidence boundary still matters. A model can help assemble and explain relationships. It should not invent a route, hide missing data, or mark a path closed without a fresh verification result.

Frequently asked questions

What is the difference between an attack graph and an attack path?

The graph contains nodes, edges, and many possible routes. An attack path is one sequence through that graph from a starting condition to a target or impact.

Does an attack graph prove an attacker used a path?

No. It models what may be possible. Observed authentication, process, network, identity, and endpoint evidence can show that an actor used some edges. Keep possible and observed states separate.

How often should an attack graph update?

Update after material source changes and expire each edge according to its evidence. Session edges may need minute level updates, while ownership records can use a longer review cycle.

What should a small team model first?

Start with five critical targets and the identities, routes, sessions, vulnerabilities, and management systems that can change them. Deliver one verified repair before expanding coverage.

The executive takeaway

Pick five critical systems this week. Demand a current source and owner for every relationship that reaches them. Close the shared edge that removes the most serious routes, repeat the original access test, and regenerate the graph. Measure verified path reduction, not colorful nodes.