Refining TLCTC Attack Path Notation: Strategic Inline #10 Meets Operational Boundary Operators

Date: 2025/09/22 | Author: Bernhard Kreinz, TLCTC.net

We’re clarifying how to show trust/domain crossings in TLCTC attack paths. Keep inline #10 for strategic, human‑readable sequences (e.g., #1 → #10 → #3). For operational, machine‑parsable use (STIX relationships, ATT&CK mappings, forensics), introduce a boundary operator ||[channel][@src→@dst]|| to mark the exact crossing (e.g., #1 ||[svc/idp][@Operator→@Target]|| → #3). This retains cluster purity, improves precision, and enhances interoperability. We include examples, boundary tests, and a minimal grammar + JSON.

Why This Refinement Matters in 2025

Supply‑chain and third‑party trust crossings are a dominant driver of modern incidents. To keep TLCTC’s no‑overlap axiom intact while enabling automation, we:

Use inline #10 strategically to signal where supply‑chain risk appears in an attack path.
Use the boundary operator operationally to encode how the trust/domain hop occurred and between which domains.

This builds directly on the TLCTC white paper v1.7.1’s dual‑layer approach (strategic vs. operational) and prior blog guidance on explicit boundaries, while aligning cleanly with STIX SROs and ATT&CK supply‑chain technique families.

Principle: #10 marks the trust shift; it is not a bucket for effects. Post‑crossing effects still map to their own clusters (e.g., #7 Malware).

Editorial note: Insert current, sourced figures for 2025 supply‑chain prevalence/costs and sector targeting in the publication version.

Quick Recap: The 10 TLCTC Clusters (strategic definitions)

#1 Abuse of Functions – Misuse of legitimate features/configurations via intended interfaces, no code flaw and no foreign code execution.

#2 Exploiting Server – Exploiting server‑side source code implementation flaws with exploit code.

#3 Exploiting Client – Exploiting client‑role source code implementation flaws with exploit code.

#4 Identity Theft – Acquisition/misuse of credentials or identity artifacts (passwords, tokens, keys, sessions) to operate as a legitimate identity.

#5 Man in the Middle (MitM) – Abusing a privileged position on the communication path to intercept/alter/relay.

#6 Flooding Attack – Abusing finite capacity to degrade/deny service.

#7 Malware – Abusing the environment’s capability to execute foreign executable content (incl. scripts/LOLBAS as code execution).

#8 Physical Attack – Unauthorized physical interaction or interference with hardware/facilities/media/signals.

#9 Social Engineering – Psychological manipulation of people.

#10 Supply Chain Attack – Compromise via trusted third‑party components/services/updates; bridge for trust import, not the effect.

Axioms recap: Non‑overlap; cause‑oriented; each cluster targets a generic vulnerability; sequences can be chained; credentials are control elements.

The Refinement: Inline #10 (Strategic) vs. Boundary Operator (Operational)

Original practice: Inline #10 inside a path (e.g., #9 → #4 → #1 → #10 → #3) to signal the moment trust from outside becomes causal for the next step. Limitation: In long chains or delegated flows, readers and tools can blur #10 as if it were the cause/effect rather than the crossing.

Refinement:

Keep inline #10 for leadership views and high‑level threat modeling.
Add a first‑class boundary operator for operational detail:
||[channel][@src→@dst]||
- channel ∈ { updates, dev, hardware, svc/idp }
- @src, @dst ∈ domain labels (e.g., @Vendor, @ORG, @CUST)

Interpretation: The next step is causal only if the trust/domain crossing exists. Remove the crossing → the path breaks.

Refinements:

Optional strategic sub‑vectors for #10 (e.g., #10.1 updates, #10.2 dev, #10.3 hardware) maintain human readability.
Operationally, always prefer the boundary operator to carry channel + domains; reserve #10.x to strategic summaries.

Guardrails:

Boundaries cannot start or end a path. They must be followed by a cluster step.
Multiple, non‑adjacent boundaries are allowed; never chain consecutive boundaries with no step between.
If the crossing is not causal, omit it.

Minimal, Parseable Grammar

Atoms

CLUSTER := "#" DIGIT DIGIT ( "." DIGIT DIGIT )?
DOMAIN  := "@" ALNUM+
CHAN    := "updates" | "dev" | "hardware" | "svc/idp"
BOUND   := "||[" CHAN "][" DOMAIN "→" DOMAIN "]||"
EDGE    := "→"
PAR     := "+"          ; parallel
REP     := "{" INT "}"  ; repetition

Compositions

STEP    := CLUSTER | BOUND | GROUP
GROUP   := "(" PATH ")" REP?
PATH    := STEP ( (EDGE|PAR) STEP )*

Annotations (optional): {t=ISO8601, conf=0..1, evidence=ID}

Boundary Tests Checklist (Operational)

