Before Tidal Cyber, I spent years at MITRE working on ATT&CK, including leading ATT&CK Evaluations. One word came up in almost every conversation about adversary behavior, and people meant something different by it each time: procedure.
An adversary procedure is the specific, documented implementation of one or more techniques used by an adversary to reach an objective. Techniques describe the methods an attacker uses to achieve tactical objectives. Procedures describe how the execution happens: the tools, commands, process relationships, dependencies, and the specific steps involved.
A recent LinkedIn discussion asked a fair question. If security teams use the word "procedure" in different ways, what are we measuring? The question deserves a clear answer. If your team defines procedures loosely, your coverage numbers may not reflect what your defenses actually address.
This post covers where the term comes from, why it gets confused, how procedures relate to MITRE ATT&CK techniques, and how Procedural Coverage gives you a more precise view of your defenses.
Where does the term "procedure" come from in cybersecurity?
The term has two roots in security: TTPs and standard operating procedures.
- TTPs (Tactics, Techniques, and Procedures) describe adversary behavior at three levels. Tactics are the goal. Techniques are the method. Procedures are the specific implementation.
- A Standard Operating Procedure (SOP) is a consistent checklist your team follows to run a workflow, such as triaging an alert.
In 2013, David Bianco introduced the Pyramid of Pain, placing tactics, techniques, and procedures (TTPs) at the top because they are among the most difficult aspects of an attack for adversaries to change. His central argument was that defenders could impose greater costs on attackers by focusing on how they operate rather than relying primarily on easily changed indicators such as hashes and IP addresses.
That same year, MITRE began developing ATT&CK, publicly released in 2015, to establish a common framework for understanding adversary tactics and techniques. While ATT&CK includes examples of how adversaries implement techniques, these procedure examples are not maintained as independent, structured objects within the framework. They document observed implementations but do not provide a comprehensive representation of the specific execution steps adversaries use.
This distinction is important. Understanding that an adversary uses a particular technique is not the same as understanding precisely how that technique is executed or whether existing defenses can disrupt it. Tidal Cyber extends ATT&CK by parsing and curating threat intelligence to identify specific adversary procedures, associating them with relevant techniques, and connecting them to defensive capabilities and detections. This enables organizations to move beyond broad technique-level coverage to a more precise understanding of how effectively their defenses address the ways adversaries actually operate.
What is an adversary procedure?
An adversary procedure is a concrete, implementation of one or more techniques an adversary, or a simulated adversary, uses to achieve an objective. It preserves the execution context around those actions:
- What was done
- How it was done
- Which objects and dependencies were involved, such as tools, processes, files, and data sources
- Which objective the execution served
How does a procedure differ from an indicator or observable?
An observable is a recorded or measurable event or artifact, such as a command, file, process, or network connection. An indicator is evidence or a pattern associated with potentially malicious activity. A procedure describes the specific implementation of one or more techniques, including how those actions are executed.
Example: an observable says rundll32.exe ran. A procedure says an attacker used rundll32.exe to call the MiniDump function in comsvcs.dll against the LSASS process and wrote its memory to disk, creating a dump that could then be used to extract credentials. The first gives you a data point. The second gives you something to detect, test, and measure.
This context keeps a procedure useful beyond one sighting or one actor name.
How do procedures relate to MITRE ATT&CK techniques?
MITRE ATT&CK provides a framework for understanding adversary activity. Tactics describe what adversaries are trying to achieve, while techniques and sub-techniques describe the methods they use to accomplish those objectives. Procedures provide the specific execution details of how adversaries implement those techniques in practice.
The relationship between procedures and techniques is not always one-to-one:
- One procedure, one technique or sub-technique. A procedure may describe a specific implementation of a single technique, such as dumping LSASS memory using a particular tool and method (T1003.001, OS Credential Dumping: LSASS Memory).
- One procedure, multiple techniques or sub-techniques. A procedure may involve several techniques working together to accomplish a specific objective. For example, an adversary may use PowerShell, process injection, and LSASS memory access as part of a single credential-dumping procedure.
- One technique, multiple procedures. Adversaries may implement the same technique through different tools, commands, scripts, or execution methods, each presenting distinct defensive considerations.
What defines a procedure is not the number of techniques associated with it, but the specificity of its implementation. A general attack path or campaign narrative is not necessarily a procedure simply because it contains multiple techniques.
Why this matters for defensive coverage
Technique-level coverage identifies whether defenses are mapped to a particular ATT&CK technique, but it does not necessarily establish whether those defenses address the specific ways adversaries execute it.
By mapping procedures to their associated techniques and defensive capabilities, Tidal Cyber provides a more precise understanding of which adversary execution methods are addressed, where coverage is partial or missing, and which defensive improvements should be prioritized.
What is Procedural Coverage, and why does technique coverage fall short?
Procedural Coverage shows whether and how your defenses address the specific procedures relevant to your threats. Technique coverage shows whether defenses are mapped to an ATT&CK technique. The gap between the two can obscure meaningful differences in defensive coverage.
Example: two organizations both show coverage for T1003.001, OS Credential Dumping: LSASS Memory:
|
|
Organization A |
Organization B |
|
Mapping |
Detection tied to a relevant adversary's procedure |
Generic rule mapped to the technique |
|
Built on |
The command path, parent-child process relationship, data source, and environmental dependency the adversary uses |
The technique label |
|
Dashboard status |
Covered |
Covered |
|
Detects the relevant execution |
Yes |
Unknown |
The technique label is the same. The defensive reality may differ. Procedure-level granularity exposes the difference without claiming certainty or universal protection.
Specificity also drives prioritization. You do not have time to treat every technique, detection, and gap as equally urgent. Procedure context helps you:
- Focus on the execution most relevant to your threats and environment
- Tune or build detections against concrete requirements
- Validate defenses against defined execution
Coverage and validation work together. Procedural Coverage shows which procedures defenses address and where coverage gaps exist. Validation shows how defenses performed against what you tested. One does not replace the other.
How does correlation turn procedures into action?
Correlation connects threat intelligence, adversary execution, and defensive capabilities to provide a more precise understanding of what matters, what is covered, and where to act.
In Tidal Cyber's Threat-Led Defense platform, correlation establishes relationships across:
- Relevant threats and the adversaries that pose them.
- Adversary procedures and procedure sightings that provide evidence of how attackers execute techniques.
- Correlating MITRE ATT&CK techniques and sub-techniques associated with those procedures.
- Assets and vulnerabilities that help establish relevance and exposure.
- Defensive capabilities and detections that address relevant techniques and procedures.
- Coverage gaps and recommended actions that identify opportunities to strengthen defenses.
- Validation evidence, where available, that provides additional confidence in whether defenses worked against what was tested.
No single correlation establishes defensive effectiveness on its own:
- A technique mapping does not establish whether a defense addresses a specific adversary procedure.
- A procedure sighting provides evidence of adversary execution, not proof that a defense works.
- The existence of a detection does not establish whether it is properly configured, applicable, or effective.
- Validation results provide evidence of what was tested, but should not be interpreted as proof of coverage beyond the scope of those tests.
By connecting these relationships, Threat-Led Defense helps security teams answer the questions that matter:
- Which threats are relevant to our organization?
- How do those adversaries execute attacks?
- Which techniques and procedures are addressed by our existing defenses?
- Where is defensive coverage full, partial, or missing?
- What have we tested, and what do the results tell us?
- Which actions should we prioritize to improve Defensive Effectiveness?
The result: A more precise, evidence-informed understanding of defensive coverage that helps organizations translate threat intelligence into prioritized action, strengthen defenses, and reduce the likelihood of attacker success.
Common misconceptions about procedure-level intelligence
Misconception 1: Procedures are only historical instances
Procedure sightings document observed adversary activity. When parsed, structured, and correlated with relevant threats and ATT&CK techniques, they provide a more precise understanding of how adversaries execute attacks.
This intelligence extends beyond documenting past activity. It helps organizations assess defensive coverage against specific adversary execution methods, identify gaps, and prioritize improvements. While procedures cannot predict every variation of a future attack, they provide evidence that makes defensive decisions more relevant and actionable.
Misconception 2: Procedure intelligence only answers "Did this actor target us?"
Determining whether a threat actor has targeted an organization is an important investigative question, but it represents only one application of procedure-level intelligence.
Threat-Led Defense uses procedure-level intelligence to understand how relevant adversaries operate and correlate their procedures with ATT&CK techniques, defensive capabilities, and detections. This helps security teams determine which threats matter, where existing defenses provide coverage, which gaps require attention, and what actions to prioritize.
Misconception 3: Procedure-level coverage is unmeasurable
Adversaries can execute the same technique in many different ways. Measuring every possible variation is neither practical nor necessary to establish meaningful defensive coverage.
Procedural Coverage focuses on a defined set of relevant threats and associated procedures, correlating them with defensive capabilities and detections to assess where coverage exists, where it is partial, and where gaps remain.
This provides a more precise measure of defensive coverage than technique-level mappings alone. Validation evidence, where available, adds confidence in whether defenses worked against what was tested, supporting a more complete assessment of Defensive Effectiveness.
Misconception 4: Procedures do not improve defensive coverage
Simply identifying an adversary procedure does not strengthen a defense. The value comes from understanding how that procedure is executed and whether existing defensive capabilities address it.
By correlating procedures with relevant threats, ATT&CK techniques, defensive capabilities, and detections, Threat-Led Defense reveals coverage gaps that broader technique-level mappings may obscure.
This enables security teams to prioritize specific improvements, strengthen existing defenses, and focus validation efforts where they can provide meaningful evidence of effectiveness.
Why Procedures Matter
MITRE ATT&CK provides a common framework for understanding adversary tactics and techniques. But mapping a defense to a technique does not establish whether it can address the specific ways an adversary executes it.
Two security products may cover the same technique yet perform very differently against the same procedure. That distinction matters.
Techniques provide a common language. Procedures provide the specificity needed to assess defensive coverage with greater precision. Validation adds confidence in whether defenses actually work against what was tested.
The question is no longer simply, "Are we covered against this technique?" It becomes, "How effectively do our defenses address the specific ways relevant adversaries execute attacks, and what should we do next?"
Ultimately, coverage is only as meaningful as the evidence behind it.
Where does this leave us?
In ATT&CK Evaluations, we examined how products detected or protected against steps in emulated adversary activity. Products associated with the same technique could behave differently against the same execution. The technique label matched. The defensive response did not.
This is why I care about the word procedure. Techniques give you a shared language. Procedures reveal the specific execution methods your defenses need to address. Procedural Coverage uses that specificity to assess defenses more precisely. Validation provides additional evidence of whether defenses worked against what was tested. I don’t think anyone needs to win the definition debate. Your team does need to agree on one definition before you report coverage. You also need to measure against something specific.
If you take one thing from this post, make it this. Ask your team what your coverage number actually measures. If the answer is a technique label, you have a map. If the answer is a set of relevant procedures, correlated to your defenses and supported by testing, you have evidence.
Evidence tells you where to spend your next hour, your next dollar, and your next detection engineering sprint.
At Tidal Cyber, that is what we built to make this possible.