What does an ATT&CK technique ID attached to a detection rule actually claim?
answer
- metadata, not a verdict
- it describes the rule's intent
- a firing can still be authorised
- tagged is not the same as detected
- specificity capped by what the logic separates
basics
~20 sIt claims what adversary behaviour the rule was written to catch. The label sits on the rule, not on any alert: a firing is not proof of malice, and the tag does not mean every variant of that behaviour is caught.
solid answer
~50 sA technique ID on a rule is a statement of authorial intent about the logic: this query exists because adversaries do this. Three consequences follow. It labels the rule, not the event — a rule tagged `T1609` (Container Administration Command) fires identically when a platform engineer execs a shell into a production pod at 02:00 to debug it, and that alert is a benign true positive while the tag stays exactly where it is. It says someone tried, not that the behaviour is caught: the log source may not arrive, the logic may be broken, the rule may only cover one procedure. And it is only as specific as what the logic can separate — if the rule fires the same way on every variant, it cannot honestly carry a sub-technique ID. The real payoff is shared vocabulary: you can find every rule touching a behaviour and describe a gap to another team without prose.
go deeper
Be ready to say in one sentence that the identifier labels the rule's intent, not the alert's verdict, and to give one example of a tagged rule firing on legitimate work.
An interviewer expects you to explain why a tagged rule is not coverage: the log source may be missing, the logic may be broken, and the rule may cover one procedure out of many.
Show the judgment of refusing a label the logic cannot support, and of separating the rule's tag from the disposition an analyst records on a single firing.
Own the convention: decide what technique labels mean across a rule set, who may add them, and what they are allowed to imply in anything the SOC publishes outside itself.
## What the ID is attached to ATT&CK technique identifiers (`T####`, with sub-techniques written `T####.###`) name adversary **behaviours**. When a detection engineer writes a rule, they normally record one or more of those identifiers in the rule's metadata alongside the author, the description and the log source. The thing newcomers get wrong is *what the identifier is attached to*. It is attached to **the rule** — to the logic — and it is a claim of intent: "this query exists because adversaries do this." It is not attached to the events the rule produces, and it is not attached to your estate. ## Three things the label does not say **It does not say a firing is malicious.** Take a rule over the Kubernetes API audit stream that alerts whenever someone creates a `pods/exec` request — a shell into a running container. Tag it `T1609` (Container Administration Command), because that is genuinely the behaviour an intruder uses to run commands inside a workload without ever dropping a file on a node. The same rule fires at 02:14 when a platform engineer on call shells into a payments pod to read a stuck queue. The alert is a *benign true positive*: the behaviour really happened, and it was authorised. The rule's label does not change, because the label was never a verdict about that person. **It does not say the behaviour is detected.** Intent is not efficacy. The rule may reference a field the platform team never enabled; the audit stream may have stopped arriving three weeks ago; the logic may cover one procedure out of six. A tagged rule is evidence that someone attempted the behaviour, which is a much weaker claim than "we would see it." **It does not say the rule catches every way the behaviour is done.** This is where labelling most often turns into a small lie. A technique with sub-techniques describes a family of procedures; a rule that fires identically on all of them can support the parent identifier and nothing narrower. ## What the label is genuinely for - **Search and grouping.** "Show me every rule we have that touches command execution inside containers" is answerable in one query when rules are labelled and answerable only by reading prose when they are not. - **Shared vocabulary.** A technique ID travels between the SOC, a red team, a vendor and a platform team without each of them defining terms. - **Describing a miss.** "We saw the exec but not what ran inside it" is vague; naming the technique the rule claims and the procedure it failed on is specific enough to act on. - **Pairing detection with a test.** A labelled rule can be matched to an execution of that behaviour, which is the only way to learn whether it fires — a rule's silence is not evidence it works. ## The two ways a label goes wrong **Overclaiming by specificity:** attaching a sub-technique ID when the logic never reads the field that distinguishes it from its siblings. **Overclaiming by breadth:** stacking every plausible technique onto one rule so it appears in more searches, which means the next engineer asking "what do we have for this behaviour" gets a rule that cannot detect it. ## Rule label versus case label There is a second, legitimate use of technique IDs that is easy to confuse with this one. An analyst working a confirmed intrusion may attach technique identifiers to the **case**, asserting from evidence that the adversary did these things. That is a claim about what happened. The identifier on a rule is a claim about what the rule looks for. Keeping the two apart is what lets you say, without contradiction, that a rule tagged with an adversary technique fired on an engineer doing their job. ## Answering this in an interview Lead with one sentence — it is intent metadata on the rule — and then give the triad: not a verdict on the alert, not proof of coverage, not a claim of completeness across variants. If you have a concrete case, use it: the same tag, one intrusion and one authorised debug session, and the tag does not move.
- A rule tagged with an adversary technique fires on authorised work. Do you remove the tag?No. The tag describes what the rule's logic looks for; the disposition on that one alert describes what this firing turned out to be. Removing the tag would break every search for rules touching that behaviour, and the next firing might not be authorised. If anything is wrong, it is the rule's precision or the report the alert landed in, not the label.
- Does an untagged rule detect any less than a tagged one?Not at all — labelling is metadata and changes nothing at query time. What you lose is everything downstream: you cannot enumerate rules by behaviour, cannot match a rule to an emulation test that exercises it, and cannot describe a gap to another team in a vocabulary they share. The detection works; the programme around it does not.
- Can an analyst attach a technique ID to a case that the rule that fired does not carry?Yes, and it is a different kind of claim. A case label asserts, from evidence gathered during the investigation, that the adversary performed that behaviour. A rule label asserts only what the logic was written to look for. An investigation routinely ends with more technique IDs on the case than on the rule that opened it.
It is the label on a specimen jar, not the diagnosis of the patient. It says what the jar was collected to hold, not what is in it today.
saying these in an interview costs you the question
- Says the tag proves the alert is malicious
- Treats a tagged rule as coverage of that behaviour
- Removes the tag once an alert turns out authorised
- Assigns a sub-technique the rule cannot distinguish
- Thinks the tag changes what the rule matches