Summiting the Pyramid

How detection and mitigation robustness ratings are derived from technique definitions — and what they tell you about evasion resistance.

What is STP?

Summiting the Pyramid (STP) is a framework from MITRE Engenuity's Center for Threat-Informed Defense that rates detection rules by their robustness to attacker evasion. The core question is: how much does the attacker have to change their behaviour to make this rule miss?

A rule that fires on a specific IP address is burned the moment the attacker rotates infrastructure. A rule that fires on the act of writing code into another process's memory is difficult to evade without abandoning the technique entirely. STP makes this intuition precise.

The five levels

This framework uses a five-level scale. STP 4 is not used — the field taxonomy produces no natural category between Execution Medium and Invariant.

STP	Category	What the rule gates on	Attacker cost to evade
5	Invariant	Fields whose values cannot change without abandoning the technique. These fields are the technique definition.	Must stop performing the technique entirely.
4	Not used	No natural category exists between Invariant and Execution Medium. Adding more conditions to a medium-scoped rule does not raise its ceiling — the rule still misses when the attacker switches medium.
3	Execution Medium	The binary, interpreter, or protocol through which the technique was triggered. Overlaps heavily with LOLBin detection.	Switch to a different Execution Medium — the technique is unchanged.
2	Attacker Controlled	Values the attacker sets freely: tool hashes, binary names, command-line arguments, C2 domain patterns.	Recompile, rename, or modify a string.
1	IoC-specific	Indicators of compromise: file hashes, domain names, IP addresses.	Rotate infrastructure. Cost is near-zero for a prepared attacker.

STP is derived, not assigned

In ATT&CK But Better, STP ratings are not heuristic labels applied after the fact. They fall out of the technique definition automatically, via the OCSF field taxonomy.

Every technique is defined as: <Actor> <Action> <D3FEND artifact class>. Each OCSF field on the technique's event is then classified into one of three roles:

Invariant — Fixed across all instances of the technique. The attacker cannot change this value without abandoning the technique entirely. A rule gating only on invariant fields has an STP 5 theoretical ceiling.

Attacker Controlled — Freely set by the attacker between uses. Rules gating on these fields are trivially evaded by changing a string, recompiling, or rotating infrastructure. STP 1–2 ceiling.

Variable — Varies per instance but is not freely chosen by the attacker — typically victim-side or OS-assigned. Must be present for the technique to occur, but cannot be controlled between uses.

The STP ceiling of any rule is determined by the highest-risk field it gates on:

STP 5 Rule gates only on invariant fields. Defines the technique regardless of how it was triggered.

STP 3 Rule includes a field scoped to an Execution Medium (binary name, interpreter, protocol). Adding more conditions does not raise the ceiling — if the attacker switches medium, all conditions miss.

STP 2 Rule gates on attacker-controlled values: hashes, IP addresses, command patterns, binary names. The attacker changes one string and the rule misses.

STP 1 Rule gates on IoCs — specific file hashes, domain names, IP addresses. Burned on first pivot.

A concrete example: the definitional Sigma rule for T1003.001 LSASS Memory gates on target.process.name = lsass.exe — an invariant field the attacker cannot change without reading credentials from a different process (which is a different technique). That rule is STP 5.

A Sysmon-based rule gating on Image|endswith: \mimikatz.exe is STP 2 — the binary name is attacker-controlled. A rule gating on ParentImage|endswith: \powershell.exe is STP 3 — powershell.exe is an Execution Medium.

Hard ceilings

The STP level of a rule is bounded by its lowest-robustness field constraint. You cannot raise the ceiling by adding more conditions:

STP 3 ceiling — Execution Medium constraint

A rule that includes actor.process.file.name = powershell.exe has a hard STP 3 ceiling, regardless of how many additional conditions are stacked on top of it. The attacker replaces PowerShell with Bash, cmd.exe, or a custom interpreter. Every additional condition becomes irrelevant the moment the medium changes.

Three STP 3 rules covering PowerShell, Bash, and Python do not combine to exceed STP 3. The attacker uses a fourth medium and all three rules miss.

This is why Execution Medium–scoped detection rules are samples in this framework, not canonical definitions. They are displayed on each technique page alongside the definitional STP 5 rule to make the ceiling cost explicit — not to suggest they are equivalent.

Theoretical vs. practical STP

The derivation above establishes the theoretical STP ceiling — what a rule must gate on to have STP 5 robustness for this technique. Whether that ceiling is achievable in practice depends on two separate questions that this framework does not answer for you:

Do your sensors observe the invariant field? An STP 5 rule for LSASS Memory requires a telemetry source that logs target.process.name on cross-process read events. Not all EDR products expose this field in all configurations.

Can the attacker suppress the observation? A sufficiently privileged attacker may be able to tamper with sensors or logging infrastructure. This is a separate evasion class from changing technique implementation.

Ontological invariance gives you the ceiling. Achieving it in your environment requires sensor coverage analysis that goes beyond what any framework can do for you.

STP for mitigation

The same logic applies to mitigations. A control that blocks a specific Execution Medium — disabling PowerShell — has a hard STP 3 ceiling, because the attacker switches medium. A control that prevents the artifact modification that defines the technique — for example, Windows Arbitrary Code Guard preventing cross-process memory writes — operates at the technique level and is STP 5.

One useful output of this framework is the explicit statement: No STP 5 mitigation exists. This tells defenders that detection is the primary lever for that technique, and that any available mitigations have a ceiling that a prepared attacker can exceed by switching implementation.

Mitigation STP has additional dimensions not present in detection STP — operational cost, feasibility, and partial mitigation coverage — that a complete framework should address. This is ongoing work.

STP annotations in the Threat Hunter's Digest

Each Sigma rule in the Threat Hunter's Digest carries an STP annotation derived from the field taxonomy above. The annotation identifies the ceiling category and the specific constraint responsible for it:

STP 3 — Execution Medium

Rule gates on Image|endswith: \powershell.exe. The attacker replaces PowerShell with another interpreter and the rule misses. Hard ceiling regardless of additional conditions.

STP 2 — Attacker Controlled

Rule gates on ImageLoaded|endswith: \truesight.sys. Driver filename is attacker-controlled — renaming the file evades the rule. The vulnerable driver's behaviour is unchanged.

STP 5 — Invariant

Rule gates on target.process.name = lsass.exe. This field is invariant to the LSASS credential dump technique — it cannot change without abandoning the technique.

The annotation is a ceiling, not an operational recommendation. A rule at STP 2 may be entirely appropriate for a detection programme that can tolerate the evasion risk and needs immediate signal on known tooling. The annotation tells you what you are accepting, not whether to accept it.