Most threat intelligence dies in a document. A well-researched report on an adversary's tradecraft gets written, circulated, admired, and filed — and nothing in the environment changes as a result. The value of intel is not the knowing. It is the last mile: turning what you learned about an adversary into a detection that actually fires when they show up. That handoff is where most intel programs quietly fail.

Why the last mile is hard

The gap is organizational as much as technical. Intel analysts and detection engineers often sit in different teams, speak different languages, and measure themselves on different things. The analyst's deliverable is the report; once it ships, their metric is satisfied. The detection engineer's backlog is full of other work, and a prose report is not a detection requirement — it is homework. So the report lands, nobody is accountable for converting it, and the intel evaporates into organizational memory.

The technical gap compounds it. A report might say a group "uses living-off-the-land techniques for persistence." That is true, useful, and completely unactionable as written. Which techniques? Observable in which log source? Distinguishable from legitimate admin activity how? The distance between an intelligence finding and a precise, low-false-positive detection is real engineering work, and if nobody owns it, it does not happen.

The pyramid tells you where to aim

Not all intel converts into detection at the same value. The old Pyramid of Pain framing still holds: detecting on hashes and IP addresses is easy for you and trivial for the adversary to change, so it ages in days. Detecting on tools and, above all, on techniques and behaviors is harder for you to build but far more painful for the adversary to evade — they would have to change how they operate, not just rotate infrastructure. The last mile is worth the most when you aim it high on the pyramid: convert intel about behavior into detection, not just intel about indicators.

Making the handoff actually happen

  • Make "detection recommendation" a required section of every intel report. The analyst does not have to write the rule, but they have to state what should be detectable and in which data source. This turns prose into a requirement someone can own.
  • Give the conversion a ticket and an owner. Every actionable finding becomes a backlog item on the detection team, tracked to done. Untracked intel is intel you have decided not to use.
  • Close the loop back to the analyst. Tell the analyst what got built and what could not — because "we could not detect this in our current logging" is itself an intelligence finding, and often a visibility-gap finding worth more than the original report.
  • Measure conversion, not production. The health metric for an intel program is not reports written. It is the fraction of actionable findings that became a live detection. Track that number and the last mile stops being optional.
Intel that never becomes a detection, a hunt, or a decision is trivia. The report is not the product. The change in what your environment can see is the product.

Close the last mile and the whole intel investment changes character. Analysts see their work show up as detections that catch real activity. Detection engineers get a prioritized stream of adversary-informed requirements instead of guessing. And the program can finally answer the only question that matters to the people funding it: what can we now catch that we could not catch before?