Logo
TLCTC
Blog / Standards Integration

Enhancing CVE Records with Cause-Oriented Threat Intelligence

BK
Bernhard Kreinz
• • Loading read time... V2.0
Context: MITRE and NIST - CVE & NVD
Illustration how MITRE and NIST work together with CVE.
Operating Model: Illustration how MITRE and NIST work together with CVE.

The Common Vulnerabilities and Exposures (CVE) program is operated by the MITRE Corporation, funded by CISA/DHS. MITRE assigns unique CVE identifiers and manages the official list. Separately, the National Vulnerability Database (NVD), maintained by NIST, imports all CVEs and enriches them with CVSS scores, CWE classifications, and CPE data.

In summary: MITRE creates the core CVE entries, NIST builds the NVD by enhancing them with detailed analysis.

Abstract

CVE records tell us what is vulnerable, but not how attacks unfold or why vulnerabilities exist. We propose enriching CVE records with TLCTC v2.0’s cause-oriented threat clusters, Attack Velocity (Δt), and Data Risk Event tags to bridge the gap between vulnerability management and strategic risk management. This blog post summarizes the core idea; the full proposal is available on GitHub.

The Problem: What CVE Records Are Missing

A typical CVE entry gives us affected software, a vulnerability description, a CVSS score, and references. But it lacks three dimensions critical for strategic defense:

  • The "How" (Cause vs. Outcome): When a CVE states "allows remote code execution," that describes the outcome. The same RCE could stem from #2 Exploiting Server, #3 Exploiting Client, #7 Malware, or #1 Abuse of Functions — fundamentally different threat vectors requiring different defenses.
  • The "When" (Attack Velocity): CVEs describe isolated vulnerabilities, but real attacks are sequences with measurable speed. Knowing that #3 → #7 happens at VC-4 (milliseconds) tells you human response is structurally impossible — only architectural controls work.
  • The "Why" (Generic Vulnerability): Every CVE exploits a generic vulnerability — the root weakness category. CVE records rarely surface this, making it hard to address entire classes of similar vulnerabilities.

The Proposal: A tlctc_extended Section for CVE Records

We propose adding an optional, backward-compatible tlctc_extended JSON section to CVE records. It includes:

  • Generic vulnerability mapping — which root weakness category the CVE exploits
  • TLCTC cluster classification with R-* rule justification (e.g., R-ROLE, R-EXEC)
  • Attack path examples with velocity annotations (→[Δt=instant])
  • Data Risk Event tags separating cause from outcome (+ [DRE: C, I, A])
  • Vertical stack analysis clarifying server/client roles per R-ROLE
  • NIST CSF 2.0 mapping across all six functions

Quick Example: Before and After

Before (standard CVE):

CVE-2025-21333 — Windows Hyper-V NT Kernel Integration VSP
Elevation of Privilege — CVSS 7.8 HIGH

After (with TLCTC enrichment):

CVE-2025-21333
├── CWE-416 (Use After Free)
│   └── Generic Vulnerability: Client-side code implementation flaws
│       └── #3 / TLCTC-03.00 (Exploiting Client) [R-ROLE: client processing]
│           ├── ATT&CK T1068 (Exploitation for Privilege Escalation)
│           ├── NIST CSF PR.IP-12 (Vulnerability Management)
│           ├── Attack Path: #4 →[Δt=15m] #3 →[Δt=instant] #7 + [DRE: C, I, A]
│           └── Velocity Class: VC-4 (requires architectural controls)
└── CVSS 3.1: 7.8 HIGH

Now we know the generic vulnerability, the classification rationale (R-ROLE), realistic attack sequences with velocity, and that VC-4 speed demands architectural controls over human response.

What This Enables

  • Eliminates ambiguity: R-* rules replace vague "RCE" with precise cluster classification and justification
  • Velocity-informed control selection: VC-4 transitions require architecture, not analysts; VC-2 transitions allow human triage
  • Cause/outcome separation: Clusters identify how the attack works; DRE tags capture what happens
  • Dual-audience notation: #3 for the boardroom, TLCTC-03.00 for SIEM integration
  • Cross-framework alignment: Maps to ATT&CK, CWE, NIST CSF 2.0, and STIX/TAXII

Full Proposal on GitHub

This blog post is a summary. The complete proposal — including the full enhanced JSON example, all nine R-* classification rules, velocity class definitions, implementation roadmap, framework alignment details, and FAQ — is maintained on GitHub:

TLCTC CVE Extension Proposal

Full specification with JSON schema, R-* rules, worked examples, implementation roadmap, and NIST CSF mapping.

View Full Proposal on GitHub

We welcome contributions, feedback, and discussion via GitHub Issues. Whether you’re a CNA, a security tool vendor, a SOC analyst, or a standards body representative — the proposal is designed to complement (not replace) existing CVE infrastructure while adding the strategic dimensions the community needs.

Resources