Mapping a report to MITRE ATT&CK is not the same as detecting the behavior. Here is how to translate technique IDs into SIEM and SOAR logic your SOC can actually run.
Most threat intel teams have learned to tag every finished report with MITRE ATT&CK technique IDs. It looks rigorous. It produces clean heat maps. It satisfies the board slide that says the program is mapped to a framework. And then nothing happens.
The handoff between a technique ID and a working SIEM rule is where the value of CTI either lands or evaporates. ATT&CK mapping by itself is taxonomy. Detection logic is engineering. If your team stops at the ID, you have produced documentation, not defense.
Why the handoff fails
The most common failure mode is that the CTI analyst writes T1059.001 in a report and the detection engineer is left to figure out what that actually means in this environment. PowerShell command line execution covers thousands of legitimate use cases. Without context the rule either drowns the SOC in noise or gets tuned down to nothing.
A second failure mode is that the report describes a procedure in narrative form and the engineer has to reverse engineer the observable. The intel says the actor uses encoded PowerShell to fetch a second stage. The engineer has to decide whether to detect on the encoding flag, the parent process, the network destination, the user account profile, or some combination. None of that decision is captured in the original report.
A third failure mode is that no one closes the loop. The rule gets deployed. It fires. The SOC triages. Nothing flows back to the CTI analyst about whether the alert was useful, what tuning was applied, or what the actual behavior looked like in production. The next report on the same actor repeats the same ID with the same lack of detail.
What a usable handoff looks like
A usable intelligence to detection handoff has four parts. Each is small. None is optional.
The first part is the technique in context. Instead of T1059.001 standing alone, the report names the procedure as the actor uses it. For example, the actor invokes powershell.exe with the EncodedCommand flag from a child of winword.exe, decodes a base64 blob that resolves to a single line Net.WebClient download, and writes the payload to %ProgramData%. That sentence contains the parent process, the command line shape, the network behavior, and the write location. An engineer can build from it.
The second part is the candidate observable set. The CTI analyst lists the data sources that would show the behavior and ranks them by fidelity. In the example above the highest fidelity source is process creation events with full command line auditing. EDR telemetry catches it. Sysmon Event ID 1 with command line logging catches it. A vanilla Windows Security log without command line auditing does not. Naming the source set tells the engineer what to query against and tells the SOC manager what coverage gaps exist.
The third part is a draft logic statement. Not a finished rule. A statement of the form: parent process is winword.exe AND child process is powershell.exe AND command line contains the EncodedCommand flag. The engineer will refine, add exclusions, and decide on the language, but the analyst has already done the work of describing what to look for.
The fourth part is the expected noise profile. The analyst calls out the obvious false positive sources. Office macro based automation. Legitimate admin scripts that base64 their parameters. Software deployment tooling that wraps PowerShell. The engineer does not have to discover these by deploying and getting paged. They are in the report.
A small template that travels
Below is a compact template the team can drop into any finished report. It is short enough that analysts will actually fill it in.
Technique: T1059.001 PowerShell
Procedure as observed: powershell.exe with EncodedCommand from winword.exe child, decoding to Net.WebClient download to %ProgramData%
Primary data source: EDR process creation with full command line, or Sysmon Event ID 1 with command line logging enabled
Draft logic: parent process winword.exe AND image powershell.exe AND command_line contains EncodedCommand AND (decoded_command contains Net.WebClient OR decoded_command contains DownloadString)
Known noise: enterprise macro automation, software deployment frameworks that wrap PowerShell with encoded parameters, IT scripts run by privileged accounts from admin workstations
Suggested response: triage as Medium until enriched with user role and host criticality. Auto enrich with parent document name if available. Escalate to High if host is in the finance OU or the user is in privileged groups.
Five fields. The detection engineer can take that to a sprint board the same day.
Translating into common SIEM and SOAR shapes
The same draft logic translates differently across stacks. The point of the template is that the translation work is now mechanical instead of speculative.
In Splunk you express the logic as a search against process creation events with conditions on ParentImage, Image, and CommandLine, then layer a stats by host to set a per host threshold if needed. In Microsoft Sentinel you express it as a KQL query against DeviceProcessEvents with the same field semantics. In Elastic the same shape lives in EQL or ES|QL against process events. In a SOAR playbook the rule becomes a trigger and the enrichment steps become tasks that fetch user role, host criticality, and parent document.
None of those translations require the CTI analyst to write the production query. They require the analyst to be specific enough that the engineer is not guessing.
Detection engineering owns the rule, CTI owns the requirement
A healthy team draws a clean line between the two roles. The CTI analyst owns the intelligence requirement that motivated the detection. The detection engineer owns the rule, its performance, and its lifecycle. Both meet at the handoff template above.
When the rule fires and the SOC triages, the SOC writes a short note back to both sides. Was the alert true positive, benign true positive, or false positive. What field was the most discriminating in the triage decision. What was missing that would have made the call faster. That note feeds the next iteration of the rule and the next version of the related report.
A weekly cadence that keeps the loop alive
Pick a one hour weekly meeting. The agenda is fixed.
Fifteen minutes on new rules deployed in the last week. The engineer walks through what was deployed, what it caught, and what it missed. The CTI analyst confirms whether it still maps to the requirement that triggered it.
Fifteen minutes on rules that fired. The SOC lead brings the top three rules by volume and the top three by analyst time. The group decides what to tune, what to retire, and what to escalate.
Fifteen minutes on rules that did not fire when they should have. The CTI analyst brings any incident from the past week where a known procedure was observed and an existing rule did not catch it. The group decides what to revise.
Fifteen minutes on the backlog. The CTI analyst presents the top two intelligence findings from the past week that need detection coverage. The engineer commits to scope for the next sprint.
Sixty minutes. Every week. No slide deck.
Metrics that matter
Stop measuring how many ATT&CK techniques you have a rule for. Start measuring three things.
Time from intelligence finding to deployed rule. Measured in business days. Track the median and the worst case. The median tells you the health of the pipeline. The worst case tells you where it breaks.
True positive precision per rule. Out of every ten alerts the rule fires, how many lead to a real action. Anything under three out of ten is a tuning problem or a requirements problem.
Coverage of the requirement, not coverage of the framework. For each active intelligence requirement, list the rules that contribute and the data sources behind them. Gaps in the requirement are easier to act on than gaps in a heat map.
The point
Mapping a report to ATT&CK is the start of the work. The value is in what comes next. Give the detection engineer a specific procedure, a named data source, a draft logic statement, and a noise profile. Hold a sixty minute weekly meeting that closes the loop. Measure time to deployment, precision, and requirement coverage. That is the difference between intelligence that looks rigorous and intelligence that lowers risk.