The End of Semantic Diffusion: DREAD vs STRIDE vs TLCTC

When we analyze a cyber incident or design a system, the cybersecurity industry often confuses three very different things: what is causing the problem, what is happening operationally, and how much we should care about the outcome.

The Top Level Cyber Threat Clusters (TLCTC) framework calls this confusion semantic diffusion. Causes, effects, techniques, and business impacts are blended into vague labels like "ransomware attack," "data breach," "denial of service," or "privilege escalation," as if those labels were precise threat categories. They are not. TLCTC’s central claim is that cybersecurity will remain semantically unstable until it separates causes from effects and classifies attack steps by the generic vulnerability initially exploited.

This becomes especially clear when we compare three very different models: Microsoft’s legacy DREAD, Microsoft’s enduring STRIDE approach, and the cause-oriented TLCTC framework.

DREAD: the scorecard Microsoft itself moved beyond

DREAD was Microsoft’s older risk-scoring method for software threats and vulnerabilities. The acronym stands for Damage, Reproducibility, Exploitability, Affected Users, and Discoverability. Analysts would score each dimension and average the result. Microsoft still documents DREAD in some legacy and specialized material, including driver threat-modeling guidance, which shows that the model remains part of the historical record even if it is no longer the center of Microsoft’s mainstream SDL practice.

What matters more is that Microsoft itself explained why DREAD fell out of favor. In Microsoft’s archived SDL writing, the problem was not subtle: two people could rate the same vulnerability very differently, producing wildly different results. Microsoft’s conclusion was that DREAD was too subjective and inconsistent to serve as a dependable foundation for security triage, so the company replaced it with a more consistent security bug bar approach. The same article explicitly says that, unlike DREAD, STRIDE remained in use.

From a TLCTC perspective, that failure makes perfect sense. DREAD never actually identifies the threat. It scores a mixture of things around the threat. "Damage" and "Affected Users" are consequence-side concerns. "Reproducibility," "Exploitability," and "Discoverability" are operational or situational properties. None of them identifies the cause-side generic vulnerability that defines the attack step. In Bow-Tie terms, DREAD tries to compress both the left side and the right side of the risk structure into one blended number. That may be useful for triage, but it is semantically weak as a classification method. Priority scoring becomes unstable when the underlying category is unstable.

So DREAD still has a role, but only a limited one. It is a language of urgency, not a language of causality.

STRIDE: better than DREAD, but still semantically blended

Microsoft’s current threat-modeling guidance still centers on STRIDE per element. The Microsoft Threat Modeling Tool uses STRIDE to guide analysts through design review and mitigation thinking, and Microsoft’s documentation continues to position STRIDE as the practical backbone of that workflow. In that sense, STRIDE clearly outlived DREAD.

That endurance is easy to understand. STRIDE is useful. It gives architects and engineers a structured way to ask, "What could go wrong here?" It is far more helpful than DREAD when the goal is to surface candidate concerns during a design review.

But usefulness is not the same as semantic precision.

Through the TLCTC lens, STRIDE still suffers from category blending. Some of its buckets point toward causes, some point toward outcomes, and some are broad labels that collapse multiple distinct causes into a single word. That makes STRIDE an effective brainstorming scaffold, but not a stable cause taxonomy. TLCTC’s axioms insist that a threat must be classified by the generic vulnerability initially exploited, that one attack step must map to one cluster, and that outcomes such as confidentiality loss or service loss must remain separate from the threat itself.

This becomes obvious when STRIDE is translated into TLCTC.

• Spoofing maps relatively cleanly to #4 Identity Theft, because it points to the use of credentials, tokens, keys, or identity artifacts to impersonate another identity. That is a valid cause-side class in TLCTC.
• Tampering does not map cleanly at all. In TLCTC, the correct classification depends on how the modification happened. Data might be altered through #1 Abuse of Functions, #2 Exploiting Server, #3 Exploiting Client, #5 Man in the Middle, or #7 Malware. "Tampering" describes what happened to the data, not the generic vulnerability that made it possible.
• Repudiation is not a TLCTC threat cluster either. It is better understood as a consequence-side integrity or auditability problem, or as a failure of proof and logging objectives. TLCTC’s standardized Data Risk Events are confidentiality, integrity, accessibility, and availability, not "repudiation" as a top-level threat category.
• Information Disclosure is even clearer. In TLCTC, that is not a threat class at all. It is a Data Risk Event: + [DRE: C], meaning loss of confidentiality. Something causes the disclosure, but the disclosure itself is the effect.
• Denial of Service is one of the most misleading STRIDE labels. In TLCTC, #6 Flooding Attack applies only when the mechanism is finite-capacity exhaustion by volume or intensity. Many situations described as "DoS" do not belong to #6 at all. A service crash caused by a code flaw belongs to #2 or #3. Ransomware making data unusable is #7 + [DRE: Ac], not #6. The label "denial of service" often describes an outcome while pretending to be a cause.
• Elevation of Privilege is also not a TLCTC threat cluster. TLCTC treats it as an effect or an intra-system boundary crossing that occurs during a step. The v2.1 extension makes this explicit: internal privilege, sandbox, process, and hypervisor crossings can be annotated, but they do not replace cause classification. The right question is not "Was there elevation of privilege?" but "What generic vulnerability caused the privilege boundary to be crossed?"

