MITRE ATT&CK and TLCTC: Detection Meets Risk Management

Executive Summary

MITRE ATT&CK has become the global standard for describing adversary behaviors, but it is not a risk management framework. It tells you how attackers operate, not which generic vulnerabilities you are exposing. This blog explains the fundamental relationship between these two frameworks and how organizations can use them together—keeping ATT&CK for detection while adding TLCTC as the strategic risk layer that ATT&CK was never designed to provide.

The Core Distinction: Two Different Questions

Before diving into mapping mechanics, we need to understand what each framework is actually designed to answer.

MITRE ATT&CK: "What Can We Detect?"

MITRE ATT&CK is fundamentally a detection framework:

Describes observable adversary behaviors.
Organized by attacker lifecycle phases (tactics).
Includes pre-attack preparation (Reconnaissance, Resource Development).
Focuses on: "What techniques do attackers use, and how can we observe them?"

ATT&CK excels at cataloging the how—the specific procedures adversaries employ at each stage of an attack. This makes it invaluable for threat hunting, detection engineering, and red team exercises.

TLCTC: "What Vulnerability Enables This Attack?"

TLCTC is fundamentally a risk management framework:

Categorizes threats by the generic vulnerability exploited.
Follows the Bow-Tie model: Threats (causes) → Loss of Control → Consequences.
Focuses on: "What root weakness in our systems, processes, or people does this exploit?"
Requires a protected asset in scope.

TLCTC excels at the why—the underlying vulnerability that makes an attack possible in the first place. This connects directly to control objectives, risk registers, and resource allocation decisions.

The Key Implication

Not every MITRE technique maps cleanly to a TLCTC cluster. Some techniques describe attacker preparation (threat potential in other domains), post-compromise enumeration (no new vulnerability), or consequences rather than causes. Understanding this asymmetry is the first step toward effective use.

The Mapping Challenge: Technique in Context

Here's where many organizations go wrong: they try to create a static, one-to-one lookup table between ATT&CK techniques and TLCTC clusters. This doesn't work. The same ATT&CK technique can map to different TLCTC clusters depending on how it's implemented and in which domain it occurs.

The "Technique in Context" Principle

Never map just the label string. Always ask:
"When an adversary uses this technique in this way, in this domain, what generic vulnerability is being abused on the protected asset?"

Consider T1059.001 (PowerShell). Is this:

#1 Abuse of Functions? If legitimately invoking PowerShell.exe with expected parameters.
#7 Malware? If executing a foreign malicious script.
#1 → #7? If abusing PowerShell to invoke and execute a foreign script (most common).

Domain Matters: Where Does the Attack Happen?

Before any mapping, determine the domain:

Domain	Description	Risk Relevance
@Org	Your organization's environment	Your risk scope—map to TLCTC
@3P	Third-party / supply chain	May affect you via #10
@AttackerInfra	Attacker's own infrastructure	Threat potential, not threat
@OtherVictims	Other organizations being compromised	Threat potential, not your threat

The Classification Decision Tree

Once you've established domain and affected asset, walk through these questions in order:

Designed Function Abuse? Is the attacker abusing a DESIGNED function/feature/API/configuration, with NO code flaw and NO foreign binary required?
→ #1 Abuse of Functions

Server-Side Code Flaw? Is the attacker exploiting a CODE IMPLEMENTATION FLAW on the SERVER side?
→ #2 Exploiting Server

Client-Side Code Flaw? Is the attacker exploiting a CODE IMPLEMENTATION FLAW in a CLIENT role?
→ #3 Exploiting Client

Identity/Credential Use? Is the attacker's main power that they can ACT AS A LEGITIMATE IDENTITY using credentials/tokens/keys?
→ #4 Identity Theft

Q5-10

Continue for #5 MitM, #6 Flooding, #7 Malware (Foreign Code), #8 Physical, #9 Social Engineering, and #10 Supply Chain.

The Software Quadrant: #1, #2, #3, and #7

Most ATT&CK techniques live in the "software" space. This disambiguation logic handles the majority of mappings:

START: Is there a CODE FLAW being exploited?
  │
  ├── YES → Is it server-side or client-side?
  │          ├── Server → #2 Exploiting Server
  │          └── Client → #3 Exploiting Client
  │          
  │          Note: The payload delivered is usually the NEXT step (#7)
  │          Giving paths like: #2 → #7 or #3 → #7
  │
  └── NO → Is FOREIGN CODE being executed?
           │
           ├── YES → #7 Malware
           │         Note: If launched via legitimate tool (LOLBAS) → #1 → #7
           │
           └── NO → #1 Abuse of Functions
                    (Pure abuse of admin tools, APIs, configuration, etc.)

The Credential Rule: Acquisition vs. Use

TLCTC Axiom X establishes that credentials are system control elements with a dual operational nature. This distinction is critical for accurate mapping.

Category	Description	Example Mapping
Acquisition	How credentials are obtained maps to the enabling cluster.	Keylogger → #7 Phishing → #9 SQLi → #2
Use	How credentials are used ALWAYS maps to #4.	Presenting stolen creds → #4 Identity Theft

Complete Attack Path Example:
#9 → #4 → #1

Breaking this down:
#9 – Phishing tricked user into entering credentials.
#4 – Attacker uses stolen credentials to authenticate.
#1 – Attacker abuses admin functions with that authenticated identity.

Handling Reconnaissance and Resource Development

These ATT&CK tactics often describe attacker preparation (Threat Potential), not attacks against your assets. If a technique only affects @AttackerInfra or @OtherVictims, it represents preparations, not an actual threat against your assets.

Mapping Guidance: For most of these, the status is N/A – Threat Potential. Only map to a TLCTC cluster when your organization is the specific target of exploitation (e.g., authenticated discovery with stolen credentials).

Putting It Together: From SOC to Risk Register

The value of this mapping emerges when you connect operational detection to strategic risk management.

Enlarge Diagram

Figure: The Translation Layer. Transforming operational telemetry into strategic risk intelligence.

What This Enables

For the SOC: Continue detecting T1190, T1566, T1078. No change to detection engineering practices.
For Risk Management: Aggregate detections into cluster exposure. Connect to control objectives per cluster. Enable board-level communication.
For Control Design: Measure not just coverage ("Do we detect T1078?") but performance ("What's our Δt for #4 attacks?").

Quality Checklist for Mapping

Domain identified: Is it clear where this technique happens?
Asset identified: Which protected asset is affected?
Cause, not consequence: Are you mapping the vulnerability exploited, not the outcome?
Single step vs. path: If multiple steps, did you express them as an attack path?
Credentials handled correctly: Acquisition vs. use distinction clear?

Conclusion: Complementary, Not Competitive

MITRE ATT&CK and TLCTC are not competing frameworks. They answer different questions for different audiences. By mapping between them, organizations can maintain world-class detection using ATT&CK while enabling strategic risk management using TLCTC—creating a common language from the SOC floor to the boardroom.