Your AI red-team report tags each delivered finding with an identifier from a published adversary technique reference. What does that tag give a reader who was not on the engagement, and what does it not give them?
answer
- shared address, not a verdict
- reader can look it up
- severity comes from your evidence
- same technique, wildly different impact
- delete the identifier — does the finding still stand?
basics
~20 sIt gives the finding a shared address: a reader can look the technique up, see how other reports used it, and find published mitigations. It does not give severity, likelihood or reproduction detail. Those come from your own evidence, narrative and rating. The identifier is an index entry, not a verdict.
solid answer
~50 sThe identifier is a lookup key into a structure the reader already knows. It lets them place your finding beside findings from other assessments, pull the reference's published detections and mitigations for that technique, and route the item to whichever team owns that class of problem. What it never carries is your engagement's specifics: how hard the attack was, how often it worked under the query budget you had, what the target configuration was, or what evidence you hold. It also does not rank anything — two items under the same technique can differ by an order of magnitude in impact. So the tag sits **beside** the finding's own title, narrative, evidence and rating, never in place of them. A useful test: if a reader could reconstruct your report from the identifier list alone, you have under-written the findings.
go deeper
Says the identifier lets a reader look the technique up and compare it with other reports, and that it is not a severity rating.
Adds the downstream uses — routing to the owning team, pulling published mitigations — and names what stays engagement-specific: evidence, conditions, success rate, rating.
Talks about report design: the tag beside the narrative rather than instead of it, and the failure mode of an identifier table that looks rigorous but is unreadable.
Frames it as a communication contract with the client's own tracking system, and cares that ratings are derived from observed evidence rather than inherited from the reference.
### What a "published adversary technique reference" actually is It is a catalogue maintained by somebody other than you. Each entry carries a **stable identifier** (a short code that is not supposed to change casually), a name, a prose description of the attacker's position, the access the technique presupposes and the effect it produces, and usually a list of candidate detections and mitigations. MITRE ATLAS is the AI-focused catalogue most teams mean; MITRE ATT&CK is the enterprise one whose shape it borrows. The structurally important fact is that **nothing in such a catalogue knows anything about your client's system**. Every entry is written about a class of attacker behaviour in the abstract, by people who have never seen the target you tested. ### The mechanism — what writing a tag next to a finding actually does Attaching an identifier is a single assertion: *the behaviour I observed is an instance of the class this entry describes*. That assertion, and nothing more, produces four downstream effects. **Location.** The reader opens the entry and gets a description written by a third party. They stop depending on your prose to understand what family of thing you found. **Comparability.** The same class of finding from another vendor, another quarter, or another product carries the same address, so items can be grouped and filtered across reports nobody wants to re-read end to end. **Routing.** Detection-engineering and platform teams commonly organise their own backlogs and coverage tracking by these identifiers, so a tagged finding lands in a queue that already exists instead of in a general security inbox. **Mitigation lookup.** The entry usually names candidate countermeasures, giving the reader a starting point that was not written by the party being paid for the engagement. ### What it costs Mapping is analyst time, not machine time, and the honest version is not cheap. Doing it properly means reading the **full entry description** for each candidate technique — not its title — and checking three things against your own evidence: where the attacker sat, what access the technique presupposes, and what effect resulted. Budget five to fifteen minutes per finding for someone already fluent in the catalogue, appreciably more the first few times, plus a review pass in which a second person re-derives a sample of the mappings. On a twenty-five-finding report that is most of an analyst day; it recurs on every engagement, and it recurs again as unplanned rework whenever the reference is revised. Those hours come out of the same budget as evidence collection and re-testing, so it is worth being explicit about what they buy: **navigability for outside readers, and no new knowledge whatsoever about the target**. ### Where the reading goes wrong This is the part interviewers are testing, because every misreading below is common and none of them looks like an error on the page. - **The identifier read as a rating.** A column of codes sits where a scoring column normally sits and inherits its authority. But no entry in the catalogue is per-target; a one-in-two-hundred-attempts curiosity and a single-shot data-egress path can carry the identical code and look identical in the table. - **Counts per technique read as a weakness profile.** "Eleven of our findings are technique X" is usually a statement about what you chose to probe and how you split findings, not about where the system is weak. Change the probe mix or the splitting rule and the profile moves while nothing about the target has changed. - **A shared identifier read as duplication.** Two findings under one code are two members of a class, not the same defect; merging them on that basis quietly deletes one of them. - **The listed mitigations read as validated.** The catalogue's countermeasures are generic candidates. None has been tested against this deployment, and a recommendation that says "see the reference's mitigations" implies otherwise. - **The identifier table read as the report.** A findings section that is codes plus one-line titles reads as rigorous and conveys almost nothing: no reader can tell what was done, under what configuration, or why any item deserves attention this quarter. ### What I would check before delivery Run the **delete-the-column test**: strike the identifier column and see whether every finding still stands on its own evidence and narrative. Confirm each mapping records *which* reference and *which* edition it was made against, at authoring time — that is unrecoverable a year later. Confirm each rating was derived from observed impact and exploitability rather than inherited from whatever the entry implies. And check that at least a sample of mappings can be justified from the entry's description rather than from its title, because title-matching is where most wrong mappings begin.
- A client asks why you also write a plain-language title for each finding when it already has a technique identifier.Because the identifier addresses a class, not this instance. The title has to say what happened to *their* system — which surface, what the attacker input did, what came out — and that is what the people who fix it read first.
- Two findings carry the same technique identifier. Should they be merged?Not on that basis. Merge only when they are the same defect on the same surface with the same fix. A shared identifier means the same class, and one may be trivial while the other is a direct data-egress path.
- Where should the reference's name and edition appear?On the mapping itself, or once in the report's methodology section covering all of them. Without it a later reader cannot tell whether a moved or renamed identifier means the finding changed or the reference did.
A technique identifier is a library call number: it tells you which shelf the item sits on and what else sits beside it, and says nothing at all about whether the book is any good.
saying these in an interview costs you the question
- Treating the technique identifier as a severity or priority signal.
- Delivering a findings table of identifiers with no narrative or evidence.
- Claiming the reference's published mitigations are validated for this specific target.
- Assuming two findings under the same identifier are duplicates.