So STRIDE is useful, but its usefulness comes with a structural cost. It helps people think, yet it does not force them to think with consistent causal categories.

STRIDE extensions reveal the pressure on the model

That weakness is not merely theoretical. In the field, practitioners have extended STRIDE itself. One visible example is STRIDE-LM, which adds Lateral Movement as a seventh category to make STRIDE more useful in network-defense and system-of-systems contexts. That extension is documented both in practitioner material and in external references that describe STRIDE-LM as a response to STRIDE’s original engineering focus.

From a TLCTC perspective, that is revealing. It suggests that practitioners feel the need to stretch STRIDE beyond its original six labels because real attacks do not sit comfortably inside them. But TLCTC would say the deeper issue remains unresolved: lateral movement is not a top-level threat class. It is a sequence pattern composed of causal steps. The same applies to privilege escalation, persistence, and many other labels that modern practice treats as if they were threat categories in their own right. TLCTC’s answer is not to keep adding more buckets. It is to classify the actual attack steps and let the path express the movement.

Why TLCTC is the more natural next step

This is where your argument becomes strongest.

If Microsoft moved away from DREAD because the scoring was too subjective, and if STRIDE survived because it is useful for brainstorming but remains semantically mixed, then a framework that preserves brainstorming simplicity while fixing the semantic structure becomes a very plausible next step.

That is exactly where TLCTC enters.

TLCTC gives analysts ten cause-oriented top-level clusters and keeps consequences separate as Data Risk Events. In practical workshop terms, that is not harder than brainstorming with STRIDE. In many ways it is cleaner. Instead of asking whether something is "Tampering" or "Information Disclosure," the analyst asks a more disciplined question: what generic vulnerability was exploited first? Once that is answered, effects are recorded separately as + [DRE: C], + [DRE: I], + [DRE: Ac], or + [DRE: Av]. That is simple enough for brainstorming, but much stronger for analysis.

This is also why TLCTC can reasonably claim to be better for brainstorming than STRIDE, not just better for post hoc classification. STRIDE brainstorming often begins by mixing causes and effects at the whiteboard. TLCTC starts with causal discipline from the beginning. It does not make the workshop more complicated; it makes the output more coherent. The ten clusters plus DRE notation are small enough to be memorable, broad enough to cover the landscape, and structured enough to preserve meaning across cases.

The supply-chain example shows the difference

Consider a compromised third-party software update. DREAD can only tell you how severe the situation appears. STRIDE struggles to decide whether this is mainly Tampering, Spoofing, or something else. TLCTC handles it directly with #10 Supply Chain Attack, because the decisive moment is the Trust Acceptance Event: the point at which the organization accepts the third-party artifact or decision as authoritative.

A clean TLCTC path might look like this:

#10 → #7 + [DRE: C] → #4

The organization accepts the poisoned trust dependency (#10), the malicious payload executes (#7), sensitive material such as credentials is exposed as a confidentiality event (+ [DRE: C]), and those credentials are later used to impersonate an identity (#4). TLCTC keeps the causal chain intact and does not force the analyst to flatten the entire scenario into a single bucket.

The shortest defensible conclusion

DREAD tells you how urgent a situation appears. STRIDE helps you brainstorm what kinds of problems might exist. TLCTC tells you what causal category an attack step actually belongs to, how attack steps chain together, and where controls should sit.

That is why Microsoft’s abandonment of DREAD matters. It shows that scoring without semantic stability is not enough. That is also why STRIDE’s survival matters. It shows that practitioners need a simple brainstorming grammar. And that is why TLCTC can be argued to be the more natural next step: it offers the same workshop usefulness, but with cleaner categories, explicit sequences, and a strict separation between threats and consequences.

If cybersecurity wants to behave more like a science, it must stop blending causes with outcomes. DREAD was not enough. STRIDE was useful, but incomplete. TLCTC’s claim is that the discipline now needs a cause-oriented grammar that is simple enough to use and precise enough to trust.