Using Attack Flow to Design Multi-Step Detections

A list of techniques loses the shape of an intrusion

A technique list can tell you that credential theft, account access, privilege change, and data collection are relevant. It does not show which identity connects them, which action must precede another, where the path branches, or which asset carries the consequence.

Attack Flow represents behavior as connected actions, assets, conditions, and relationships. For detection engineering, its value is not the diagram itself. The value is making the hypothesized path explicit enough that you can ask where evidence should exist and which interruption would matter.

Begin with a bounded scenario. “Cloud compromise” is too broad. “A stolen user session grants an application authority, accesses a sensitive mailbox, stages selected messages, and creates an external sharing path” gives you actors, state transitions, and possible observation points.

Model actions and conditions before attaching detections

Describe what must happen without assuming the telemetry. A user session is obtained. Authority is granted. A resource is accessed. Data is collected. An external path is created. Add conditions such as required role, tenant relationship, or approval state when they change whether the next action is possible.

Now add alternatives. The attacker may reuse an existing application instead of creating a grant. Collection may occur through export, synchronization, or repeated reads. Branches prevent one observed path from becoming an accidental claim about every path to the objective.

Only after the behavior is coherent should you attach evidence. Otherwise available log fields can distort the threat model into the path your tools happen to see. The detection hypothesis for each opportunity should state what the behavior predicts, where it can be observed, and what could contradict the relationship.

Place opportunities where the evidence changes the decision

Not every node deserves an alert. A common sign-in may be weak evidence but useful context. A new grant may justify review. A grant followed by access and external sharing may justify a faster incident decision. Mark the consumer and useful decision at each opportunity.

Look for transitions that are difficult to omit and places where independent sources meet. Identity audit may show authority. Resource audit may show use. Sharing audit may show a new external relationship. Their agreement can strengthen the explanation, while disagreement can reveal missing data or an alternative path.

Preserve source boundaries. A common trace or session key helps relation but does not make every event causal. State which edge is directly observed, which is inferred from entity and time, and which exists only in the threat model.

Design correlation around partial and late evidence

Real flows are incomplete. Sensors miss steps, events arrive out of order, and legitimate activity can enter the middle of a modeled path. A correlation that requires every step may be precise in testing and blind in production.

Decide which steps are required for the claim, which add confidence, and which merely add context. Define how long state is retained, which entity keys join activity, and how concurrent flows for one user remain separate. Consider whether a later event can update an earlier assessment rather than being discarded outside a fixed window.

Test partial paths and overlaps. Two grants and two resource accesses close together can be paired incorrectly. A delayed first step can make a valid sequence appear reversed. These are analytical failures, not implementation trivia, because they change the story presented to the consumer.

Use the flow as a living explanation of coverage

After validation, annotate each opportunity with its evidence source, analytic version, tested variations, current health, consumer, and limit. Mark behavior nodes that have prevention but no independent detection, and branches whose evidence is unavailable. The flow becomes a reviewable explanation of the portfolio rather than a picture of assumed control.

When an incident occurs, compare observations with the modeled path. A new branch can become a revised threat hypothesis. A missed event can reveal an observation gap. An alert that did not change a decision may belong as enrichment instead. Preserve those lessons with the model.

Attack Flow is most useful when it keeps three things separate: the behavior you believe is possible, the evidence you actually observed, and the defensive decisions you can justify. Connecting them supports multi-step detection. Confusing them turns a clear diagram into false certainty.