Last reviewed:
Exploit telemetry should map to the behaviour the attacker performs, not the vulnerability label attached to the advisory.
A CVE id is not an ATT&CK technique. The technique comes from the action the attacker takes: exploiting a public-facing application, abusing a cloud account, running commands, disabling logs or accessing cloud storage.
Start with the exploit chain. The first observable event may map to Initial Access. The next one may map to Execution, Persistence or Defence Evasion. One advisory can produce more than one useful technique link.
Technique mapping without evidence is decoration. Put the log source and field next to each mapping so another reviewer can see why the technique was chosen.
For cloud work, that evidence may be an Azure Activity Log operation, an AWS CloudTrail event, a Google Cloud Audit Log entry or a managed finding that names the behaviour clearly.
observable_event: POST /login with SQL injection payload
technique: T1190 Exploit Public-Facing Application
follow_on_event: suspicious shell command from web worker
technique: T1059 Command and Scripting Interpreter
evidence: WAF log plus process telemetry
Do not map every tactic that could happen after exploitation. Map what the rule or hunt can see. If the detector only sees the initial web request, it should not claim persistence or exfiltration coverage.
This is where evidence labels help. A posture control, managed finding, SIEM rule and hunt note can all support the same technique, but they should not be presented as the same kind of coverage.
Advisories mature. Early reports may name only impact. Later vendor notes, PoCs and incident write-ups may reveal the exploit path. Revisit the mapping when those details appear.
A small change log beats a silent overwrite. Record why a technique was added, removed or downgraded so the coverage history remains useful.