name

tired-labs-methodology

description

TIRED Labs TRR/DDM methodology - canonical definitions for the DDM inclusion test, structural conventions, procedure vs instance distinction, and discipline-neutrality rules. Required by ALL agents working on TRR research, DDM construction, TRR writing, or TRR review. Supporting files cover failure modes (FM1-FM10), Action Object naming, DDM conventions, and TRR formatting standards - load on demand.

TIRED Labs Methodology - Single Source of Truth

This skill contains the canonical methodology rules for Technique Research Reports (TRRs) and Detection Data Models (DDMs). All agents reference this skill for definitions rather than maintaining their own copies.

The four sections below are loaded with every agent that activates this skill. Topic-specific reference content lives in supporting files and should be loaded on demand.

The DDM Inclusion Test

Every operation considered for a DDM must pass all three simultaneously:

Essential: The technique cannot succeed without this operation. If you can skip it and still accomplish the technique, it doesn't belong.
Immutable: The attacker cannot change or avoid this operation - it is a fixed requirement of the underlying technology. (Configurations that feed the operation may be administrator- or attacker-modifiable; the operation itself cannot.)
Observable: Some telemetry source can theoretically detect this operation, even if that source isn't deployed in every environment.

If an operation fails any one of these three criteria, it does not belong in a DDM. State the verdict explicitly for each operation: "Essential: yes - [reason]. Immutable: yes - [reason]. Observable: yes - [source]." No hedging. No "likely" or "probably" or "appears to be."

Immutability applies to operations, not configurations. The DDM inclusion test asks whether the operation is immutable - meaning the technique cannot succeed without it. The configuration that feeds the operation (handler mappings, registry settings, group policy) may be administrator- or attacker-modifiable. Do not confuse "this operation cannot be skipped" with "this configuration cannot be changed."

Example: a registry key that can be set to multiple values (any of which makes the technique succeed) still produces the same essential operation when the technique runs. The key's value is the configuration; the act of reading or writing the key during technique execution is the immutable operation.

Automatic exclusions (never put these in a DDM):

Tool names — on-prem (Mimikatz, Cobalt Strike, China Chopper, PowerSploit, Metasploit, Rubeus, Impacket, BloodHound) and cloud (AADInternals, ROADtools, TokenTactics, Pacu, aws_consoler)
Command-line flags and parameters
File names and paths chosen by the attacker
Delivery methods (exploit, RDP, WebDAV, phishing, stolen credentials)
Encoding or obfuscation choices (Base64, XOR, encryption method)
Optional reconnaissance steps (enumeration, scanning)
Programming language or script variant
Invocation mechanism (COM object, .NET API, native API, script directive)

Structural Conventions

Prerequisites vs. Pipeline:

Operations that happen before the main execution flow (possibly hours or days before, like writing a file to disk) are prerequisites.
Model prerequisites as nodes with arrows feeding INTO the appropriate pipeline node - not as "Step 1" in a linear chain.
Visual placement: prerequisites above or to the left of the pipeline.

Sub-operations:

When an operation contains a notable sub-step that produces its own telemetry (e.g., "Compile ASPX" under "Execute Code"), model it as a sub-operation with a downward arrow from the parent.

Branch conditions:

When the DDM branches at a single operation (different execution paths), label each branch arrow with a conditional description.
Example: Execute Code -> Spawn Process: "if OS command" / Execute Code -> Load Assembly: "if in-process"
The branch labels describe outcomes (different essential operations), not invocation mechanisms. .NET API, COM object, native API, and similar mechanisms are automatic exclusions and never appear as DDM node names.

Multi-machine techniques:

Green circles (#68bc00): Source/attacker machine operations
Blue circles (#0062b1): Target/victim machine operations
Black (#000000): Shared, neutral, or infrastructure operations

External / non-observable prerequisites:

Gray border (#808080) with gray fill (#cccccc): Prerequisite operations that occur outside the observable boundary of the technique (e.g., a DNS record published at an external authority for a cloud-tenant verification flow, or an attacker-side artifact prepared before a remote operation).
Use only for prerequisite nodes that are essential to the pipeline but produce no telemetry within the system the TRR covers.
The TRR procedure narrative must explicitly call out the gray styling and explain why the operation is non-observable.

Procedures vs. Instances

A procedure is a unique pattern of essential operations - a recipe.
An instance is a specific execution of a procedure - a cake from the recipe.
Different tools executing the same essential operations = same procedure.
Different essential operation paths = different procedures.

The key question: "Does this change the essential operations, or just the implementation details?" If only implementation details change (different tool, different file extension, different encoding), it's the same procedure. If the essential operations themselves change, it's a new procedure.

Procedure boundaries are defined by essential operation outcomes, not by invocation methods. The mechanism used to reach an essential operation (COM object, .NET API, native API, script directive) is attacker-controlled and tangential. What defines the procedure is the outcome - e.g., Spawn Process vs. in-process operation.

When multiple execution paths share the same defining essential operation but differ in handler, prerequisites, role service dependencies, or upstream artifacts, document them as named variants within a single procedure rather than separate procedures. Differentiate prerequisites across variants - do not generalize into a single blanket statement if constraints differ.

Discipline-Neutrality Rules

A TRR is source material for any security team. It documents the technique; it does not prescribe the defensive response.

Banned phrases in TRR prose (any of these is an automatic review FAIL):

"primary detection opportunity" / "detection opportunity" / "detection point"
"high-fidelity signal" / "high-fidelity detection"
"defenders should" / "analysts should" / "SOC should" / "blue team should"
"best place to detect" / "provides visibility" / "key indicator for detection"
"should alert on" / "recommended detection" / "monitor for this"
"most reliable indicator" / "detection strategy" / "detection recommendation"
Any framing that implies "this is where you should look" - catches subtle FM1 patterns the explicit phrase list misses

Correct approach: State telemetry as technical fact. "This operation produces Sysmon 1 (ProcessCreate) telemetry where the parent process is w3wp.exe." That is a fact. Calling it "the primary detection opportunity" is a prescription.

No tool names in TRR prose. Describe the essential operation, not the tool. Tools appear in References only, for attribution.

Additional Resources

Load these files on demand when the topic applies to the work in front of you.

failure-modes.md — FM1-FM10 named definitions. Load when reviewing a TRR for known failure patterns or when the trr-prose-guard hook flags a violation.
action-object-naming.md — Action Object naming convention with comparison table. Load when constructing or reviewing DDM operation node names.
ddm-conventions.md — Node Property Convention, Telemetry Label Format, Per-Procedure Export Convention. Load when constructing DDMs, generating exports, or reviewing DDM JSON.
trr-formatting.md — TRR Formatting Standards (linter compliance), TRR Document Rules (scope, overview, narrative, telemetry presentation). Load when writing or reviewing the TRR document itself.