Causality: If removing third‑party trust stops the next step, insert a boundary.
Provenance: If external artifacts or decisions are consumed, specify the channel.
Semantics: Keep clusters pure; #10/boundary is the bridge, not the effect.
Multiplicity: Use multiple boundaries where paths traverse multiple trust tiers.

Practical Examples (Strategic → Operational)

1) Repository Compromise

Strategic: #9 → #4 → #1 → #10 → #3

Operational: #9 → #4 → #1 ||[dev][@3P→@ORG]|| → #3

Reading: Social Engineering → Identity Theft → Abuse of Functions → dev trust import → Exploiting Client.

2) Build System Compromise

Strategic: #2 → #4 → #1 → #10.2 → #7

Operational: #2 → #4 → #1 ||[dev][@Vendor→@CUST]|| → #7

Reading: Exploiting Server → Identity Theft → Abuse of Functions → dev boundary → Malware.

3) Malicious Package Publication (Typosquatting)

Strategic: #1 → #10 → #7

Operational: #1 ||[dev][@Attacker→@ORG]|| → #7

Reading: Abuse of Functions → dev boundary → Malware.

4) Update Distribution Compromise

Variant (Server Compromise):

Strategic: #2 → #1 → #10.1 → #7

Operational: #2 → #1 ||[updates][@3P→@ORG]|| → #7

Variant (On‑Path):

Strategic: #5 → #10.1 → #7

Operational: #5 ||[updates][@MITM→@ORG]|| → #7

5) Insider at Vendor

Backdoor:

Strategic: #1 → #10.2 → #7

Operational: #1 ||[dev][@Vendor→@CUST]|| → #7

Vuln Intro:

Strategic: #1 → #10.2 → #2/#3

Operational: #1 ||[dev][@Vendor→@CUST]|| → #2/#3

Pegasus Campaigns: Applying the Refinement (illustrative)

Zero‑click messaging exploits (2019–2021)

Strategic: #1 → #10 → #3 → #7

Operational: #1 ||[svc/idp][@Operator→@Target]|| → #3 → #7

Reading: Abuse of Functions (service delegation misuse) → service boundary → Exploiting Client (parsing) → Malware.

Network Injections (2019)

Strategic: #5 → #1 → #10 → #3 → #7

Operational: #5 → #1 ||[updates][@Operator→@Target]|| → #3 → #7

Use cautious phrasing and cite public technical reports when claiming specific mechanics.

Canonical Patterns (Cookbook)

Repository → IDE: #9 → #4 → #1 → #10 → #3 (expand with ||[dev]…||)
Update Mechanism Abuse: #4 → #1 → #10.1 → #7
Development Pipeline: #2 → #1 → #10.2 → #7
Third‑Party Library: #1 → #10 → #2 (or #7 depending on effect)
Hardware Supply Chain: #8 → #10.3 → #7

JSON Shape for Interchange (Operational)

{
  "version": "1.0",
  "domains": ["@Operator", "@Target"],
  "steps": [
    {"cluster": "#1", "domain": "@Operator"},
    {"boundary": {"channel": "svc/idp", "from": "@Operator", "to": "@Target"}},
    {"cluster": "#3", "domain": "@Target"},
    {"cluster": "#7", "domain": "@Target"}
  ]
}

Integration Notes

STIX 2.x: Encode crossings as SROs between domain‑scoped SCOs/SRO graphs; carry channel as a custom property.
MITRE ATT&CK: Keep cluster semantics clean; map techniques (e.g., T1195/T1199) to where they fit in the path; boundary operator provides the hop metadata without polluting cluster choice.
NIST CSF 2.0: Use the 10×5 (functions) matrix to attach controls per cluster; boundary crossings inform third‑party/TPRM control sets (SBOM, SLSA, artifact provenance, release attestations).

Advantages

Strategic clarity: Leadership instantly sees where supply‑chain risk emerges.
Operational precision: Encodes channel + domains for automation and IR.
Interoperability: Clean mappings to STIX/ATT&CK without semantic overlap.
Repeatability: Minimal grammar + JSON for consistent parsing.
Control mapping: Boundaries inform trust/provenance controls; steps map to cluster‑specific controls.

FAQs

Why two levels?

Inline #10 keeps strategy simple; the operator adds ops detail.

Backward‑compatible?

Yes. Existing paths remain valid; operational views can replace inline #10 with boundaries one‑for‑one.

When to use the operator?

For IR timelines, STIX packages, ATT&CK mappings, and when documenting delegated trust.

Call to Action

Adopt inline #10 strategically and the boundary operator operationally. Add the JSON to playbooks, encode boundaries in STIX, and train analysts with the boundary tests. Share feedback at TLCTC.net and contribute examples from 2025 incidents.

Separating trust crossings from effects keeps TLCTC’s semantics crisp while enabling automation. This refinement strengthens cross‑silo communication and supports high‑fidelity incident documentation in an era where supply chains amplify risk.

TLCTC Blog - 2025/09/22