MITRE ATT&CK & STIX Integration with TLCTC V2.0

The Integration Challenge

Fragmented threat intelligence fails to connect strategic risk management with operational security. While MITRE ATT&CK and STIX enable detailed sharing, they lack a standardized high-level taxonomy that answers: "What generic vulnerability was exploited?" — the question that bridges threat intelligence with actionable defense.

What's New in V2.0

TLCTC V2.0 introduces three major enhancements that transform how we document, share, and analyze attack intelligence:

Attack Velocity (Δt)

Temporal dimension measuring defender response windows between attack steps.

Domain Boundaries

Explicit marking of responsibility sphere transitions in attack paths.

JSON Architecture

Four-file structure enabling machine-readable threat intelligence exchange.

V2.0 Notation System

TLCTC employs two complementary notation systems that map bi-directionally:

Layer	Format	Example	Use Case
Strategic	`#X`	`#9 → #7 → #4`	Executive comms, risk boards
Operational	`TLCTC-XX.YY`	`TLCTC-09.00 → TLCTC-07.00`	SIEM rules, automation, APIs

Attack Path Operators

Operator	Syntax	Meaning
Sequence	`→` or `->`	Sequential attack steps
Parallel	`(#X + #Y)`	Simultaneous/coordinated actions
Velocity	`→[Δt=2h]`	Time between steps
Domain Boundary	`\|\|[ctx][@Src→@Tgt]\|\|`	Responsibility sphere transition
DRE Tag	`+ [DRE: C, I, Av/Ac]`	Data Risk Event — Av = data gone/unreachable, Ac = present but unusable (e.g. ransomware)
Transit (v2.1)	`@Src⇒@Carrier→@Tgt`	Relay/carrier that passes the attack through (not source or target)
Intra-System (v2.1)	`\|[type][@from→@to]\|`	Boundary crossing within one host (sandbox, privilege, process, hypervisor)
Unresolved (v2.1)	`?` / `…`	Single unresolved step / unresolved gap (epistemic, not a cluster)

Key Principle: DRE tags record outcomes (Confidentiality, Integrity, Availability impacts) but do not change cluster classification. TLCTC classifies causes, not consequences.

Attack Velocity Classes

V2.0 introduces four operational velocity classes that describe the defender's feasible response mode based on the time available between attack steps:

VC-1 Strategic

Days → Months

Log retention, threat hunting, strategic monitoring

VC-2 Tactical

Hours

SIEM alerting, analyst triage, guided response

VC-3 Operational

Minutes

SOAR/EDR automation, rapid containment, playbooks

VC-4 Real-Time

Seconds → Milliseconds

Architecture hardening, circuit breakers, rate limits

Cluster Topology

TLCTC V2.0 classifies clusters by their topological role in attack paths:

#	Cluster Name	Topology	Generic Vulnerability
#1	Abuse of Functions	Internal	Functional scope/trust
#2	Exploiting Server	Internal	Server-side implementation flaws
#3	Exploiting Client	Internal	Client-side implementation flaws
#4	Identity Theft	Internal	Identity-artifact binding
#5	Man in the Middle	Internal	Lack of E2E protection
#6	Flooding Attack	Internal	Finite capacity limitations
#7	Malware	Internal	Designed execution capability
#8	Physical Attack	Bridge	Physical accessibility
#9	Social Engineering	Bridge	Human psychological factors
#10	Supply Chain Attack	Bridge	Third-party trust dependencies

