Join our Newsletter — 33% off our NHI Course

Procedure

A procedure is the specific way an adversary carries out a technique in a real environment. Two attackers may use the same technique but follow different procedures based on tooling, access, or operational habits. Procedure-level analysis helps defenders build more precise detections than technique labels alone.

Expanded Definition

In adversary-focused analysis, a procedure is the concrete method used to execute a technique under real-world conditions. It captures the sequence of actions, tooling choices, timing, account usage, and environmental adjustments that make an attack operational rather than theoretical. The distinction matters because the same technique can be carried out through multiple procedures, each leaving different evidence and demanding different detection logic. Within threat modelling and incident analysis, procedures help defenders move from broad labels to actionable understanding.

Procedure is not a universal governance term with one fixed standards definition, and usage in the industry is still evolving across threat intelligence, detection engineering, and purple-team workflows. In practice, analysts often compare observed procedure details with established technique catalogs such as MITRE ATT&CK and organisational telemetry to understand how an intrusion actually unfolded. For security teams, the value lies in specificity: procedures reveal the attacker’s habits, constraints, and adaptation patterns, which technique names alone do not capture.

The most common misapplication is treating a technique label as if it fully describes the intrusion, which occurs when analysts stop at the category name and miss the concrete steps that determine whether a detection will work.

Examples and Use Cases

Implementing procedure-level analysis rigorously often introduces more investigative overhead, requiring organisations to weigh richer detections against the time needed to normalize and compare event details.

  • An attacker may use credential dumping as a technique, but one procedure may rely on built-in administrative tools while another uses custom malware, creating different telemetry and response priorities.
  • During lateral movement, the same technique can appear as remote service creation, scheduled task abuse, or valid cloud admin console activity. Procedure detail helps analysts distinguish those paths.
  • A phishing campaign may use the same initial access technique, yet the procedure differs depending on whether the adversary harvests credentials through a fake login page, OAuth consent abuse, or token theft.
  • Detection engineers can convert observed procedures into rules and hunts by aligning command patterns, parent-child process chains, and account behavior with NIST Cybersecurity Framework 2.0 detection and response outcomes.
  • Threat intelligence teams use procedures to assess whether two incidents share operational DNA, even when the toolset or infrastructure has changed between intrusions.

Why It Matters for Security Teams

Procedures matter because defenders rarely stop an intrusion by knowing only the technique category. Security teams need the operational details that show how the adversary authenticated, what tooling was used, which privileges were required, and how the actor adapted after encountering friction. That is especially important in environments with human and non-human identities, where a procedure may involve abusing service accounts, API tokens, delegated permissions, or automation credentials. In those cases, the procedure exposes how identity trust was converted into execution authority.

For NHI and agentic AI security, procedure analysis also helps identify whether an agent, script, or workload was used as the attacker’s execution layer rather than the primary target. That distinction is increasingly important when monitoring tool-to-tool interactions, secret usage, and privileged workflows. Frameworks such as MITRE ATT&CK and the MITRE ATT&CK knowledge base support this operational view by cataloging how techniques are commonly carried out, while detection teams translate those observations into telemetry and response logic.

Organisations typically encounter the cost of weak procedure analysis only after repeated detections fail to stop the same adversary, at which point procedure becomes operationally unavoidable to address.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATLAS, OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 DE.CM-1 Procedure detail improves continuous monitoring by showing how attacks are actually executed.
MITRE ATLAS ATLAS catalogs adversarial behaviors and execution patterns relevant to procedures.
OWASP Non-Human Identity Top 10 NHI security depends on understanding how procedures abuse tokens, secrets, and service identities.
OWASP Agentic AI Top 10 Agentic AI guidance highlights how procedures can abuse tools, autonomy, and execution authority.
NIST AI RMF GOVERN AI RMF governance requires understanding operational behaviors, including adversary procedures.

Use procedure-level observations to tune detections and monitor for repeatable adversary behaviors.