Cause-Oriented SOAR: TLCTC for Cortex XSOAR and XSIAM

What is TLCTC?

The Top Level Cyber Threat Clusters (TLCTC) framework is a cause-oriented, axiomatic threat taxonomy. It classifies cyber threats by why compromise happens — the generic vulnerability the attacker exploits — not by what happens (outcomes like “ransomware”, “data breach”, or “insider threat”). Exactly 10 non-overlapping clusters cover the entire threat space, governed by 10 axioms and a small set of normative classification rules. It is licensed under CC BY 4.0 and maintained openly. For the framework, whitepaper, glossary, tools, and more: tlctc.net.

The problem this integration solves

Most SOAR deployments structure playbooks around outcomes: a “Ransomware Playbook,” a “Phishing Playbook,” a “Data Exfiltration Playbook.” TLCTC’s Axiom III prohibits this — outcomes are consequences, not threats. When playbooks branch on the consequence, you end up duplicating work across every CVE that produces the same outcome and missing the actual generic vulnerability the attacker exploited.

A cause-oriented SOAR turns this inside out: one master playbook per cluster, regardless of the eventual outcome. A #3 Exploiting Client playbook covers every browser exploit you’ll ever face. A #4 Identity Theft playbook handles every credential-application step regardless of how the credential was obtained. A #10 Supply Chain playbook fires at the Trust Acceptance Event no matter which package was compromised.

That’s what this integration ships.

What’s in the release

The integration is published in two parallel builds — same functional scope, packaged for two different Palo Alto Networks SOAR platforms:

Both builds ship:

• 10 cluster-scoped master playbooks — TLCTC-01-AbuseOfFunctions through TLCTC-10-SupplyChain. One per cause, none per outcome.
• An ATT&CK→TLCTC classifier that derives the cluster automatically from the technique IDs your XDR/SIEM already produces.
• A Velocity-Class router branching response by Δt: VC-4 record-only (EDR enforces sub-second), VC-3 auto-contain (minutes), VC-2 human-gated (hours), VC-1 hand-off to threat hunting (days+).
• An RS Container sub-playbook implementing both Direct Response and Propagated PR controls — automatic GDPR Art. 33 and NIS2 Art. 23 trigger logic based on the Data Risk Event chain.
• A Layer 3 attack-path emitter that produces a schema-valid JSON instance on incident close, ready for archival, retro-analysis, or cross-incident pattern study.

Tagged release: cortex-xsoar-v1.0.0.

Where to find what

Start here

• Top-level overview — picks the right build for your platform.
• Integration repo root — both builds, side by side.

XSOAR 6.2 build

XSOAR 8.x + XSIAM Content Pack

Underlying TLCTC artefacts the integration depends on

The five rules the classifier enforces

The integration is interesting because the classification automation doesn’t just look up a technique → cluster. It enforces the framework’s normative rules so that a single ATT&CK technique can fire multiple cluster playbooks when the framework demands it.

The full test suite — five reproducible cases with expected playbook firing sequences and emitted Layer 3 paths — lives in test-cases.md.

Why this matters operationally

Three concrete payoffs once the pack is live:

1. One playbook covers every CVE that shares a cause. A new browser zero-day arrives → your #3 Exploiting Client playbook already covers it. No content update required.
2. Regulatory triggers stop being ad-hoc. GDPR Art. 33 and NIS2 Art. 23 fire deterministically based on the Data Risk Event chain (DRE on PII for GDPR; severity threshold for NIS2) — implemented as the Propagated PR branches of the RS Container sub-playbook. No more chasing notification deadlines case by case.
3. Every closed incident produces a comparable artefact. The Layer 3 attack-path JSON emitted on close is schema-validated and structurally identical across incidents. Cross-incident pattern study, attacker-profile analysis, and risk register updates run on a single shape.

Getting started

1. Pick your build: 6.2 or 8.x/XSIAM (the integrations index has the deciding table).
2. Run the deploy runbook end-to-end — both builds include a complete install path with smoke tests:
   • 6.2 runbook
   • 8.x / XSIAM runbook
3. Run the five acceptance tests before promoting to production. Failures point to either a stale lookup list or a misconfigured ATT&CK feed.
4. Wire your XDR/SIEM to the classifier — anything that produces ATT&CK technique IDs will work; adapt the mapper if your feed uses a non-standard field path.

Questions, contributions, and issue reports are welcome on the TLCTC GitHub repo.