Why “Cyber” in the Name does not win Cyber Wars

Date: 2025/09/28 | Frameworks: ISO/IEC 27000-series, TLCTC

Where ISO lacks and would profit from the TLCTC.

TL;DR

ISO/IEC 27000‑series is excellent at governing how to run an ISMS and how to manage risk. But it is deliberately agnostic about what cyber threats actually are and how they chain together. TLCTC fills that gap with a cause‑oriented, non‑overlapping taxonomy of ten Top Level Cyber Threat Clusters and a simple attack‑path notation that plugs straight into ISO risk and control workflows. Use ISO to run the program; use TLCTC to see—and break—the attack paths.

1) Acknowledge & Reframe (TLCTC Lens)

You’re asking where ISO “lacks.” Through the TLCTC lens, the problem is not ISO’s quality—it’s scope. ISO optimizes management; TLCTC optimizes threat clarity. Practically:

Strategic Management Layer (ISO + TLCTC): Define context, risks, objectives, governance.
Operational Security Layer (TLCTC): Identify the cause‑side cyber threats (#1–#10), map attack paths, tie specific TTPs and controls to the first exploited generic vulnerability.

Core TLCTC Axioms (short list):

Axiom II: Each attack vector is defined by the generic vulnerability it initially targets.
Axiom III: Threats are on the cause side (Bow‑Tie left); outcomes like “data breach” are on the right.
Axiom V: Threats ≠ Threat actors.
Axiom X: Credentials are system control elements; their compromise is a system compromise.

2) What ISO Does Great (Keep it!)

27001 gives a requirements skeleton for an ISMS and points to a control set.

27005 gives a repeatable risk process (context → assess → treat → monitor).

27000 provides vocabulary and positions the ISMS family.

These are indispensable. The gap is not governance—it’s the lack of a crisp, cyber‑specific threat taxonomy and attack‑path model to standardize risk identification and treatment priorities.

3) Where ISO Lacks (and how TLCTC fixes it)

3.1 No cyber‑specific threat taxonomy

ISO explains that you must identify “threats,” but does not provide a unified cyber‑threat classification or a sequence grammar. TLCTC provides 10 Top Level Cyber Threat Clusters (cause‑oriented, non‑overlapping):

Abuse of Functions – misuse of legitimate features/configurations (no code bug, no foreign code).
Exploiting Server – exploit server‑side implementation flaws.
Exploiting Client – exploit client‑side implementation flaws.
Identity Theft – acquire/misuse credentials, tokens, keys, sessions.
Man in the Middle (MitM) – abuse a privileged position on the path.
Flooding Attack – exhaust capacity to deny service.
Malware – execute foreign code (incl. scripts/LOLBAS as code execution).
Physical Attack – unauthorized physical access/interference.
Social Engineering – human manipulation as the vector.
Supply Chain Attack – compromise via trusted third‑party components/services.

Why it matters: Without a standard, teams invent local taxonomies, mix causes with effects, and miss steps in the chain. TLCTC gives a common, strategic language that’s precise enough for operations.

3.2 Ambiguity between causes, events and consequences

