TID-CMM Threat-Informed Detection Capability Maturity Model
Home › Model › Interoperability

Interoperability and handoffs

What this model consumes, what it maps to, what it merely relates to, what it hands off, and what it does not map to at all — each labelled with the kind of relationship it is, because “aligned” covers five different things and only two of them are mappings.

Five kinds of relationship

A maturity model acquires an undefendable reputation by calling all of these the same word. They are listed separately here, and every entry in the table below is labelled with one of them.

KindWhat it means here
Consumed inputExternal data the model reads and depends on. Its version is pinned and recorded on every assessment.
Formal crosswalkA mapping recorded on every one of the 58 sub-capabilities, machine-readable, shipped in the datasets. Reportable.
Referenced relationshipA mapping or a vocabulary recorded only where it genuinely exists — on one or two sub-capabilities — and stated as such, not extrapolated to the rest of the model.
Comparative positioningAn explanation of how this model relates to another, with no per-control mapping claimed at all.
Operational handoffOutput of one assessment becomes input to another — through a versioned document, or as work someone picks up. No score is converted.
Not mappedNamed because people ask, and recorded as unmapped rather than implied.

The relationships, one row each

Framework or modelRelationship CoverageWhat it actually is
MITRE ATT&CK Enterprise v19.2Consumed input697 techniques Every coverage claim is anchored to technique and sub-technique IDs. Scope is derived from it; telemetry assurance is computed from the log sources its own analytics require. How ATT&CK is used.
NIST Cybersecurity Framework 2.0Formal crosswalkall 58 Every sub-capability names the CSF 2.0 subcategories it evidences, so detection maturity can be reported inside an existing CSF programme.
SOC-CMM v2.xFormal crosswalkall 58 Every sub-capability names the SOC-CMM domain and aspect it corresponds to. SOC-CMM assesses the SOC as an operating unit; this asks whether it would see the adversary.
ISO/IEC 27001:2022 Annex AReferenced relationship1 of 58 Referenced where explicitly mapped; currently TI.1 / A.5.7. No other sub-capability carries an Annex A reference, and none is implied.
MITRE EngageReferenced relationship1 of 58 Supplies the placement and operationalisation vocabulary used by AA.7 (deception). Not a maturity mapping.
Gartner CTEMComparative positioning2 of 58 CTEM asks whether an exposure is exploitable; TID-CMM asks whether the exploitation would be seen.
Elastic DEBMMComparative positioning1 of 58 DEBMM covers detection-engineering practice; TID-CMM covers whether that practice is aimed at the right adversary and proven against them.
MITRE D3FENDNot mapped— Listed in earlier releases as a crosswalk. No sub-capability carries a D3FEND mapping, so it is recorded as unmapped rather than claimed.
UTIOMOperational handoff (non-scoring)— TID-CMM is UTIOM’s detection module. The results page carries a non-scoring UTIOM operating-model view derived from answers already given; it invents no UTIOM component score and no level.
TIR-CMMOperational handoff (versioned export)— The results page writes the handoff document, tid-cmm/export/1.0: crown jewels, adversaries, attack paths and registered scenarios, in-scope techniques with evidenced statuses, and the constrained detection score as the ceiling on response. TIR-CMM 1.0 imports the core context it recognises — the detection score, crown jewels with their asset classes, adversaries, and the stage and asset-class scope of the paths; the extended 1.6 detail is retained in the file but is not yet consumed by that importer. Shape and mappings.
RSMMOperational relationship— The Realistic SIEM Maturity Model assesses the platform detection runs on. Separate scope, separate version, separate score; findings travel between the two as work, never as a converted number. The handoff table.

Counts are read from the model data shipped with this release, so this table cannot drift from what the datasets contain. Two things are never claimed here: compliance with a framework, which this model does not assess, and a mapping produced on request, which is how a crosswalk stops meaning anything.

How things actually connect

The relationships above are only useful if something carries them. Five mechanisms do, all of them inspectable.

Stable identifiers Domain codes (TI, TM, DC, DE, AV, AA, IR, GV), sub-capability IDs (TI.1 … GV.7), maturity levels 0–5 and constraint IDs C1–C5 do not change between releases; a mapping written against them keeps working.
Versioned machine-readable model /api/model.json carries the whole model — domains, sub-capabilities, descriptors, weights, evidence criteria and every crosswalk key (nist_csf_2, soc_cmm, iso_27001_2022, ctem, debmm, mitre_engage) — with model.version on the payload and the relationship kinds recorded under alignment. Also techniques, levels, constraints, tiers and profiles. The API.
JSON Schema The export document is described by a published schema, so an importer can validate before it reads. Data model.
Reference datasets The derived ATT&CK datasets (techniques, actors, detection strategies) and the telemetry catalogue ship as CSV and YAML, so the derivation can be checked rather than trusted. Redistributing them needs permission. Resources.
Your own assessment as data Save and import the assessment as JSON — it stamps model_version — and export the TIR-CMM handoff document from the results page. Both are plain files you can read, diff and keep.

One picture

Left to right: what the model reads, what it is, and what its output feeds.

Semantic HTML and CSS only — no diagram library, and nothing here is generated from a score.