Bridge Clusters (#8, #9, #10) inherently enable attacks to cross domain boundaries — transitioning from one responsibility sphere to another. The domain boundary operator ||[context][@Source→@Target]|| SHOULD accompany bridge cluster steps.

v2.1 Extensions (Additive)

Version 2.1 adds three backward-compatible operator families. They are purely additive — existing v2.0 paths remain valid, and none of these annotations ever change cluster classification.

Transit Boundary Operator

Marks a sphere that carries or relays the attack but is neither its source nor its target. ⇒ denotes transit, → denotes final delivery:

#9 ||[sms][@Attacker⇒@SMSProvider→@Victim]|| → #3

R-TRANSIT-3: Vendor code running on the target device is not transit — Safari on the victim's phone is the attack surface (classify by R-ROLE as #3), not a relay. And transit is not #10: a relay passes the attack through, while #10 Supply Chain marks trust acceptance (a compromised package installed by the target).

Intra-System Boundary Operator

Marks a boundary crossing within a single host, using single-pipe delimiters and one of four types — sandbox, privilege, process, hypervisor:

#3 |[sandbox][@renderer→@os]|

R-INTRA-7: Intra-system boundaries never change cluster classification — they are observability annotations, not classification inputs. R-INTRA-9: the memory type is explicitly deferred and MUST NOT be used.

Unresolved-Step Operators

Incident analysis is iterative — evidence arrives over time. Two operators capture forensic uncertainty: ? for a single unresolved step (exactly one step occurred, cluster unknown) and … for an unresolved gap (at least one step occurred; count and clusters unknown):

#3 →[Δt=0s] #7 →[Δt=4h] ? →[Δt=<10m] #4 → #1

Use the weakest annotation the evidence forces. The binary rule (R-UNRES-9): if any cluster can be defended — even weakly — use #X [conf=low], not ?.

State	Syntax	Use when
Classified	`#X`	Cluster assigned, evidence supports it
Low-confidence	`#X [conf=low]`	Best-supported cluster with explicit caveat
Inferred	`#X [inferred]`	Not directly observed but logically required
Unresolved	`?` / `…`	No cluster can be defended on available evidence

R-UNRES-2/3/5: ? and … are epistemic annotations, not clusters — they are excluded from statistics and MUST NOT carry DRE tags. Every unresolved step is an open analytical task to replace as evidence matures (R-UNRES-7), and MUST carry a prose note explaining what is unknown (R-UNRES-8).

Proposed STIX Enhancements

The following custom STIX objects extend the 2.1 specification to incorporate TLCTC V2.0 concepts:

x-threat-cluster Object

Represents a TLCTC threat cluster with its generic vulnerability and topology classification:

x-threat-cluster.json

{
  "type": "x-threat-cluster",
  "spec_version": "2.1",
  "id": "x-threat-cluster--a1b2c3d4-...",
  "name": "Social Engineering",
  "x_tlctc_id": "TLCTC-09.00",
  "x_tlctc_strategic": "#9",
  "description": "Attacks exploiting human psychological factors...",
  "x_generic_vulnerability": "Human psychological factors",
  "x_topology": "bridge",
  "x_typical_domain_boundaries": ["@External→@Org", "@HR→@Org"],
  "x_framework_version": "2.0"
}

x-attack-sequence Object (V2.0)

Documents complete attack paths with velocity annotations, domain boundaries, and DRE tags:

x-attack-sequence-v2.json

{
  "type": "x-attack-sequence",
  "spec_version": "2.1",
  "id": "x-attack-sequence--e5f6g7h8-...",
  "name": "Phishing to Credential Abuse Chain",
  "x_framework_version": "2.0",
  "x_sequence_notation": "#9 →[Δt=2h] #7 →[Δt=15m] #1 →[Δt=5m] #4",
  "x_dominant_velocity_class": "VC-3",
  "attack_steps": [
    {
      "step_number": 1,
      "x_tlctc_id": "TLCTC-09.00",
      "x_tlctc_strategic": "#9",
      "stage": "initial",
      "x_responsibility_sphere": "@External",
      "x_domain_boundary": {
        "context": "email",
        "source": "@External",
        "target": "@Org"
      },
      "mitre_techniques": ["T1566.001"],
      "description": "Spear-phishing email with malicious attachment"
    },
    {
      "step_number": 2,
      "x_tlctc_id": "TLCTC-07.00",
      "x_tlctc_strategic": "#7",
      "stage": "intermediate",
      "x_responsibility_sphere": "@Org",
      "x_delta_t": {
        "value": 2,
        "unit": "h",
        "velocity_class": "VC-2"
      },
      "mitre_techniques": ["T1204.002"],
      "description": "User executes malicious macro"
    },
    {
      "step_number": 3,
      "x_tlctc_id": "TLCTC-01.00",
      "x_tlctc_strategic": "#1",
      "stage": "intermediate",
      "x_responsibility_sphere": "@Org",
      "x_delta_t": {
        "value": 15,
        "unit": "m",
        "velocity_class": "VC-3"
      },
      "x_credential_event": "acquisition",
      "mitre_techniques": ["T1003"],
      "description": "Credential dumping via LSASS abuse (R-CRED: acquisition maps to enabling cluster #1)"
    },
    {
      "step_number": 4,
      "x_tlctc_id": "TLCTC-04.00",
      "x_tlctc_strategic": "#4",
      "stage": "final",
      "x_responsibility_sphere": "@Org",
      "x_delta_t": {
        "value": 5,
        "unit": "m",
        "velocity_class": "VC-3"
      },
      "x_credential_event": "application",
      "x_dre_tags": ["C", "I"],
      "mitre_techniques": ["T1078"],
      "description": "Lateral movement using stolen credentials (Axiom X: credential use is always #4)"
    }
  ]
}

Four-File JSON Architecture

TLCTC V2.0 standardizes threat intelligence sharing through a layered file architecture:

┌─ FRAMEWORK LAYER (Universal / Stable)

tlctc-framework.json — Core cluster definitions

tlctc-responsibility-spheres.json — Domain boundaries

tlctc-attack-sequence-schema.json — Validation schema

└─ INTELLIGENCE LAYER (Dynamic / Per-Incident)

[incident-id]-attack-path.json — Specific attack instance

Real-World Case Study: Emotet Campaign

The Emotet banking trojan campaign demonstrates a sophisticated multi-stage attack path. Here's how V2.0 notation captures both structure and timing:

V2.0 Attack Path Notation:

#9 ||[email][@External→@Org]|| →[Δt=hours] #7 →[Δt=minutes] #7 →[Δt=days] #1 →[Δt=minutes] #4 →[Δt=minutes] #7 + [DRE: C, Ac]

emotet-attack-path.json

{
  "metadata": {
    "sequence_id": "EMOTET-2024-001",
    "attack_title": "Emotet Initial Access to Domain Compromise",
    "framework_version": "2.0",
    "created": "2024-03-15T10:00:00Z",
    "analyst": "SOC Team Alpha"
  },
  "x_sequence_notation": "#9 →[Δt=hours] #7 →[Δt=minutes] #7 →[Δt=days] #1 →[Δt=minutes] #4 →[Δt=minutes] #7",
  "x_dominant_velocity_class": "VC-2",
  "attack_steps": [
    {
      "step_number": 1,
      "tlctc_cluster": {
        "strategic": "#9",
        "operational": "TLCTC-09.00"
      },
      "stage": "initial",
      "responsibility_sphere": "@External",
      "domain_boundary": {
        "context": "email",
        "source": "@External",
        "target": "@Org"
      },
      "description": "Phishing email with malicious Word document"
    },
    {
      "step_number": 2,
      "tlctc_cluster": {
        "strategic": "#7",
        "operational": "TLCTC-07.00"
      },
      "stage": "intermediate",
      "responsibility_sphere": "@Org",
      "delta_t": {
        "value": "hours",
        "velocity_class": "VC-2"
      },
      "software": [
        { "name": "Microsoft Word", "role": "exploit-delivery" }
      ],
      "mitre_techniques": ["T1204.002"],
      "description": "Macro execution drops Emotet loader"
    },
    {
      "step_number": 3,
      "tlctc_cluster": {
        "strategic": "#7",
        "operational": "TLCTC-07.00"
      },
      "stage": "intermediate",
      "responsibility_sphere": "@Org",
      "delta_t": {
        "value": "minutes",
        "velocity_class": "VC-3"
      },
      "software": [
        { "name": "Emotet", "role": "malware" }
      ],
      "mitre_techniques": ["T1055"],
      "description": "Secondary payload injection"
    },
    {
      "step_number": 4,
      "tlctc_cluster": {
        "strategic": "#1",
        "operational": "TLCTC-01.00"
      },
      "stage": "intermediate",
      "responsibility_sphere": "@Org",
      "delta_t": {
        "value": "days",
        "velocity_class": "VC-1"
      },
      "software": [
        { "name": "Mimikatz", "role": "attack-tool" }
      ],
      "mitre_techniques": ["T1003.001"],
      "x_credential_event": "acquisition",
      "description": "Credential dumping via LSASS abuse (R-CRED: acquisition maps to enabling cluster #1)"
    },
    {
      "step_number": 5,
      "tlctc_cluster": {
        "strategic": "#4",
        "operational": "TLCTC-04.00"
      },
      "stage": "intermediate",
      "responsibility_sphere": "@Org",
      "delta_t": {
        "value": "minutes",
        "velocity_class": "VC-3"
      },
      "mitre_techniques": ["T1078"],
      "x_credential_event": "application",
      "description": "Lateral movement using stolen credentials (Axiom X: credential use is always #4)"
    },
    {
      "step_number": 6,
      "tlctc_cluster": {
        "strategic": "#7",
        "operational": "TLCTC-07.00"
      },
      "stage": "final",
      "responsibility_sphere": "@Org",
      "delta_t": {
        "value": "minutes",
        "velocity_class": "VC-3"
      },
      "fec_executed": true,
      "dre_tags": ["C", "Ac"],
      "mitre_techniques": ["T1486"],
      "description": "Ransomware payload execution — exfiltration (C) + encryption (Ac: data present but unusable, per Axiom III)"
    }
  ],
  "business_impacts": [
    {
      "impact_id": "IMP-001",
      "category": "operational",
      "description": "72-hour business disruption",
      "linked_steps": [6]
    },
    {
      "impact_id": "IMP-002",
      "category": "financial",
      "description": "Ransom demand + recovery costs",
      "linked_steps": [6]
    }
  ]
}

Attack Timeline Analysis

The velocity annotations reveal critical defender windows:

Transition	Δt	Velocity Class	Defender Action
#9 → #7	hours	VC-2	Email filtering, user awareness
#7 → #7	minutes	VC-3	EDR detection, process isolation
#7 → #1	days	VC-1	Threat hunting, detect credential dumping
#1 → #4	minutes	VC-3	Credential rotation, privileged-access monitoring
#4 → #7	minutes	VC-3	SOAR playbooks, network segmentation

Operational Insight: The #7 → #1 transition shows a VC-1 (Strategic) window of days — this is where defenders have the most time to detect and respond. Threat hunting should prioritize detecting credential dumping (#1, acquisition) before those credentials are weaponized for lateral movement (#4).

Integration Benefits

Combining TLCTC V2.0 with STIX and MITRE ATT&CK enables organizations to:

Velocity-Aware Detection: Map SIEM rules to velocity classes, ensuring automation matches attacker speed
Domain Boundary Analysis: Identify control gaps at responsibility sphere transitions (vendor, cloud, physical)
Strategic Communication: Use #X notation for board reports while TLCTC-XX.YY drives SOC automation
Pattern Recognition: Aggregate attack paths across incidents to identify sector-specific threat patterns
Control Prioritization: Align security investments with the most impactful clusters and transitions

Getting Started

To integrate TLCTC V2.0 into your threat intelligence workflow:

Download the framework JSON files from tlctc.net
Map existing MITRE ATT&CK techniques to TLCTC clusters using the mapping table
Create custom STIX objects using the schemas above
Annotate incident timelines with velocity data to derive Δt values
Validate attack paths against tlctc-attack-sequence-schema.json

Conclusion

TLCTC V2.0's integration with STIX transforms threat intelligence from a documentation exercise into an operational tool. Attack Velocity provides the temporal dimension defenders need to calibrate their response capabilities. Domain Boundary Operators make responsibility handoffs explicit. The standardized JSON architecture enables machine-readable exchange across organizational boundaries.

The result: a unified language where strategic risk managers and SOC analysts can finally speak the same threat taxonomy — grounded in causes, not outcomes.

Download V2.1 Whitepaper

Enhancing STIX with TLCTC V2.0

The Integration Challenge

What's New in V2.0

Attack Velocity (Δt)

Domain Boundaries

JSON Architecture

V2.0 Notation System

Attack Path Operators

Attack Velocity Classes

Cluster Topology

v2.1 Extensions (Additive)

Transit Boundary Operator

Intra-System Boundary Operator

Unresolved-Step Operators

Proposed STIX Enhancements

x-threat-cluster Object

x-attack-sequence Object (V2.0)

Four-File JSON Architecture

Real-World Case Study: Emotet Campaign

Attack Timeline Analysis

Integration Benefits

Getting Started

Conclusion