Threat-Informed Defense Is Detection Engineering, Minus the Guessing

Enterprise SIEMs ingest, on average, over 250 log types across tens of thousands of sources — theoretically enough to detect the overwhelming majority of MITRE ATT&CK techniques. Measured actual coverage sits around 21%. That gap isn't a tooling problem. It's what happens when a program builds detections without first deciding, deliberately, which adversary behaviors it's defending against.

Threat-Informed Defense (TID) is MITRE's answer: the systematic application of a deep understanding of adversary tradecraft to improve defenses. The term is stewarded by the Center for Threat-Informed Defense (CTID), a MITRE-run research consortium founded in 2019 with member companies spanning finance, healthcare, and tech. Their pitch isn't another framework to bolt on — it's a specific claim about what a detection should be built from.

The three dimensions, briefly

CTID structures TID as a triangle — three dimensions that only work as a loop, not a checklist to complete once.

• Cyber Threat Intelligence identifies which adversary groups and techniques actually threaten you, and maps that intelligence to ATT&CK — not as raw IOCs, but as durable, describable behavior.
• Defensive Measures turns that mapping into detections and mitigations built on the technique itself, not on an artifact — a hash, an IP — that changes with the adversary's next build.
• Test & Evaluation validates that those defenses actually trigger on the behavior they claim to cover, through structured adversary emulation instead of assuming a deployed control works.

MITRE's own maturity model for this — INFORM, the successor to their earlier M3TID research — weights the three dimensions unevenly: Defensive Measures highest, then Cyber Threat Intelligence, then Test & Evaluation. The ordering is deliberate. Taking defensive action is the point; the other two dimensions exist to aim it and check it, not to stand alone.

This isn't IOC-hunting with a new name

Indicator-based defense — block this hash, alert on this IP — is cheap to build and cheap for an adversary to evade: change the file, rotate the infrastructure, and the detection goes dark. This is the entire argument behind David Bianco's Pyramid of Pain, which CTID builds on directly. IOCs sit at the bottom, trivial for an attacker to discard. TTPs sit at the apex — expensive to change, because they're closer to what the adversary actually needs to do to succeed, not what they happen to be using this week.

ATT&CK is the vocabulary for that apex. It's not automatically protective just because a heatmap shows technique coverage, though — CTID's own researchers have pushed back on treating coverage percentage as the goal. A rule that "covers" T1059 by matching one specific PowerShell one-liner isn't threat-informed. It's IOC-hunting wearing an ATT&CK ID.

Where most TID programs actually fail

Not from lack of an ATT&CK Navigator heatmap. They fail on the same boring failure mode CTEM programs do — skipping the stage that's hardest to staff.

Teams chase technique-count coverage instead of technique-quality coverage, because a bigger number in the heatmap is easier to report than an honest answer to "would this actually catch the adversary using this technique." CTID built an entire project, Summiting the Pyramid, specifically to grade detections on how evasion-resistant they really are — a tacit admission that most "covered" techniques are covered by something brittle.

Test & Evaluation is the stage that gets cut, for the same reason Validation gets cut from CTEM: it's expensive, it requires a team that can emulate real adversary behavior, and skipping it produces a program that looks complete on paper and has never actually been tested against the thing it claims to stop.

And ATT&CK doesn't prioritize for you. It's a map, not an itinerary — without threat intelligence specific to your industry and environment layered on top, technique-count coverage optimizes for the wrong thing entirely: broad, shallow defense against everything, instead of deep defense against what's actually likely to show up.

Where to actually start

• Build a named, prioritized technique list for your actual threat model — the groups relevant to your industry and the entry points you actually have — not a generic top-techniques list copied from a vendor report.
• Grade detections by what they depend on, not whether they exist. A rule tied to a specific tool artifact is one build away from blind.
• Run structured adversary emulation on a schedule, not as a one-off engagement — CTID's own Adversary Emulation Library has named, publicly available plans for real threat actors, built for exactly this.
• Close the loop back to CTI. A Test & Evaluation result that doesn't change what Cyber Threat Intelligence prioritizes next isn't validation, it's a report.

If you want a faster read on which of those three dimensions is actually weak in your own program, the Threat-Informed Defense Maturity Assessment scores all three — weighted the same way MITRE's own INFORM framework weighs them — from twelve questions.

A detection built on an artifact protects you until the adversary changes one file. A detection built on a technique makes them change how they operate. That difference is the entire point of calling it threat-informed.