Logo
TLCTC
Blog / Strategy & Architecture

Kill the Hype: Capability-Based Planning via the 10x(5x2) Matrix

Converting Risk Appetite into Engineered Defense.

BK
Bernhard Kreinz
• • Loading read time...
Executive Summary

"Capability-Based Planning" has become consulting theater—vague maturity models disconnected from actual threats. The TLCTC framework offers a rigorous alternative: the 10x(5x2) Matrix. This structure transforms capability planning from slide decks into engineered, measurable defense architecture.

Click to Enlarge
Infographic: CBP
With a wink: Deconstructing the "Capability Based Planning Cyber Security" and "Security Architecture".

The Problem: Capability Theater

Walk into any security program review and you'll hear it: "We have a vulnerability management capability." "We have an incident response capability."

Ask the follow-up question—"Which threat does this capability defend against?"—and watch the room go quiet.

Traditional capability definitions center on tools (firewall management) or processes (patch management). They describe how you are organized, not what you are defending against. This is why mature organizations still get breached. Their capabilities are organized around their org chart, not the adversary's playbook.

The Paradigm Shift: Redefining "Capability"

In the TLCTC framework, we strip away the consulting jargon. A Cyber Security Capability is defined as:

The organizational ability to execute specific Control Objectives (Identify, Protect, Detect, Respond, Recover) across both Local and Umbrella layers for a specific Threat Cluster.

A capability is not "Firewall Management." A capability is "Defense against #6 Flooding Attack."

The Architecture: The 10x(5x2) Matrix

To build a defensible program, we visualize the battlefield. The matrix creates 100 distinct control cells:

10 Clusters × 5 Functions × 2 Scopes = 100 Cells
Threat Cluster (The "What") Identify Protect Detect Respond Recover
Local Umb Local Umb Local Umb Local Umb Local Umb
#1 Abuse of Functions ◻◻ ◻◻ ◻◻ ◻◻ ◻◻
#2 Server Exploits ◻◻ ◻◻ ◻◻ ◻◻ ◻◻
... (Clusters #3-#9) ...
#10 Supply Chain ◻◻ ◻◻ ◻◻ ◻◻ ◻◻

The Dimensions

  • The Rows (The "What"): The 10 Top Level Cyber Threat Clusters (Axiom I).
  • The Columns (The "How"): The 5 NIST CSF Functions.
  • The Z-Axis (The "Where"):
    • Local Controls Applied directly to the asset (e.g., Endpoint Hardening).
    • Umbrella Controls Applied to the environment (e.g., Network Gateway).

Cluster-Derived Strategic Imperatives (The "Why")

Filling the 100 cells of the matrix isn't just a checkbox exercise; it requires a design philosophy. In the TLCTC framework, we don't adopt "Principles" because they are trendy; we adopt them because the Physics of the Threat Clusters demands them.

Defense in Depth

Derived From: Axiom VIII

Because attacks happen in sequences (e.g., #9 → #4 → #7), we need controls at multiple steps. If the #9 control fails, the #7 control must be there.

Zero Trust

Derived From: #4 Identity

Because credentials (#4) are system control elements that can be stolen, we cannot implicitly trust identity. We must verify every transaction.

Secure Supply Chain

Derived From: #10 Supply Chain

Because #10 is a Bridge Cluster that crosses trust boundaries, we must treat external code as untrusted until verified (SBOM, Signing).

Least Privilege

Derived From: #1 Abuse

Because every function is a potential attack vector, we must minimize the functional scope available to any user or process.

Operationalizing the Matrix: A Deep Dive Example

How do we apply this? Let's look at #10 Supply Chain Defense. This is critical because #10 is a Bridge Cluster—it crosses domain boundaries from @Vendor to @Org.

NIST Function Control Objective Local Control (Asset) Umbrella Control (Env)
Identify Identify trusted dependencies. SBOM generation during build. Vendor Risk Assessment (TPRM).
Protect Prevent trust abuse. Dependency pinning, Signature verification. CRITICAL Repository firewalls, Approved Vendor policies.
Detect Detect anomalous updates. Hash mismatch alerts in CI/CD. Threat Intel feeds on compromised vendors.
Respond Contain compromised supply chain. Rollback to last known good build. Block vendor IP ranges/domains.

Note: For Bridge Clusters, Umbrella controls are vital because they protect the boundary where the external trust enters your environment.

Measuring Success: The Velocity KPI

If your Capability for #6 Flooding Attack relies on manual log analysis (Human Speed), but the attack moves at Realtime Speed, the Capability is Ineffective regardless of budget.

The Detection Coverage Score (DCS)

DCS = (Mean Time to Detect) / (Attack Velocity Δt)

Goal: DCS < 1.0
(You must be faster than the adversary)

Conclusion

  1. Forget generic lists. Build your program around the 10 Clusters.
  2. Fill the Matrix. Ensure you have Identify, Protect, Detect, Respond, and Recover for every row.
  3. Check the Depth. Ensure you have Local and Umbrella coverage, especially for Bridge Clusters.
  4. Apply Principles. Use the Strategic Imperatives to guide your architecture.
  5. Measure Velocity. Ensure your Capability Velocity > Attack Velocity.

This approach transforms "Capability-Based Planning" from a vague slide deck into an engineered, auditable defense architecture.

References

  1. Kreinz, B. Top Level Cyber Threat Clusters (TLCTC), White Paper V1.9.1.
  2. NIST. Cybersecurity Framework (CSF).