Attack Path Analysis

Attack Path Analysis connects individual security findings — misconfigurations, identity risks, network exposures, and vulnerabilities — into chains that reveal exactly how an attacker would move from an exposed entry point to your most critical assets. Rather than presenting 847 disconnected findings, Onam builds a property graph of your estate and runs automated traversal to surface the paths that actually represent existential risk.

This page explains how the graph is built and verified, how paths are found and ranked, how MITRE techniques are attached per hop, and how choke points tell you the one fix that severs the most paths.

How the graph is built

After every scan, the Attack Path engine ingests results from the platform's 29 engines into a Neo4j property graph:

Nodes are every resource in the asset inventory — EC2 instances, S3 buckets, IAM roles, Lambda functions, RDS databases, Kubernetes pods, secrets, and the rest — carrying their properties, findings, and classification.

Edges are relationships that represent possible attacker movement. They are produced by ~25 catalog-driven edge derivers, each specialized in one kind of evidence:

• IAM policy derivation — role assumption, PassRole, resource-policy access
• Network exposure — internet-facing endpoints, load balancer chains
• Security group rule matching — which sources can actually reach which ports
• KMS and encryption relationships — who can decrypt what
• CDR behavioral edges — movement actually observed in audit logs
• Public-exposure classification — is-public on buckets, snapshots, images

The resulting edge types read like attacker verbs: can-assume, can-read, can-write, can-reach, can-escalate, is-exposed.

Edge verification across five domains

A candidate edge is not enough — a security group may permit traffic that IAM forbids, or a policy may grant access a network path never reaches. Before an edge is marked CONFIRMED, it is cross-checked against evidence from five security domains: identity, network, configuration, data, and behavioral signals. Only confirmed edges participate in path traversal, which is why the engine produces short lists of real paths instead of thousands of theoretical ones.

Path traversal

The engine runs BFS traversal from entry points toward crown jewels:

• Entry points — internet-exposed endpoints, publicly readable storage, externally assumable roles. Classification is catalog-driven, so new exposure patterns are added without code changes.
• Crown jewels — production databases, secrets managers, classified data stores. Also catalog-driven, plus your own tags (see below).

Every discovered path is ranked by:

• Step count — shorter paths rank higher
• Node severity — paths traversing Critical findings rank higher
• Blast radius — paths reaching high-value assets rank higher
• Exploitability — EPSS probability and CISA KEV data are incorporated for CVE-adjacent hops

Crown jewel configuration

Define crown jewels in three ways:

1. Tag resources directly in the console
2. Import existing cloud provider tags (env=production, classification=critical)
3. Let Data Security classification auto-tag stores containing PII, PCI, or PHI

Crown jewel assets receive a risk multiplier in the FAIR risk engine — every attack path terminating at a crown jewel carries a boosted exposure score. Without any tags, the engine falls back to heuristics: managed databases, secrets managers, and resources tagged env=prod are treated as implicit crown jewels.

Per-hop MITRE ATT&CK chains

Every hop in a path is tagged with the MITRE ATT&CK technique an attacker would use to take it, and the engine tracks capability accumulation along the path — what the attacker holds (credentials, network position, data access) after each hop. The result reads like a red-team narrative: entry, escalation, lateral movement, objective.

Toxic combinations

Toxic combinations are pairs (or triples) of findings that individually score as Medium but together enable a Critical attack chain.

• Finding A: EC2 instance has IMDSv1 enabled (Medium — SSRF vector)
• Finding B: Instance profile has s3:* permissions (Medium — overprivileged)
• Together: SSRF, then IMDSv1 credential theft, then full S3 access — a Critical breach path

Onam detects these combinations automatically and surfaces them as unified findings with an aggregate severity of Critical.

Choke points

Choke points are first-class objects in the graph: nodes or edges that many attack paths share. Fixing one choke point severs every path that runs through it. The console ranks them as the Top 5 choke points for your estate, and for each one shows:

1. The fix — for example, remove a public entry point, restrict an overprivileged role, or patch a Critical CVE on a pivot node
2. The number of attack paths it severs
3. The estimated risk reduction in dollars, from the FAIR risk engine

Remediate choke points before individual paths. One choke-point fix routinely closes 10+ paths at once — it is the highest-leverage action the platform can recommend, and the Top 5 list is the best default agenda for your weekly security review.

Integration with other engines

FAQ

How long does graph construction take? Graph construction runs automatically after every scan — typically 3–8 minutes for estates up to 10,000 resources. For very large environments (100,000+ resources), incremental updates apply only to changed nodes.

Can I export attack paths for reporting? Yes. Paths export as PDF reports (executive summary plus technical detail) or as JSON for SIEM/SOAR ingestion via GET /api/v1/attack-paths.

What if I have no crown jewels tagged? The engine still runs using its catalog heuristics — managed databases, secrets stores, and production-tagged resources are implicit crown jewels until you refine the list.

Next steps

• Threat Detection — how posture, behavior, and correlation fit together
• Risk Quantification — the dollar figures behind path ranking
• CIEM — the identity chains that become graph edges
• Book a demo — see your own Top 5 choke points