Which connections actually hold?
A vulnerable service, an overprivileged account, and a sensitive repository can appear in the same report without forming a usable route. The proposed path depends on reachability, permissions, timing, and the behavior of the controls between them.
Treat the route as a set of linked claims. For each connection, ask what must be true, what evidence supports it, and what would break it. A diagram helps organize those questions; it does not replace the answers.
Black Atlas’s published attack-path service describes analysis of linked exposure rather than isolated findings. Its catalogue also states that service definitions are not deployment records. The guide below is an original preparation method, not a result from that service.
Prepare evidence for the links
| Evidence | Question it helps answer |
|---|---|
| Asset and service inventory | What exists, who owns it, and which asset matters to the decision? |
| Network and trust boundaries | What can communicate, and where is access restricted? |
| Effective identity permissions | What can the identity actually do under the relevant conditions? |
| Configuration and control records | What should block the route, and what evidence supports that expectation? |
| Time and collection scope | Do the observations describe a compatible period and the same environment? |
Keep only information authorized for the review. The preparation checklist can use high-level descriptions until an approved channel and handling rules are in place.
Inspect a simple example
Illustrative path. The links require verification.
A plausible path is a question.
An exposed service, a privileged identity, and a sensitive asset may form a route. Each connection still needs evidence. This diagram shows a fictional scenario, not an observed incident.
REVIEW STATE / HYPOTHESISSeparate possibility from supported reachability
In the example, a service connects to an identity and a data asset. Suppose the identity’s relevant permission has not been checked. That gap changes the conclusion: the route remains a hypothesis.
A useful review identifies the missing permission evidence and the smallest authorized check that could resolve it. It should also ask whether a control interrupts the route and whether that control was observed under the same conditions.
MITRE ATT&CK can supply names for observed behaviors. A technique label gives the team a common vocabulary; it does not verify an individual connection.
What the decision record should contain
- The asset and boundary being evaluated.
- Evidence and timestamps for each claimed connection.
- Conditions that enable or interrupt the route.
- Unresolved links and how they affect the conclusion.
- The reviewer and the next authorized check.
Know what the map cannot establish
An unobserved route is not necessarily impossible. A supported route is not a prediction that an incident will occur. Missing inventory, changing permissions, and incomplete visibility can all change the picture.
Do not turn a count of diagram nodes into a risk score without a justified model. Prioritize a review by asset importance, evidence strength, plausible consequences, and the scope of authority. See control validation for the next question: what demonstrates that a proposed interruption works?
Sources & context
- Black Atlas attack-path service ↗Primary description; environment-specific scope must be confirmed.
- MITRE ATT&CK resources ↗Behavioral terminology; not proof of local reachability.
- Black Atlas limits ↗No claim of complete attack-path coverage.
Sources reviewed 18 October 2026. First-party descriptions establish the source’s stated approach; they are not independent validation of security outcomes. About our sources.