Every detection engineering team has had this exact conversation, usually at 2am, usually right after a “critical” alert turned out to be a backup job: “wait, what does this rule actually need to see?” Nobody knows. The person who wrote it left the company eleven months ago. The rule references a field that may or may not exist depending on which log forwarder was having a good day when it shipped. And the SIEM team, bless them, has now asked “why isn’t this firing” for the fourth time this sprint, and every single time the honest answer is some variation of “we genuinely don’t know, let’s go find out together,” which is a sentence that should never leave a detection engineer’s mouth in a mature program.
We got tired of that sentence. So we built something to make it stop being necessary — and then, because we can’t help ourselves, we immediately started arguing about whether we were about to build the exact wrong thing.
The Bad Idea We Almost Shipped
The obvious “fix” for telemetry chaos is the one every vendor pitches you at a conference booth: tag every detection with its exact log source and fields before anyone’s allowed to write the rule. Sounds disciplined. Sounds like engineering rigor. It is actually a trap.
Here’s why: if you force analysts to start from “what event do we have” and reason forward into “what could this detect,” you get a library of Event ID trivia dressed up as a detection program. You end up building analytics anchored to EventID 4688 because that’s what was convenient, not because process creation telemetry was the right lens for the behavior you were actually hunting. Change one flag on the adversary’s tooling, lose the artifact you anchored on, and your “detection” evaporates. This is how you get a coverage matrix that looks beautiful in a slide deck and catches nothing that wasn’t already in a canned APT simulation from three years ago.
We nearly built exactly that. Telemetry-first, gate the authoring on “do you have the log source,” ship it, feel very responsible. Then somebody in the room (you know who you are, Red) pointed out the obvious thing everyone in this industry keeps forgetting: behavior comes first, telemetry is a byproduct, not a precondition. You reason about the adversary’s actual tradecraft, you write the logic that captures that behavior, and only then do you go figure out what evidence proves it happened. Reverse that order and you’ve optimized for “what data do we already have lying around” instead of “what does this attack actually look like” — which is precisely the failure mode that makes red teams laugh at blue teams during retros.
What We Actually Built: Telemetry Tagging
So instead of gatekeeping the front door, we put the telemetry work at the back of the authoring process, inside the Workbench, as a derived artifact of analysis you’ve already done — not a permission slip you need before you’re allowed to think.
Here’s the flow: you do the actual detection engineering work. You pick the ATT&CK technique. You write the Strategic Goal. You fill in Technical Context with the real procedure narrative — how the adversary actually does the thing, not a Wikipedia summary of the technique. You write the detection rule itself. You classify the Threat Surface Taxonomy (Windows, Azure, whatever platform you’re actually defending). Once — and only once — all five of those are genuinely populated, a button lights up: Derive Telemetry Tags.
Hit it, and the platform does the boring homework you don’t want to do by hand: it cross-references your selected technique against known data components, pulls in whatever native telemetry hints the platform already has for that technique family, mines your own technical-context narrative for tool-specific or artifact-specific telemetry that the generic technique mapping would never surface on its own, and then — this is the part we’re actually proud of — cross-checks the whole candidate list against the literal body of the detection rule you wrote. If your rule queries a field your candidate list missed, it gets added. If a candidate is nowhere near what your rule actually touches, it gets dropped. Free internal consistency checking, no extra effort.
What comes out the other end is a clean, editable tag list: source, the relevant technique/data-component mapping, the specific field names, and a one-line rationale explaining why this telemetry matters for this exact rule. That list travels with the detection into the Rule Hub. That list is the thing you hand to your SIEM team instead of a Slack message that starts with “so basically.”
The Gate Nobody Gets to Skip
Here’s the part we’re the most stubborn about, because we’ve watched “optional best practice” fields rot into permanently-empty form inputs across every platform we’ve ever used, including, historically, our own: the five required fields are a hard block. Not a warning banner. Not a yellow triangle you can dismiss and forget about forever. The button is disabled, full stop, with a tooltip telling you exactly which of the five fields you still haven’t bothered to fill in, until every single one is there.
Yes, this includes Threat Surface Taxonomy, which technically lives inside the SOAR Configuration section — a section we’ve documented elsewhere as genuinely optional, because most of SOAR configuration is response automation that not every org needs on day one. We made an explicit, deliberate exception: that one field is a hard precondition for telemetry derivation regardless of whether you’ve bothered opening that section, because without it your telemetry candidates are useless generic noise instead of platform-specific reality. Windows and Azure do not produce the same telemetry for the same ATT&CK technique, and pretending otherwise is how you end up with a “detection” that assumes Sysmon exists in an environment that’s 100% cloud-native.
The Word “Unverified” Is Doing Real Work Here
We need to be loud about this part, because it’s exactly the kind of nuance every vendor demo conveniently skips: every single tag this feature produces is stamped unverified, permanently, in this version. Why? Because the reference data behind the derivation — the technique-to-data-component mappings — comes from a bulk import of what MITRE documents as generally available telemetry for a given technique. It is not, repeat not, a live check against your actual SIEM. It does not know whether your Windows Security Event Log ingestion has been silently broken since March. It does not know if your Sysmon config strips command-line arguments before they ever hit your pipeline. It is a well-informed hypothesis, not a receipt.
We could have quietly skipped that caveat and let the feature look more finished than it is. We didn’t, because we’ve already written an entire article roasting the industry habit of treating “rule exists in the library” as equivalent to “detection is complete, deployed, and operationally proven.” Slapping a fake “verified” checkmark on telemetry we haven’t actually confirmed exists would be the exact same lie with a different coat of paint. So: unverified means unverified. Confirming what your organization actually has flowing into your SIEM, in real time, with real health checks, is a different and harder problem — one we’re deliberately leaving for a future milestone instead of pretending we solved it today.
The Bug We Found While Building This
And because self-deprecating honesty about our own screwups is basically our brand at this point: while wiring up the automatic ATT&CK tagging for this feature, we discovered that selecting a MITRE technique in the Detection Strategy section was silently not adding that technique as a searchable tag on the Workbench object. It updated the technique field. It just never told the tagging system about it. Which means every Workbench you’ve built before this fix has a technique selected in the strategy section that’s invisible to tag-based search and filtering, unless someone typed it in manually. That’s now fixed — selecting a technique auto-tags the object, same as our existing pattern for tagging by rule format. You’re welcome, and also, sorry.
Where to Find It
The Derive Telemetry Tags button lives in the Workbench’s right-hand Details panel, directly under your manual Tags field and right above the Node ATT&CK Mappings section — not buried in a settings menu, not hidden behind a “Pro” paywall gate, not requiring you to learn a new tab. Fill in the five required fields, hit derive, review what comes back, edit anything that’s wrong, and move on with your life. The whole point was to shrink the “why isn’t this firing” conversation, not to invent a new form for you to dread filling out.
We’re not claiming this ends telemetry chaos forever. We’re claiming it stops treating telemetry dependency as tribal knowledge that lives exclusively in one analyst’s head until they quit. That’s a smaller claim than “AI-powered telemetry verification,” and it’s the one we can actually stand behind.
Happy hunting.
Featured image generated using Artificial Intelligence (EU AI Act transparency notice).