A threat report lands in your queue. Somewhere in paragraph nine, the analyst mentions the actor used a signed binary to run code, then moved laterally over SMB. Your job is to turn that sentence into something your detection team can act on. That translation — from prose to structured technique IDs — is the core skill behind MITRE ATT&CK mapping, and it is far more learnable than it looks.

What follows is the vocabulary, a repeatable tagging workflow, and the mistakes that quietly ruin mapping data.

Tactics, techniques, and procedures

ATT&CK is a public knowledge base of adversary behavior, built by MITRE from observed intrusions and organized into separate matrices for enterprise, mobile, and industrial control systems. Everything inside it sits at a different level of abstraction, and mixing those levels up is the first habit worth fixing.

• Tactic — the goal. Credential Access, Lateral Movement, Exfiltration. Tactics answer why an action was taken.
• Technique — the method. Each one carries an ID, such as T1059 for Command and Scripting Interpreter or T1053 for Scheduled Task/Job.
• Sub-technique — the narrower variant. T1059.001 is PowerShell; T1053.005 is Scheduled Task.
• Procedure — the exact implementation seen in one intrusion. This is usually what a threat report describes: “the group created a scheduled task named Updater that launched a Base64-encoded PowerShell one-liner.”

Procedures change constantly. An actor will rename a binary, swap a script for a compiled loader, or shift from one remote-access tool to another between campaigns. The techniques underneath stay the same, which is why defenders map to techniques and hunt by procedure. If you can detect scheduled task creation from an unusual parent process, the specific task name matters much less.

Two practical notes. First, pick the right matrix before you start tagging — an incident involving a substation PLC belongs in ATT&CK for ICS, not Enterprise. Second, the matrix is not a strict checklist. Tactics are ordered left to right for readability, not because every intrusion marches neatly from Initial Access to Impact. Real intrusions loop, skip, and double back.

A workflow you can repeat

Mapping gets much easier once you stop trying to be exhaustive and start following a fixed sequence.

1. Read the report once without marking anything. You are building a mental timeline of the intrusion, not collecting IDs.
2. Mark the behavioral verbs. Highlight sentences describing actions: created, executed, dumped, connected, exfiltrated. Nouns like “the malware” or a tool name tell you nothing about behavior.
3. Identify the tactic first. Ask what the actor was trying to achieve at that moment. The tactic narrows the candidate techniques from hundreds to a handful.
4. Choose the most specific technique the evidence supports. If the report only says “used a scripting interpreter,” stop at T1059. If it names PowerShell, go to T1059.001. Guessing a sub-technique the report never states corrupts your data.
5. Record the evidence next to the ID. A short quoted sentence or a page reference makes the mapping auditable and saves you from re-reading the whole document in six months.
6. Note confidence. A simple high, medium, or low field is enough. Reports written from vendor telemetry sometimes infer a technique; your mapping should reflect that uncertainty rather than hide it.
7. Do a gap pass. If the report describes beaconing but you mapped nothing in Command and Control, you missed something. Read the narrative again looking for the tactic you did not tag.

Keep the ATT&CK version in your notes. Techniques are added, deprecated, and split over time, and a mapping from three years ago will not line up cleanly with the current matrix.

Where beginners go wrong

Most bad mapping data comes from a small number of habits.

Tagging tools instead of behavior. “PowerShell” is an implementation, not a technique. The technique is T1059.001. Likewise, naming a malware family is not mapping. Ask what the tool did: did it dump credentials from memory, encrypt files, or establish a tunnel?

Over-tagging. Twenty-five techniques on a four-page report looks thorough and is useless for prioritization. A ten-technique mapping that captures the distinctive behavior of the intrusion will serve your team better than a sprawling list where everything is weighted equally.

Ignoring failed attempts. If the actor tried and failed to disable a security tool, that is still Defense Evasion, and it is still a detection opportunity. Intent matters, and failed attempts often reappear in later campaigns.

Copying someone else's mapping. Reuse is fine as a starting point, but mappings drift, get truncated, and pick up techniques the original report never claimed. Read the source yourself.

Turning tags into detections

Mapping is only worth the effort if the output changes what you build. Load your technique IDs into the ATT&CK Navigator, a free web tool from MITRE, and layer them against your current detection coverage. The gaps become a work queue.

Prioritize ruthlessly. Techniques that are both common in your sector and cheap to detect — a new service installation, an unusual scheduled task, a burst of remote service authentication — usually beat exotic techniques that need telemetry you do not collect. Where you can, validate a detection by reproducing the technique in a lab; open source emulation libraries such as Atomic Red Team are built for exactly that.

Finally, keep mappings in one place and give them a consistent format. A shared spreadsheet with columns for technique ID, tactic, evidence, confidence, and source report will outperform a folder of annotated PDFs within a month. When an executive asks whether you are covered against the group in the latest advisory, you will have an answer instead of a search.

Start small. Take three recent reports you already trust, map them with the workflow above, and compare the results with a colleague. The disagreements you have about those ten technique IDs are the most useful training you will get.

Photo: StefanCoders / Pixabay