ISO is outcome‑oriented (CIA, incidents, consequences). TLCTC forces cause clarity via Bow‑Tie thinking: left side = threats (#1–#10); knot = system compromise; right side = data/business impacts.

3.3 No attack‑path notation

ISO doesn’t provide a concise way to write an attack. TLCTC mandates:

Sequence: #X → #Y → #Z
Parallel: (#A + #B)
Boundary (optional, advanced): ||[channel][@src→@dst]|| to mark trust/domain crossings precisely.

This compact grammar makes tabletop exercises, intel briefs, and risk registers consistent and automatable.

3.4 Credentials treated as “data,” not as control elements

ISO folds credentials into general information assets and IAM controls. TLCTC’s Axiom X elevates them to system control elements: if credentials are compromised, your system control is compromised. This reframes both risk and response (e.g., scope of incident, mandatory rotation, kill‑switch playbooks).

3.5 Supply‑chain transitions are not first‑class

ISO has supplier controls but no explicit trust‑boundary operator. TLCTC’s boundary notation makes crossings visible at the exact hop where risk changes, removing ambiguity in long chains.

4) Ransomware, Honestly (as an example)

Common path:

#9 Social Engineering → #7 Malware → #4 Identity Theft → (#1 Abuse of Functions + #7 Malware)

Why this is “cause‑first”:

#9 is the initial vector (phishing).
#7 is the first code execution (dropper/script/LOLBAS).
#4 follows as credentials get harvested/misused.
Parallel: the actor abuses admin tools (#1) while deploying encryptor (#7).

What ISO misses: It never asks you to write the path. Without a path, you treat controls piecemeal. With TLCTC, you can target controls where they break the chain earliest and cheapest.

5) ISO ⇆ TLCTC: A Practical Integration Pattern

5.1 In ISO 27005 risk identification, standardize on TLCTC

Mandate that every identified cyber risk references one primary TLCTC cluster (by cause). Add the attack‑path sequence for multi‑stage scenarios. Attach relevant sub‑threats/TTPs at the operational level.

5.2 In ISO 27001 risk treatment, select controls per TLCTC cluster

Create a 10×Controls view. Example (abridged):

TLCTC Cluster	Primary intent of controls
#1 Abuse of Functions	Authorization design, least privilege, safe defaults, function scoping, hardening baselines, change governance
#2 Exploiting Server	SSDL, code review, SCA/DAST/IAST, patching, RASP, memory safety
#3 Exploiting Client	Browser/app hardening, sandboxing, EDR, content disarm, update cadence
#4 Identity Theft	Strong auth (MFA), phishing‑resistant tokens, key mgmt, rapid revocation, just‑in‑time access
#5 MitM	TLS, cert pinning, secure DNS, segmentation, authenticated proxies
#6 Flooding Attack	Anycast/CDN, rate limiting, autoscale, back‑pressure, runbooks
#7 Malware	App allow‑listing, EDR, macro policy, script control, egress controls
#8 Physical	Locks, tamper‑evidence, secure boot, HSMs, EMP/side‑channel hygiene
#9 Social Eng.	Security culture, simulation, role‑based training, verified channels
#10 Supply Chain	SBOM, signed updates, vendor attestation, third‑party isolation, break‑glass

Use this as the selection lens when producing your Statement of Applicability and mapping to Annex‑A‑class controls.

5.3 In ISO performance evaluation, measure by cluster

Define KRIs/KCIs/KPIs per cluster (e.g., time‑to‑revoke credentials in #4; exploit‑to‑patch latency in #2/#3; TTP detection coverage in #7). Roll up to a Threat Radar for the board.

6) Worked Integrations

6.1 Phish‑to‑Encrypt (SMB enterprise)

Path: #9 → #7 → #4 → (#1 + #7)

ISO hooks:

27005: Record the path under risk identification; iterate until treatment breaks the earliest feasible link.
27001: SoA includes control families for #9/#7/#4; improvement loop tracks dwell time and revocation speed.

Win from TLCTC: The SoA and runbooks are path‑aware, not just control‑dense.

6.2 Supplier Build Compromise (SaaS)

Path: #10 Supply Chain → #7 Malware → #4 Identity Theft → #1 Abuse of Functions

Add boundary: ||[update@vendor→package@you]|| between #10 and #7.

ISO hooks: vendor management + change control.

Win from TLCTC: The trust crossing is explicit; detection gates sit before acceptance of third‑party artifacts.

7) “Cyber” in the Name ≠ Cyber Clarity

Saying “cybersecurity” in a title doesn’t define cyber threats. Programs fail when they:

treat effects (e.g., “data breach”) as threats,
blend IT risks and control failures into “threat lists,”
or omit attack‑path thinking entirely.

TLCTC fixes the semantics, so governance artifacts (risk registers, SoA, metrics) become operationally truthful.

8) Quick‑Start Checklist (drop‑in to your ISO program)

Adopt TLCTC as your enterprise cyber‑threat taxonomy (Strategic Layer).
Require attack‑path notation for every material cyber risk.
Map SoA controls by TLCTC cluster; label runbooks by cluster.
Treat credentials as control elements (Axiom X): pre‑approved mass‑rotation and kill‑switches.
Mark supply‑chain boundaries using the boundary operator; gate integrations accordingly.
Instrument KRIs per cluster and publish a quarterly Threat Radar to execs.

9) FAQ (for skeptics)

Q: Isn’t ISO 27005 enough?

A: It gives the process, not the taxonomy or path grammar. TLCTC supplies both without fighting ISO.

Q: Does TLCTC overlap ATT&CK/CWE?

A: No. ATT&CK/CWE live at the Operational Layer (techniques/weaknesses). TLCTC sits above, classifying initial cause vectors #1–#10. Map up, don’t mix.

Q: We already do “threat lists.”

A: Make them TLCTC‑clean: no outcomes, no actors, no control failures, no system types. One primary cluster per item, sequences for multi‑stage.

10) Conclusion

ISO runs the machine; TLCTC sharpens the sight. Pair them and you transform a compliant ISMS into a path‑aware defense program that stops attacks earlier, cheaper, and more reliably.

Appendices

Appendix A — TLCTC Attack‑Path Legend

Sequence: #X → #Y
Parallel: (#A + #B)
Boundary (advanced): ||[channel][@src→@dst]||

Appendix B — Minimal TLCTC Glossary (Strategic Level)

Threat Cluster: One of the ten cause‑oriented categories (#1–#10).
Primary Cluster: The first exploited generic vulnerability in a path.
Sub‑Threats (Operational): Concrete TTPs/techniques mapped under a cluster.
Identity as Control (Axiom X): Compromised credentials = compromised system control.

TLCTC Blog - 2025/09/28