Why Two Layers? Because Reality Has Two Layers
Most cybersecurity frameworks treat their structure as an organizational convenience—a way to sort threats into tidy categories for reporting purposes. TLCTC takes a fundamentally different approach: its two-layer architecture reflects how cyber risk actually works in the real world.
This distinction matters more than it might first appear. What's natural—grounded in the actual structure of reality—differs fundamentally from what's typical in most cyber standards today. And building your security program on an unnatural foundation creates problems that no amount of tooling or process can fix.
"The best frameworks don't just organize information—they reveal the structure that was always there."
The Natural Structure of Cyber Risk
Every cyber attack follows the same fundamental pattern: an attacker exploits a vulnerability to cause an event, which leads to consequences. This is the Bow-Tie model, and it's not a framework we invented—it's a description of how causality works in risk scenarios.
Within this structure, two distinct layers emerge naturally:
Layer 1: Stable Patterns
Certain aspects of cyber risk don't change regardless of which system you're protecting, which tools you're using, or which year it is:
- Software can have implementation flaws
- Identities can be impersonated
- Communication paths can be intercepted
- Capacity can be exhausted
- Humans can be manipulated
- Third parties can be compromised
These are the 10 generic vulnerabilities—they're universal and timeless.
Layer 2: Volatile Specifics
Other aspects change constantly—sometimes daily or hourly:
- Which CVEs affect your systems
- Which TTPs attackers are using this week
- Which detection rules need updating
- Which patches are pending
- Which IOCs are relevant
- Which tools are deployed where
These are the operational details—they're specific and constantly changing.
This isn't a choice TLCTC made—it's a structure that exists in reality. The 10 generic vulnerabilities haven't changed since the first networked computer; the specific CVEs exploiting them change weekly. A framework that collapses these layers together is fighting reality.
What's Typical vs. What's Natural
Most cybersecurity standards and frameworks make a fundamental error: they organize threats by outcome rather than by cause. This feels intuitive—"ransomware" and "data breach" are what people worry about—but it destroys the analytical foundation needed for consistent security.
❌ What's Typical (but wrong)
- Outcome-based categories: "Ransomware," "Data Breach," "DDoS" used as threat types
- Cause-consequence conflation: Mixing what attackers do with what results
- Flat taxonomies: No distinction between stable patterns and specific instances
- Actor-centric thinking: Organizing by "who" instead of "how"
- Control-failure-as-threat: Treating missing controls as threat categories
Results in: incomparable incident data, broken control mapping, and the same "breach" classified differently every time.
✓ What's Natural (how it works)
- Cause-side classification: Threats defined by the generic vulnerability exploited
- Layered abstraction: CVE → Generic Vulnerability → Cluster (specific to universal)
- Stable + Volatile separation: Strategic patterns that don't change vs. operational details that do
- Action-centric structure: What attackers do, not who they are
- Clean Bow-Tie positioning: Threats on the left, outcomes on the right, never mixed
Results in: comparable analysis, clear control mapping, and consistent classification across teams and time.
The Ransomware Test
Consider a simple question: "What is a ransomware attack?"
Under outcome-based thinking, ransomware is a category unto itself. You track "ransomware incidents," build "anti-ransomware controls," and report "ransomware risk" to the board.
Under TLCTC's cause-based approach, "ransomware" is a label for an outcome—the encryption and extortion that results from a successful attack. The actual threat is a sequence of causes:
#9 → #3 → #7 → #4 → (#1 + #7)
- #9 Social Engineering: Phishing email tricks user into opening attachment
- #3 Exploiting Client: Malicious macro exploits Office vulnerability
- #7 Malware: Dropper executes, establishes persistence
- #4 Identity Theft: Credential harvesting enables lateral movement
- #1 + #7: Abuse legitimate functions + execute ransomware payload
This isn't pedantry—it's the difference between learning from incidents and endlessly relitigating what happened. Two organizations hit by "ransomware" might have completely different attack paths, requiring completely different controls. Outcome labels hide this; cause-side analysis reveals it.
TLCTC Axiom III states: "Threats Are Causes, Not Outcomes." This isn't a preference—it's a logical constraint. If you classify by outcomes, you can't compare incidents, can't map controls consistently, and can't learn systematically. The same outcome ("data breach") can result from #2 (SQL injection), #4 (credential theft), #5 (MitM), or #9→#4 (phishing to credential use). These require different controls—but outcome-based thinking hides this.
The Communication Gap
The two-layer structure isn't just philosophically correct—it solves a practical problem that plagues every security organization: the disconnect between strategy and operations.
Ask a CISO what keeps them up at night, and you'll hear about board presentations, risk appetite, and resource allocation. Ask a SOC analyst what keeps them up at night, and you'll hear about detection rules, false positives, and attack techniques.
They're talking about the same threats, but in completely different languages.
- Board Meeting: "We need to address our supply chain risk exposure"
- SOC Meeting: "We detected suspicious npm package behavior and need to update our YARA rules"
Same threat (#10 Supply Chain Attack), different universes.
This disconnect creates critical problems:
- Strategic decisions lack operational grounding – Risk appetites are set without understanding what controls actually exist.
- Operational activities lack strategic context – SOC teams detect threats without knowing which ones the board cares most about.
- Communication breaks down – Technical teams can't explain risks in business terms; leadership can't translate priorities into technical requirements.
- Resources are misallocated – Investment decisions don't align with actual threat landscape or control effectiveness.
The Solution: A Two-Layer Framework
The TLCTC framework addresses this disconnect by embracing the natural two-layer structure of cyber risk: a Strategic Layer for decision-making and governance, and an Operational Layer for implementation and execution—connected by a clear, consistent bridge.
Strategic Layer reflects the stable, universal patterns—the 10 generic vulnerabilities that don't change whether you're defending a hospital, a bank, or a power grid. Operational Layer reflects the specific, constantly changing manifestations—today's CVEs, this quarter's TTPs, the actual tools in your SOC. Both exist in reality; TLCTC keeps them appropriately separated rather than collapsing them into an undifferentiated muddle.
Scope of Each Layer
Strategic Management Layer
- Works with TLCTC clusters #1–#10 and their generic vulnerabilities
- Defines risk appetite and tolerance per cluster
- Defines control objectives per cluster × NIST CSF function
- Owns KRIs and high-level KCIs at cluster / objective level
- Maintains governance artefacts (policies, standards, accountability)
- Deliberately avoids TTPs, CVEs, tool configurations
Operational Security Layer
- Implements TLCTC sub-threats (TLCTC-XX.YY) in tooling and processes
- Works with concrete vulnerabilities (CVE/CWE) and MITRE TTPs
- Models and detects attack paths across domains
- Implements and operates local and umbrella controls
- Owns KCIs and KPIs for control effectiveness and operational performance
- Feeds metrics back to the strategic layer to inform KRIs
The Strategic Layer: Where Decisions Are Made
Purpose and Scope
The Strategic Layer is where organizations define what they care about and how much risk they're willing to accept. It works exclusively with stable concepts that don't change with each new CVE or TTP:
- The 10 threat clusters and their generic vulnerabilities
- Risk appetite and tolerance statements per cluster
- Control objectives (what controls should achieve, not how)
- Key Risk Indicators aggregated from operational metrics
Who Works Here?
- Board members and executives
- Chief Information Security Officers
- Risk managers and compliance officers
- Security leadership responsible for program direction
Strategic Artifacts
| Artifact | Purpose | Update Frequency |
|---|---|---|
| Risk Register (TLCTC-based) | Track threats by cluster, using stable categories | Quarterly |
| Risk Appetite Statement | Define acceptable exposure per cluster | Annually |
| Control Objectives Matrix | Map NIST CSF functions to clusters | Annually |
| KRI Dashboard | Monitor emerging risks at cluster level | Monthly |
The Operational Layer: Where Defense Happens
Purpose and Scope
The Operational Layer is where organizations implement defenses using the volatile, specific details that change constantly:
- Specific vulnerabilities (CVE/CWE) affecting actual systems
- Tactics, Techniques, and Procedures (MITRE ATT&CK)
- Detection rules, SIEM configurations, tool settings
- Incident response playbooks with specific procedures
- Key Control Indicators (KCIs) and Key Performance Indicators (KPIs)
Who Works Here?
- SOC analysts and threat hunters
- Security engineers and architects
- Vulnerability management teams
- Incident responders
Operational Layer in Practice
SOC Analyst: "SIEM alert: Suspicious PowerShell execution detected on endpoint DESKTOP-7821. Correlating with TLCTC framework..."
Analysis:
- Initial phishing email (
TLCTC-09.00Social Engineering) - Malicious macro in attachment (
TLCTC-03.00Exploiting Client) - PowerShell dropper execution (
TLCTC-07.00Malware) - Attack path:
#9→#3→#7
SOC Manager: "This maps to our #7 Malware response playbook. Execute containment procedures."
Dual Notation System
The framework uses two complementary notation systems:
| Layer | Notation | Format | Use Case |
|---|---|---|---|
| Strategic | Human-readable | #X |
Executive communication, board reports |
| Operational | Machine-readable | TLCTC-XX.YY |
SIEM rules, automation, databases |
The Bridge: NIST CSF as Universal Grammar
The two layers must communicate. TLCTC uses NIST CSF's six functions (GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER) as the bridge—a universal grammar that applies to every node in a risk event chain.
NIST CSF's functions aren't just a checklist—they're a complete description of what any control can do at any point in a risk scenario. Strategic control objectives map to functions; operational controls implement those functions. The mapping is the bridge.
Example: Full Bridge in Action
Strategic Layer Activities:
- Board sets risk appetite for #10 Supply Chain Attack to "Low"
- CISO defines control objective: "IDENTIFY and PROTECT against compromised third-party components"
- KRI established: "Number of unvetted dependencies in production code"
Bridge Translation:
- Control objective requires: Software Composition Analysis (SCA)
- Implementation requirements: Automated scanning, SBOM generation
- Success criteria: 100% dependency visibility, <7 day remediation for critical findings
Operational Layer Implementation:
- Deploy Snyk/Dependabot for SCA scanning
- Integrate SCA into CI/CD pipeline (map to
TLCTC-10.02) - Establish KCI: "% of builds with SCA scan passed"
- Establish KPI: "Mean time to remediate critical dependency vulnerabilities"
Feedback Loop:
- Weekly: Security engineer reviews KCI (95% builds scanned)
- Monthly: Ops manager reviews KPI (4.2 day MTTR)
- Quarterly: CISO reports KRI to board (Unvetted dependencies: 12, down from 47)
Key Benefits Summary
Strategic Layer Benefits
- Clear communication with board and executives
- Risk-based resource allocation
- Consistent risk assessment methodology
- Meaningful risk appetite statements
- Comparable incident documentation
Operational Layer Benefits
- Precise threat classification
- Consistent incident response
- Effective threat hunting
- Clear control implementation guidance
- Automated tool integration
When strategy and operations speak the same language—when they both reference the same underlying reality rather than incompatible abstractions—your entire security program becomes coherent. Executives understand what they're approving. Security teams understand priorities. Investments align with actual risk.
Conclusion: Align with Reality
The cybersecurity industry has struggled for too long with the disconnect between strategic intent and operational reality. Boards make decisions without understanding implementation; SOC teams detect threats without knowing strategic priorities. Frameworks proliferate without revealing the structure that was always there.
TLCTC's two-layer framework doesn't impose an artificial structure on cyber risk—it reveals the natural structure that already exists. Stable patterns belong in the Strategic Layer. Volatile specifics belong in the Operational Layer. NIST CSF bridges them with a universal grammar.
This isn't organizational convenience. It's alignment with how reality works. And when your framework aligns with reality, everything else becomes easier: communication, control mapping, incident learning, resource allocation.
"The best defense isn't just strong controls or good threat intelligence—it's an organization where everyone from the board to the SOC speaks the same language and works toward the same goal. The two-layer framework gives you that common language. The rest is up to you."
References
- Kreinz, B. Top Level Cyber Threat Clusters (TLCTC) — Version 2.0 White Paper, 2025.
- NIST Cybersecurity Framework 2.0, National Institute of Standards and Technology, 2024.