When should a detection rule carry an ATT&CK sub-technique ID rather than the parent?
answer
- match the label to the logic
- can the rule separate the siblings
- specific label, unbranched condition
- under-claiming hides the gap too
- the label is read without the rule
basics
~20 sLabel at the granularity the logic can actually separate. A sub-technique ID claims the rule distinguishes that procedure from its siblings. If the rule fires identically on all of them, the parent is the honest label; if it only ever catches one, the parent hides that.
solid answer
~50 sThe test is whether the rule's condition reads whatever distinguishes the sub-technique from its siblings. Take a rule over the Kubernetes API audit stream that matches `objectRef.subresource: exec` — it fires whether the requested command was `sh`, `python` or `env`, because it never inspects the command at all. That rule can carry the parent, not a sub-technique for a specific interpreter: the narrower label would advertise a distinction the logic does not make, and the next engineer trusting it would believe you separate the variants. The error runs both ways. A rule that only matches one interpreter and is tagged with the parent under-claims: it makes the rule look broader than it is, and hides which variants you actually miss. So: sub-technique when the logic branches on the distinguishing evidence, parent when it does not, and never a sub-technique picked because it sounded more precise.
go deeper
Know that sub-technique identifiers are variants of a parent behaviour and that using one is a stronger claim than using the parent.
Be ready to apply the test out loud on a rule condition you are shown: name the field that would distinguish the variants and say whether the logic reads it.
Demonstrate both failure directions, including under-claiming, and explain what a wrong label costs the next person who searches by behaviour instead of reading the query.
Set the convention for a whole rule set: who may attach a sub-technique, what evidence is required, and how labels are re-examined when a rule's condition changes.
## The granularity rule in one line **Label a rule at the granularity its own condition can distinguish.** Everything else in this topic is a corollary. ATT&CK sub-techniques (`T####.###`) are procedural variants of a parent behaviour. Attaching one to a rule is a *stronger* claim than attaching the parent: it says the rule separates that variant from its siblings, so that a firing means this variant and not another. ## Overclaiming: the common direction Consider a multi-tenant Kubernetes platform. A rule over the API server audit stream fires on any request with `verb: create`, `objectRef.resource: pods`, `objectRef.subresource: exec` — someone has opened a command channel into a running container. The author is tempted to tag it with a sub-technique for a Unix shell, because that is what people usually exec. But the condition never reads the requested command. A request whose URI carries `command=sh`, one carrying `command=python`, and one carrying `command=env` all match identically. The rule cannot tell you which happened, so a sub-technique identifier on it is an advertisement the logic cannot honour. The honest label is the parent — and in this case a better label still is the container-administration technique, because *the way the command was run* (through the orchestrator's API rather than a process on the node) is what the rule actually established. The damage from overclaiming is not abstract. Labels are what other people search. An engineer asking "what do we have for this specific variant" gets back a rule that fires on all of them, concludes the variant is handled, and stops looking. A red teamer executing exactly the sibling variant finds the rule fires and reports it as caught, when in fact anything in the family would have fired. ## Under-claiming: the direction people forget The reverse mistake is real and less discussed. A rule that only matches one narrow procedure — say, it keys on an artefact only one interpreter produces — but is tagged with the parent tells readers you cover the whole family. Now the parent looks addressed and nobody writes the rules for the other variants. Under-claiming hides the shape of your gap. So the parent is not automatically the safe choice. It is the correct choice when the logic genuinely does not distinguish; it is a different error when the logic distinguishes and you chose not to say so. ## When the label should move - **The condition gains a branch.** If you extend the rule to read the requested command and treat interpreters differently, the sub-technique claim becomes supportable — for the branch that makes it. - **The distinguishing field turns out to be unreliable.** A field that is optional, easily forged by the party you are watching, or only present at some collection levels cannot underwrite a sub-technique claim, even if the rule reads it. What the field records also matters: a value naming only the entrypoint a session was started with does not tell you what was run afterwards inside that session. - **ATT&CK has no sub-technique for the distinction you make.** Then tag the parent and put the procedural detail in the rule's own description. Do not invent an identifier; a fabricated ID silently breaks every downstream consumer that resolves identifiers against the published catalogue. ## The label is a promise to a reader, not a filing decision The question to ask before committing an identifier is not "which one fits best" but "if someone acts on this label without reading the rule, what will they wrongly believe?" If the answer is "that we separate variants we do not separate," narrow the claim to the parent. If it is "that we cover a family we cover one member of," go specific. ## What to say in an interview State the test — granularity the logic can distinguish — then give both failure directions with a concrete condition, and finish on the consumer: the label exists so someone else can act on it without reading your query, which is precisely why it must not promise more than the query delivers.
- Give a case where labelling with the parent is the dishonest choice.A rule that can only catch one interpreter — it keys on an artefact only that interpreter leaves — but is tagged with the parent behaviour. Readers conclude the whole family is addressed, so nobody writes rules for the other variants. Here the narrower label is more honest, because it makes the shape of the gap visible instead of papering over it.
- Your rule does read the field that distinguishes the variant. Is the sub-technique label automatically justified?Only if the field is trustworthy for that purpose. Ask whether it is always populated, whether it can be set by the party being watched, and whether it records what you think — a value naming the entrypoint of a session says nothing about what was run inside it afterwards. An unreliable field makes the sub-technique claim as hollow as never reading one.
- What if the distinction your rule makes has no sub-technique in ATT&CK?Tag the parent and describe the specific procedure in the rule's own description or test cases. Never mint an identifier: anything downstream that resolves identifiers against the published catalogue will silently drop or mis-resolve a fabricated one, and you lose the single benefit of using a shared vocabulary at all.
saying these in an interview costs you the question
- Picks the sub-technique because it sounds more precise
- Believes the parent label is always the safe choice
- Ignores that the rule never reads the distinguishing field
- Invents a sub-technique identifier when none exists
- Treats labelling as filing rather than a claim