Using Attack Flow to Model the Procedure Layer Missing in ATT&CK

In this post

In an earlier post on Attack Flow, I focused on how the model works technically.

This post is about why procedures are the missing operational part of most TTP research.

ATT&CK gives us tactics and techniques.

What is often missing is procedure-level modelling: the concrete way a technique is executed in a real environment.

That gap is often the difference between “coverage on paper” and “defence in production.”

In this post we’ll cover:

what technique mapping misses
why procedures are the missing layer in TTP analysis
what procedures add in real SOC workflows
practical case studies that show the difference
why Attack Flow is a good way to represent procedures in STIX-native environments
a practical POC

Procedures: the missing part of TTPs

In theory, “TTPs” include tactics, techniques, and procedures.

In practice, many programs mostly model tactics and techniques.

That creates a blind spot.

A technique tells you a class of behavior.

A procedure tells you the exact operational implementation of that behavior:

what command or API is used
in what sequence
against which assets
under what conditions
with what expected effect

Without procedures, ATT&CK mapping can become taxonomy without execution context.

With procedures, ATT&CK becomes operationally testable.

The coverage problem nobody likes to admit

Many teams have an ATT&CK heatmap that looks healthy.

PowerShell covered. Credential access covered. Lateral movement covered.

Then an incident lands and those same teams discover the painful gap: they covered categories, not execution paths.

This is the key distinction inside TTP work:

Technique mapping tells you what an adversary can do.
Procedure mapping tells you how they actually did it in your environment.

That “in your environment” part is the whole point.

Procedures include operational details that drive outcomes:

sequence
timing
target asset class
identity context
command chains
conditional branching

Without these, you can build a technically correct ATT&CK model that is still operationally weak.

What changes when teams move from techniques to procedures

Across CTI, detection, and response workflows, the same shift appears once teams move to procedure-level modelling.

1) Ransomware response becomes sequence-aware, not label-aware

During a ransomware intrusion, the difference is usually not whether “execution” or “impact” was covered in ATT&CK.

The difference is whether the team models and detects the actual chain, for example:

WMI-triggered PowerShell
shadow copy deletion command chain
scheduled task deployment
targeting backup systems during maintenance windows

When teams model this as a procedure, incident response can triage and contain based on path progression, not isolated alerts.

2) Threat intelligence triage focuses on novelty

At technique level, many reports look like repeats.

When procedures are extracted, teams can quickly separate:

known procedure variants already covered
truly new procedural behavior requiring engineering effort

This changes intelligence from “more reading” into a prioritization engine.

3) Detection engineering shifts from tool signatures to attacker outcomes

Tool-centric detections degrade as adversaries swap tooling.

Procedure-centric detections stay useful because they anchor on behavior:

memory access patterns for credential access
authentication and movement anomalies for lateral spread
persistence state changes (e.g. tasking/autoruns) before impact

Detection strategy becomes: detect objective completion, regardless of utility used.

4) Risk decisions become concrete

Technique labels are often too broad for hard prioritization decisions.

Procedure mappings make risk specific:

which systems are targeted
when they are targeted
what attacker preconditions must be true
what business process is disrupted if the chain succeeds

This gives leadership an evidence-backed basis for control investment.

5) Adversary emulation validates realistic paths

Technique checklist exercises are useful, but often too generic.

Procedure-led emulation tests realistic operational chains end-to-end, which improves:

control validation fidelity
speed of gap discovery
quality of purple-team findings

Why Attack Flow can help

If the problem is sequence and context, we need a model that captures sequence and context.

STIX itself does not have the concept of a Procedure object.

Attack Flow gives us that while staying STIX-native.

It lets us represent:

ordered attack actions
branching through conditions/operators
command context through process objects
target context through attack assets and linked STIX objects

Most importantly, it lets us represent procedure chains as first-class data objects, not analyst narrative fragments lost in PDFs or tickets.

That makes procedures queryable, testable, and reusable.

A practical POC: procedure mapping with Attack Flow

Let’s make this concrete.

Model one high-impact ransomware procedure end-to-end in Attack Flow, then link it to detections, assets, and controls.

Procedure chain:

WMI-triggered PowerShell
shadow copy deletion
scheduled task deployment
backup server targeting during maintenance windows

Full flow view:

Step 1: WMI-triggered PowerShell execution

Procedure - WMI-triggered PowerShell execution

This action maps to ATT&CK Execution (TA0002) and WMI (T1047) and includes command context via a STIX process object.

Step 2: Shadow copy deletion

Procedure - Shadow copy deletion

This maps to Impact (TA0040) and Inhibit System Recovery (T1490) and includes detection mapping via an indicator:

"pattern": "[process:command_line MATCHES '(?i).*vssadmin\\\\s+delete\\\\s+shadows.*']",

ICYMI: In my last post I showed how to link to Sigma Rules to Attack Flows.

It also links targeted assets (attack-asset) to core STIX infrastructure.

Step 3: condition-based progression to scheduled task deployment

Procedure - Scheduled task deployment

Between step 2 and step 3, an attack-condition captures attacker logic:

Target host is backup server AND operation occurs within maintenance window.

With this pattern, procedure modelling remains composable, standards-aligned, and portable across STIX-native tooling.

In summary

Tactics and techniques are essential, but incomplete on their own.

Procedures are the missing part of TTPs in many ATT&CK programs.

If your model cannot show how an attack path unfolds across sequence, conditions, assets, and controls, you are measuring taxonomy, not readiness.

Attack Flow gives us a practical way to close that gap without abandoning ATT&CK or STIX.

The immediate next step is simple: pick one high-impact procedure in your environment, model it end-to-end, and validate whether your detections and controls break the chain in practice.