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

Click to Enlarge

The Origin: From Military Doctrine to Cyber Defense

The term "Capability-Based Planning" (CBP) didn't originate in cybersecurity. It was forged in military defense strategy. In the late 1990s, defense establishments—the U.S. Department of Defense, NATO, the UK Ministry of Defence—faced a fundamental shift. The Cold War was over. The enemy was no longer a single, predictable adversary. Threats were becoming diverse, asymmetric, and fast-evolving.

The old model—"Threat-Based Planning" against a known opponent—was no longer sufficient. So military strategists developed a new approach: don't plan against a specific enemy; plan against the capabilities you need regardless of who the adversary is.

The core structure was deceptively simple:

1. Identify the threat. What is the generic class of danger?
2. Define the required capabilities. What must we be able to do to counter it?
3. Assess the gap. Where are we falling short?
4. Invest and build. Close the gap with doctrine, technology, training, and organization.

The Drone Analogy

Consider how this works in practice. A military identifies armed drones as an emerging threat class. They don't start by asking "Which country will attack us with drones?"—that's the old threat-based thinking. Instead, they ask:

"Drones are a threat. What capabilities do we need?"

The answer unfolds across multiple dimensions:

• Govern: Doctrine and rules of engagement for counter-drone operations. Risk appetite—what level of drone incursion is tolerable?
• Identify: Radar systems and intelligence to detect and classify drone activity in the battlespace.
• Protect: Jamming systems, geofencing, physical hardening of critical assets.
• Detect: Real-time sensor networks, acoustic detection, RF scanning.
• Respond: Kinetic and electronic countermeasures, trained operators, rapid-reaction units.
• Recover: Battle damage assessment, asset restoration, lessons learned.

Notice the pattern: one threat, decomposed across governance, identification, protection, detection, response, and recovery. Each dimension requires different technologies, different people, and different processes. That is Capability-Based Planning.

So Do We.

Now translate this to cyber security. Take Cluster #1: Abuse of Functions. Specifically, consider the abuse of AI systems—an adversary weaponizing your own AI-enabled features against you: prompt injection, model manipulation, automated reconnaissance using your own tools.

"Abuse of Functions of AI Systems is a threat. What capabilities do we need?"

The question is identical. The structure is identical. Only the domain has changed:

• Govern: AI usage policy, risk appetite for AI-enabled features, accountability model for AI outputs.
• Identify: Inventory of AI-enabled functions, assessment of misuse potential, threat modeling of AI attack surfaces.
• Protect: Least privilege on AI capabilities, input validation, rate limiting, output filtering, sandboxing.
• Detect: Anomaly detection on AI behavior, monitoring for prompt injection patterns, output drift alerts.
• Respond: Kill switches for AI features, rollback to safe states, isolation of compromised AI components.
• Recover: Model retraining, revalidation of AI outputs, restoration of trust in AI-driven processes.

This is the same military discipline applied to a different battlefield. The military asks "What capabilities do we need against drones?" We ask "What capabilities do we need against Abuse of Functions?" Then against Exploiting Servers. Then against Identity Theft. Then against Supply Chain Attacks. Ten threats. Ten rows. Same question, ten times.

The Problem: Capability Theater

With this military origin in mind, the dysfunction in cyber security becomes painfully clear. 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.

Imagine a military general saying "We have a logistics capability" without specifying whether it counters naval threats, aerial threats, or cyber threats. That general would be relieved of command. Yet in cyber security, this is the norm. Capabilities are organized around 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 (Govern, 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(6x2) Matrix

To build a defensible program, we visualize the battlefield. With NIST CSF 2.0's addition of the Govern function, the matrix creates 120 distinct control cells:

The Dimensions

• The Rows (The "What"): The 10 Top Level Cyber Threat Clusters (Axiom I).
• The Columns (The "How"): The 6 NIST CSF 2.0 Functions (GV / ID / PR / DE / RS / RC).
  • Govern (GV) Cross-cutting: ownership, risk appetite, taxonomy adoption, metrics governance.
• 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 120 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.

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.

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

Measuring Success: Velocity Classes & the DCS

TLCTC V2.0 introduces four Velocity Classes (VC-1 through VC-4) that determine which defensive modes are structurally viable for each attack edge. If your Capability for #6 Flooding Attack relies on manual log analysis (VC-2: Tactical), but the attack moves at VC-4: Real-Time speed, the Capability is structurally ineffective regardless of budget.

Key rule (Normative): If a critical transition is VC-3 or faster, purely human response is structurally insufficient. Controls must be automated or architectural.

Try It Yourself: The CBP Matrix App

Theory is nothing without practice. We've built an interactive tool that lets you fill your own 10x(6x2) Matrix—defining capabilities, workforce, and governance controls for each cell, across multiple environments.

Conclusion

1. Forget generic lists. Build your program around the 10 Clusters.
2. Fill the Matrix. Ensure you have Govern, Identify, Protect, Detect, Respond, and Recover for every row.
3. Check the Depth. Ensure you have Local and Umbrella coverage, especially for Bridge Clusters (#8, #9, #10).
4. Apply Principles. Use the Strategic Imperatives to guide your architecture.
5. Measure Velocity. Map each attack edge to a Velocity Class (VC-1 through VC-4) and ensure DCS < 1.0 at every critical transition.

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