Top Level Cyber Threat Clusters
White Paper Super Compact Version 1.9.1
November 2025, Bernhard Kreinz
Bridging the Gap: A Unified Approach to identify and categorize Threats in Cyber Risk Management. A Pragmatic Solution for Targeted Cyber Threat Identification and Cyber Risk Management connecting the Operational Level with the Strategic Level.
The cybersecurity landscape is fragmented. Organizations struggle with inconsistent terminology and siloed approaches to threat identification and risk management, hindering effective defense strategies. Current frameworks often conflate vulnerabilities, attack techniques, and outcomes, leading to confusion and gaps in threat modeling. This white paper introduces the Top Level Cyber Threat Clusters (TLCTC) framework, a novel solution designed to bridge this critical gap and unify strategic planning with operational security. Unlike existing approaches, the TLCTC framework provides a universal, consistent taxonomy of ten distinct threat clusters, each rooted in a fundamental underlying vulnerability rather than observed events or attacker behaviors. This clear, cause-oriented categorization facilitates targeted threat identification, precise mapping of threats to controls, and seamless integration with existing frameworks like NIST CSF, MITRE ATT&CK & CWE, and STIX.
The TLCTC framework employs a unique two-tiered approach, distinguishing between strategic management and operational security. At the strategic level, it empowers leadership to define risk appetite, allocate resources effectively, and communicate cyber risk clearly. Operationally, it enables security teams to implement targeted threat intelligence, enhance incident response, and streamline security operations. This unified approach ensures consistent cybersecurity strategy understanding and execution across all levels of the organization.
This white paper details the derivation of the ten threat clusters through a logical thought experiment, provides clear definitions and real-world examples, and outlines methods for integrating the framework into existing security practices, including secure coding guidelines and the software development lifecycle. Furthermore, it introduces the concept of Cyber Threat Radars, a visualization tool based on the TLCTC framework, for improved threat analysis, communication, and collaboration across organizations and national borders. By adopting the TLCTC framework, organizations can transition from reactive, fragmented cybersecurity practices to a proactive, unified approach, strengthening their overall security posture and enabling more informed decision-making in the face of evolving cyber threats, leading to more resilient and adaptable cybersecurity postures. I encourage the cybersecurity community to engage with this framework, validate its applicability, and provide feedback to further refine and enhance its effectiveness.
Why Start With Assumptions and Axioms? 11
#5 Man in the Middle (MitM) 20
Data Processing Pathways and Threat Cluster Mapping 28
Bridging Strategy and Operations: A Comprehensive TwoTiered Approach 33
Cyber Risk Events and Incidents 34
Cyber Bow-Tie and Risk-Management 37
Clarification on Central Event Position 38
Sequences in Cyber Threat Clusters 45
Sequences in Attacks: An Example View 46
Vertical Stack Application: A Layered Security Approach 49
Standardizing Strategic Cybersecurity 56
Refinement of the Top Level Clusters 56
Standardizing Operational Cybersecurity 62
Buzz-Word Refinement of the Top Level Clusters 63
Standardized Attack Path Notation 65
The Need for Multi-Layer Notation Convention 66
Real-World Application of Dual-Layer Notation 66
Attack Path Notation: Domain Boundaries and Supply-Chain Transitions 68
Example: MFA Bombing and MFA Fatigue in TLCTC Attack Path Notation 72
IT Systems, Assets, and the TLCTC Framework 74
The Challenge: Moving Beyond IT System Types 74
Strategic vs. Operational Views 75
A. Leveraging NIST CSF functions 77
Cyber Threat Cluster Control Framework 77
Hierarchical Framework for Key Indicators 81
C. Introducing Cyber Threat Radars 91
Enter the Cyber Threat Radar 91
Understanding Cyber Threat Radar Visualizations 93
D. Threat Intelligence - Analysis of MITRE & STIX 98
Enhancing STIX with the Top Level Cyber Threat Clusters 99
E. Threat Intelligence - Real World Examples 107
NSO Group Pegasus spyware Attack Paths 107
Cobalt Strike as a Multi-Threat Tool 111
F. Oversimplification? An operational View 116
Demystifying the Cyber Threat Landscape: A Pragmatic Approach to Threat Identification and Risk Management
Cybersecurity professionals face a critical challenge in effectively identifying and categorizing threats due to the inconsistent and often ambiguous guidance provided by leading standards and frameworks (NIST CSF, ISO 27000, CIS, ENISA, BSI, MITRE, others and all CERT reports I have analyzed). The lack of clear distinctions between threats, threat actors (or their motivation), vulnerabilities, control failures, IT system types, and risk events has led to a semantic blur that hinders the development of effective risk management strategies.
Driven by the need for a more coherent and actionable approach, I embarked on a thought experiment to distill the essence of what constitutes a 'threat' in the cybersecurity domain. The objective was to create a refined conceptual framework that clearly segregates threats from commonly confused elements, providing a universal approach to cybersecurity that can be applied across diverse IT systems and contexts.
The resulting framework, the "Top Level Cyber Threat Clusters (TLCTC)" provides a pragmatic and structured solution for targeted threat identification. It seamlessly integrates enterprise risk management (ERM) with security operations center (SOC) and threat intelligence processes. By defining distinct, non-overlapping categories, this framework eliminates ambiguity and ensures precise mapping of threats to controls. These clusters are universally applicable both horizontally across various domains (e.g., enterprise IT, cloud environments, IoT) and vertically through the IT stack (e.g., application layer, operating system, hardware). This approach bridges the gap between strategic risk management and operational security, empowering organizations to develop targeted threat intelligence, implement effective risk mitigation strategies, and address the complexity of the cyber threat landscape with clarity and confidence.
It is crucial to understand that cyber risks are a subset of the broader category of operational risks (OpRisk). While cyber risk management focuses primarily on threats from unauthorized or unknown entities, a comprehensive risk management strategy must consider the full spectrum of operational risks. This includes traditional IT risks (with threats such as e.g. ”software failure”, "error in use" and "abuse of rights"), compliance risks, and third-party risks (including their associated cyber risks). Organizations should integrate cyber risk management within a holistic OpRisk framework to gain a consolidated view of their risk landscape. This approach allows for better resource allocation, more effective risk mitigation strategies, and a clearer understanding of how cyber risks interact with other operational risks. It's important to note that while actions of authorized actors (such as employees or customers) should be managed under separate risk categories, any attempts by these individuals to breach that boundary would fall within the scope of cyber risks. This nuanced approach ensures that all potential cyber threats are addressed, regardless of their origin, while maintaining the broader context of operational risk management.
The 10 Top Level Cyber Threat Clusters framework serves as a Rosetta Stone in the fragmented cybersecurity landscape, providing a universal translation layer between strategic risk management and operational security through three core stakeholder objectives:
The framework consists of three primary layers:
For Strategic Leadership & Risk Management:
For Security Operations & Technical Teams:
For Global Cybersecurity Community:
This streamlined framework bridges the gap between strategic cyber risk management and operational security practices, uniting the fragmented landscape of cybersecurity approaches under a common understanding supported by major organizations and frameworks like NIST CSF, CVE, MITRE and ETSI and STIX.
Before diving into the cyber threat clusters, we must establish our foundational principles. In any logical framework, axioms serve as basic truths that we accept without proof, while assumptions define the scope and context of our thinking. Like mathematical proofs that build upon basic axioms, our cyber threat framework requires clear starting points to ensure consistent and logical development.
The following assumptions and axioms form the essential foundation of the 10 Top Level Cyber Threat Clusters concept. You must agree with these basic principles to validate and effectively use this framework. If any of these foundational elements don't align with your understanding, the subsequent threat categorization may not serve its intended purpose.
Compliance Note: While regulatory frameworks may classify credentials as personal data, operationally within TLCTC they function as system control elements. Both the data risk (confidentiality breach upon exposure) and system risk (loss of control upon use) must be evaluated.
Without these clear starting points, we risk mixing threats with vulnerabilities, confusing causes with effects, and creating overlapping or inconsistent categories that don't serve practical security needs.
Compliance note on credentials: Operationally, credentials and identity artifacts are elements of access control and therefore drive #4 Identity Theft when used. Regulatory frameworks may additionally treat certain credentials as personal data. This framework’s mapping (operational cause/effect) is orthogonal to legal classification: both views can be applied simultaneously without conflict.
Imagine the complex world of information technology as a single object. This object, although robust and seemingly closed, has various attack surfaces – the generic vulnerabilities.
**1.** We are at asset software. First, we concentrate on the essentials and take care of the functional domain and scope and realize that every function can be abused and that more scope also means more attack surface. Here our first threat cluster arises: **Abuse of Functions**
**2.** Every software, although optimized, may contain code flaws that can be exploited, especially if it is directly exposed (Server side). This leads us to the threat cluster: **Exploiting Server**
**3.** Even on the client side, there is a risk that existing software code flaws can be exploited. This type of attack, where the client accesses a malicious resource, manifests itself in the threat cluster: **Exploiting Client**
**4.** Our software interacts with identities and credentials, both human and technical. When these identities are compromised, they can be abused. This leads to the threat cluster: **Identity Theft**
**5.** Communication is crucial in our connected world. Yet, as data is transmitted between points A and B, rogue parties might eavesdrop or inject themselves. This reveals the threat cluster: **Man in the Middle**
**6.** This continuous connectivity also makes us susceptible to attacks that want to flood our infrastructure or software (application) and put it out of action. This leads us to the threat cluster: **Flooding Attack**
**7.** In the digital landscape, there is a continuous exchange of files and data. Some of these files could contain malware code and thus pose a threat. Here the threat cluster arises: **Malware**
**8.** We must not forget that there are physical points of access and interaction through which intruders might come. Therefore, we have the threat cluster: **Physical Attack**
**9.** And we should not forget about the human factor. We are susceptible to deception, manipulation, and misconduct. This human element leads us to the threat cluster: **Social Engineering**
**10.** Our software or hardware ecosystems are almost always linked with third-party software or hardware. Do we have control over these? This leads to the last threat cluster: **Supply Chain Attack**
Through this thought experiment and careful examination of vulnerabilities in the IT landscape, I have derived these 10 distinct top level threat clusters. It offers us a clear structure and a deeper understanding of the diverse threats that our IT systems, people, and processes face.
The control examples are merely exemplary and intended to facilitate quick understanding. Systematic control selection is discussed in the chapter "Cyber Threat Cluster Control Framework."
Definition: An attacker abuses the logic or scope of existing, legitimate software functions, features, or configurations for malicious purposes. This manipulation occurs through standard interfaces using expected input types (data, parameters, configurations, sequence of actions), but in a way that subverts the intended purpose or security controls. Here, inputs remain data: no foreign code is introduced or executed; the attacker misuses correctly implemented functionality via legitimate parameters and calls. This also includes living-off-the-land: using only software functions and binaries already present on the (even compromised) system—invoked with legitimate inputs/parameters—without introducing any foreign code.
Generic Vulnerability: The scope, complexity, or inherent trust placed in legitimate software functions, features, and configurations. More scope/complexity can create a larger attack surface.
Context: This threat addresses the manipulation of the functional domain itself – what the software is designed to do. The attacker misuses capabilities intentionally built into the system, often exceeding implicit boundaries or leveraging overly permissive designs via standard interfaces using expected input types (data, parameters, configurations, sequence of actions). Crucially, this does not involve executing foreign Malware Code (unlike #7), nor does it rely on foreign code that is exploiting specific implementation flaws/bugs (unlike #2/#3 Exploiting Server/Client). When initiated via Social Engineering (#9), this often involves tricking a user into enabling, disabling, or misconfiguration of legitimate, existing features (e.g., enabling RDP access, creating firewall exceptions, changing security settings), rather than installing new software (which would facilitate #7).
Boundary check (keep with #1 unless…):
Critical distinction for #1:
#1 does NOT create data→code transitions. Data→code transitions occur via:
Sub-Threats Examples: Data Poisoning, Abuse of document sharing functions, BGP Hijacking, Misuse of API functionalities, Parameter Tampering (exploiting logic), Enabling insecure configurations, LOLBAS invocation (note: when LOLBAS executes foreign code/scripts, map as #1 → #7 sequence)
Control Examples: Input validation (for logic), Strong configuration management, Least privilege for functions/APIs, Feature usage monitoring, Business logic checks, Multi-step approvals for sensitive configurations
Attacker's View: "I abuse a functionality, not a coding issue."
Developer's View: "I must understand and constrain the functional domain of my code. Every feature I implement must have clearly defined boundaries and expected usage patterns. I need to ask: What is the legitimate scope of this functionality, and how could it be misused?"
Asset Type: Software (Its logic and functions and configuration)
Definition: An attacker targets and leverages flaws originating directly within the server-side application's source code implementation. These vulnerabilities (e.g., improper input handling, insecure API usage, resource leaks, logic errors introduced during coding) allow manipulation of server behavior or unauthorized access using Exploit Code, which is foreign code. This forces a data→code transition: exploit code executes as new, foreign code in the server context by triggering a server-side implementation flaw.
Generic Vulnerability: The presence of exploitable flaws within the server-side source code implementation and its resulting logic, stemming from insecure coding practices.
Context: This cluster isolates vulnerabilities that are fundamentally mistakes made by developers during coding on the server side. It addresses the direct consequences of insecure software development practices related to how code handles data, manages resources, or implements application logic. An attacker uses Exploit Code to trigger these specific code-level bugs. This focus on source code implementation flaws distinguishes it from:
Sub-Threats Examples: SQL Injection (coding flaw in query building), Buffer Overflows (coding flaw in memory handling), RCE via Deserialization (coding flaw in data processing), SSRF (coding flaw in URL processing), XXE Injection (coding flaw in XML parsing), Stored/Reflected XSS (coding flaw in handling output)
Control Examples: Secure Coding Training & Standards, Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Manual Code Review, Input Validation/Sanitization Libraries, Output Encoding, Content Security Policy (CSP), Secure Component Usage, Patching, WAF
Attacker's View: "I abuse a flaw in the application's source code on the server side."
Developer's View: "I must apply language-specific secure coding principles for all server-side code, understanding the security pitfalls of my chosen language (e.g., SQL injection in PHP, deserialization in Java, buffer overflows in C++) and implementing appropriate safeguards."
Asset Type: Software (Specifically, the server-side application source code implementation)
Definition: An attacker targets and leverages flaws originating directly within the source code implementation of any software acting in a client role (requesting/processing data from a server or resource). These vulnerabilities (e.g., improper handling of responses or local data, insecure interaction with local resources, logic errors introduced during coding) allow manipulation of client behavior, unauthorized access to client resources, or information disclosure using Exploit Code, often when the client interacts with malicious content, servers, or manipulated local state. Like in #2 this also creates a data→code transition: exploit code executes as new, foreign code in the client by abusing a client-side implementation flaw.
Generic Vulnerability: The presence of exploitable flaws within the source code implementation of software acting as a client, stemming from insecure coding practices related to processing external data/responses, rendering UI, or managing client-side state and resources.
Context: This cluster isolates vulnerabilities that are fundamentally mistakes made by developers during coding within any software component performing a client function – receiving and processing data/responses. Examples include web browsers, mobile apps, desktop applications, document readers, command-line clients (SSH, SQL), client libraries (e.g., HTTP, database connectors), API consumers, and background services acting as clients. It addresses insecure development practices in how this client code handles data, interacts with APIs, or renders information. An attacker uses Exploit Code to trigger these code-level bugs. This focus on client-role source code implementation flaws distinguishes it from:
Sub-Threats Examples: DOM-Based XSS (client script coding flaw), Client Library Buffer Overflows (e.g., in libcurl handling responses), Insecure Deserialization in Client/API Consumer, Command-line Client argument/response handling flaws, Exploits targeting browser/plugin rendering engines.
Control Examples: Secure Coding Training & Standards (Client-Side Focus), SAST/DAST for client code/libraries, Framework/Library Protections, Secure handling of data from all external sources (servers, files, URLs, APIs), Avoiding dangerous functions, Keeping all client software/libraries patched.
Attacker's View: "I abuse a flaw in the source code of software acting as a client." (Often triggered by crafted input/data/response)
Developer's View: "I must apply language-specific secure coding principles for all client-side code, understanding how my language handles external data (e.g., DOM-based XSS in JavaScript, buffer overflows in native clients) and never trusting incoming data."
Asset Type: Software (Specifically, the source code implementation of software acting in a client role)
Definition: An attacker targets weaknesses in identity and access management processes or credential protection mechanisms to illegitimately misuse authentication credentials (e.g., passwords, tokens, keys, session identifiers, biometrics) to impersonate a legitimate identity (human or technical).
Generic Vulnerability: Weak Identity Management Processes and/or inadequate credential protection mechanisms throughout the identity lifecycle (issuance, storage, transmission, validation, revocation), allowing credentials to be illegitimately misused.
Context: This cluster focuses specifically on the compromise of the authentication process itself through unauthorized use of credentials. This focus on credential compromise distinguishes it from:
Note: Credentials, tokens, keys, session identifiers, and any access-enabling identity representations are system control elements with a dual operational nature:
Non-Overlap Rule: Credential acquisition maps to the enabling threat cluster (#1/#2/#3/#5/#7/#8/#9/#10); credential use always maps to #4..
Sub-Threats Examples: Password Spraying, Session Hijacking, Pass-the-Hash/Ticket attacks, Use of Stolen API Keys/Secrets
Control Examples: Multi-Factor Authentication (MFA), Strong password policies, Credential rotation, Secure credential storage, Session management, Anti-phishing training (#9) & technical controls (URL filtering, browser warnings against known harvesting sites enabling #4), Monitoring for credential abuse
Attacker's View: "I abuse credentials to operate as a legitimate identity."
Developer's View: "I must implement secure credential lifecycle management: proper storage (hashing with salt), secure transmission, session handling (timeout, invalidation), and robust authentication mechanisms (MFA support). Every identity-related function needs defense-in-depth."
Asset Type: Software (Identity/Access Management Systems), Credentials
Definition: An attacker intercepts, eavesdrops on, modifies, or relays communication between two parties without their knowledge or consent, by exploiting a privileged position on the communication path. This position might be gained locally (e.g., on shared Wi-Fi) or by leveraging control over existing network intermediaries.
Generic Vulnerability: The lack of sufficient control, integrity protection, or confidentiality over the communication channel/path, including the implicit trust placed in local networks (like public Wi-Fi) and intermediate network infrastructure in standard IP networking.
Context: This cluster describes attacks enabled by an attacker controlling a point on the communication path. Common examples familiar to end-users include attackers on the same public Wi-Fi network intercepting traffic, or potentially a compromised VPN service acting maliciously. More broadly, in standard Internet (IP) communication, intermediaries (routers, ISPs) always exist, creating potential MitM points if compromised (e.g., via BGP hijacking - #1). #5 focuses on the actions possible from this intermediary position (local or remote): eavesdropping, modification, injection, replay, protocol downgrades. This cluster is distinct from the methods used to initially gain the position (which fall under #1, #8, etc.). Network architectures like SCION aim to mitigate vulnerabilities in intermediate path infrastructure.
Sub-Threats Examples: Public Wi-Fi Eavesdropping/Injection, SSL/TLS Interception (via rogue AP or compromised intermediary), DNS Spoofing from local network attacker, Malicious VPN Traffic Manipulation, Modifying data via compromised router
Control Examples: End-to-End Encryption (E2EE), Using trusted VPNs, Transport Layer Security (TLS) with strong validation (HSTS, Cert Pinning), Avoiding untrusted public Wi-Fi for sensitive tasks, Network path monitoring, Data integrity checks, Architectures providing path control (e.g., SCION)
Attacker's View: "I abuse my position (on the local network or via control over an intermediary) between communicating parties."
Developer's View: "I must ensure the confidentiality and integrity of data in transit at all relevant layers. This includes enforcing strong encryption protocols like mTLS at the application layer and utilizing secure network architectures (e.g., IPsec, or path-aware networking like SCION) at the network layer. I must ensure proper certificate and path validation, and design for end-to-end protection, assuming any uncontrolled network segment is hostile."
Asset Type: Network/Communication Channel & Path Infrastructure (including local networks)
Definition: An attacker intentionally overwhelms system resources or exceeds capacity limits through a high volume of requests, data, or operations, leading to disruption, degradation, or denial of service for legitimate users.
Generic Vulnerability: Finite capacity limitations inherent in any system component (e.g., network bandwidth, CPU, memory, storage, database limits, application quotas, API rate limits, process/thread pools).
Context: This cluster covers attacks whose primary goal is to exhaust a specific, limited resource required for service operation. While often associated with network-level Distributed Denial of Service (DDoS), it generically applies to overwhelming any capacity constraint. This includes application-level attacks like flooding databases with excessive posts/data, exhausting API rate limits, filling log storage, or triggering computationally expensive operations en masse. The attack leverages volume or intensity, often via legitimate protocols or application functions (sometimes scaled via #1 Abuse of Functions), rather than exploiting specific code flaws (#2/#3) or executing malware (#7). The outcome is typically Loss of Availability.
Sub-Threats Examples: Network DDoS (SYN Flood, UDP Flood, Amplification Attacks), Application Layer DDoS (HTTP Flood, Slowloris), Database Storage Exhaustion via excessive writes, Log Volume Attacks filling disk space, API Rate Limit Flooding, Computationally Expensive Request Flood, XML bomb for parser exhaustion
Control Examples: Network Traffic Filtering/Scrubbing (DDoS Mitigation Services), Rate Limiting (Network & Application Level), Resource Quotas (Disk, DB storage, API calls), Efficient Resource Management in Code, Connection Pooling Limits, Input validation to prevent overly large/complex requests, Scalable Infrastructure Design, Anomaly Detection (Volume-based)
Attacker's View: "I abuse the circumstance of always limited capacity in software and systems."
Developer's View: "I must implement efficient resource management. This includes using appropriate data structures, setting request limits, timing out long-running operations, and releasing resources properly. Every loop and resource allocation must consider abuse scenarios. Reminder: Sometimes we need an umbrella control here."
Asset Type: Software, Network, Hardware (Their finite resources/capacity)
Definition: An attacker abuses the inherent ability of a software environment to execute foreign executable content,including inherently malicious Malware Code or legitimate tools/scripts when they execute attacker-controlled or otherwise foreign code ("dual-use").
Generic Vulnerability: The software environment's designed capability to execute potentially untrusted 'foreign' code, scripts, or binaries.
Context: This cluster deals with unauthorized execution achieved via an environment's intended execution capabilities. This includes running inherently malicious Malware Code AND the malicious use of legitimate "dual-use" tools or scripts (e.g., PowerShell, PsExec, legitimate remote admin tools) introduced or invoked by the attacker. In both cases, the attacker leverages the design of the software environment to run executable content for malicious ends. When initiated via Social Engineering (#9), this often involves tricking a user into downloading and executing new, foreign software/scripts, rather than just reconfiguring existing system features (which would be #1).
This is distinct from:
Sequential Relationship #1 → #7: When function abuse (#1) is used to invoke or enable foreign code execution, this represents a two-step sequence where the invocation mechanism is #1 and the actual code execution is #7. Common patterns include:
Sub-Threats Examples: Ransomware, Trojans, Malicious Macros, Execution via PowerShell scripts, Use of PsExec for lateral movement, Malicious use of legitimate Remote Desktop tools (when installed by attacker/victim)
Control Examples: Blocking file types, Application control/allow-listing (critical for dual-use tools), Anti-malware scanners, Script/macro execution policies, Behavioral analysis (detecting legitimate tools used abnormally), Sandboxing, PowerShell Constrained Language Mode
Attacker's View: "I abuse the environment's designed capability to execute Malware Code, malicious scripts, or newly from foreign introduced legitimate tools for my purposes."
Developer's View: "I must control code execution paths. This means validating file types and content, avoiding dynamic code execution (e.g., eval), implementing proper sandboxing, and using Content Security Policies. I will never execute user-controlled input uncontrolled."
Asset Type: Software (The execution environment, Dual-Use Tools)
Definition: An attacker gains unauthorized physical interaction with or causes physical interference to hardware, devices, facilities, or data transmission media (including wireless signals).
Generic Vulnerability: The physical accessibility of hardware, facilities, and communication media (cabling, wireless spectrum), and the exploitability of Layer 1 (Physical Layer) communications and hardware interfaces.
Context: This cluster covers threats involving manipulation or disruption at the physical level. It encompasses two main types based on the interaction required:
1. Direct Physical Access Attacks: Require the attacker to physically touch or interact directly with the hardware, device, or its immediate secure environment (e.g., tampering, theft, connecting unauthorized devices, physical intrusion into facilities).
2. Indirect Physical Access Attacks: Exploit physical properties or emanations without requiring direct contact with the core device (e.g., electromagnetic eavesdropping like TEMPEST, signal jamming, environmental disruption, acoustic attacks).
Physical access can often bypass logical security controls and may be a precursor to other attacks (e.g., installing malware via USB - #7, stealing devices with credentials - #4).
Sub-Threats Examples: Hardware Tampering, Port Access (e.g., unauthorized USB/network connection), Physical Device Theft, Facility Intrusion, TEMPEST attacks, Signal Jamming, Wireless Interception (passive), Cutting Cables, USB Baiting
Control Examples: Physical access controls (locks, guards, secure facilities), Device security (cable locks, port security), Data encryption at rest, Tamper detection/seals, Shielding against emanations (for TEMPEST), Wireless security protocols & monitoring, Secure hardware disposal
Attacker's View: "I abuse the physical accessibility or properties of hardware, devices, and signals."
Developer's View: "I must implement tamper-evident logging, encrypt sensitive data at rest, use secure key storage (HSM/TPM), and design for secure failure modes. I will assume physical access means compromise and plan accordingly."
Asset Type: Physical (Hardware, Facilities, Media, Signals)
Definition: An attacker psychologically manipulates individuals into performing actions counter to their or their organization's best interests, such as divulging confidential information, granting access, executing code, or bypassing security procedures.
Generic Vulnerability: Human psychological factors: gullibility, trust, ignorance, fear, urgency, authority bias, curiosity, or general compromisability.
Context: This cluster focuses exclusively on exploiting the human element through deception, manipulation, or influence. It leverages psychological triggers rather than technical vulnerabilities in code or systems. Social Engineering is very often the initial vector for more complex attacks, tricking users into actions that enable other threat clusters:
Crucially, technical vulnerabilities (e.g., CVEs) are never mapped to this cluster; #9 is purely about human manipulation leading to an unsafe action.
Sub-Threats Examples: Phishing (lure/deception phase), Pretexting, Baiting, Quid Pro Quo, Tailgating, Spear Phishing, Whaling, Vishing, Smishing, Water holing (luring users to a compromised site)
Control Examples: Security Awareness Training, Phishing Simulations, Clear procedures for handling requests (esp. for sensitive info/actions), Multi-person approvals for critical actions, Technical anti-phishing controls (email/URL filtering), Caller ID / Sender verification
Attacker's View: "I abuse human trust and psychology to deceive individuals."
Developer's View: "I must design interfaces that promote secure behavior. This means providing clear security indicators, confirmation dialogs for sensitive actions, and making the secure path the easiest path. UI/UX is a security control."
Asset Type: Human
Definition: An attacker compromises systems by targeting vulnerabilities within an organization's supply chain. This involves compromising third-party software components, hardware, services, or distribution/update mechanisms that are trusted and integrated into the organization's own environment or products.
Generic Vulnerability: The necessary reliance on, and implicit trust placed in, external suppliers, vendors, components, libraries, hardware, services, and their associated development or distribution processes.
Context: This cluster focuses on attacks where the initial vector leverages the trust relationship with external entities whose products or services are incorporated into the target's systems or development lifecycle. It's distinct from merely using a compromised third-party platform for attacks (e.g., using a compromised cloud server for C2 is not #10 unless the cloud service itself delivered malware via its trusted updates). Key vectors include:
A successful #10 attack often leads to #7 Malware deployment or other cluster activities within the target environment via the trusted channel.
Sub-Threats Examples: Compromised Software Updates (e.g., SolarWinds), Malicious Code in Third-Party Libraries/Dependencies (e.g., Log4j scenario if intentionally malicious), Backdoored Hardware Components, Compromised Build/CI/CD Pipelines injecting code, Tampered installation media.
Control Examples: Third-Party Risk Management (TPRM), Software Composition Analysis (SCA), Software Bill of Materials (SBOM), Secure CI/CD pipeline practices, Code signing & verification of updates/dependencies, Hardware integrity checks, Vendor security assessments
Attacker's View: "I abuse the trust in third-party components, services, or vendors incorporated by the target."
Developer's View: "I must maintain strict dependency hygiene. This involves using dependency scanning, verifying package integrity, minimizing the dependency footprint, and implementing SBOM practices. I will trust no external code implicitly."
Asset Type: Software, Hardware, Services (Specifically, the third-party elements and distribution mechanisms integrated by the target)
Understanding how data flows through IT systems and transforms into various forms of processing is fundamental to accurate threat cluster mapping. The TLCTC framework recognizes four distinct data processing pathways, each mapping to different threat clusters based on the nature of the transformation and the vulnerabilities exploited.
Pathway 1: Data → Data (#1 only)
Pure data manipulation through legitimate functions without any code execution. The attacker manipulates data, parameters, configurations, or sequences of actions within the intended functional domain.
Characteristics:
Examples:
Mapping: #1 Abuse of Functions
Pathway 2: Data → Function Invocation → Foreign Code Execution (#1 → #7)
Abuse of legitimate system functions to invoke or enable the execution of foreign code, scripts, or binaries. This is a TWO-STEP sequence where the function invocation is #1 and the actual code execution is #7.
Characteristics:
Examples:
Critical Note on LOLBAS (Living Off The Land Binaries and Scripts):
When attackers use legitimate system binaries/scripts for malicious purposes:
LOLBAS execution is NOT purely #1, as foreign code/scripts execute via these tools.
Mapping: #1 → #7 (sequential)
Pathway 3: Data → Exploit Code via Implementation Flaw (#2 or #3)
Data crafted to exploit implementation flaws in source code, forcing unintended code execution. This creates a data→code transition by triggering coding bugs that allow Exploit Code (foreign code) to execute outside normal execution paths.
Characteristics:
Examples:
Mapping:
Pathway 4: Data → Foreign Code via Designed Execution Capability (#7 only)
Foreign executable content (malware, scripts, binaries) executes directly through the system's intended execution environment without requiring function abuse or implementation flaw exploitation.
Characteristics:
Examples:
Mapping: #7 Malware
Key Principle: Data→Code Transitions
Only #2, #3, and #7 involve actual code execution:
Threat Cluster: "A threat cluster organizes a set of threats that exploit the common vulnerabilities related to IT systems and humans."
Threat: "A threat is a set of tactics, techniques and procedures (TTP) that attackers apply to provoke an event or incident, exploiting vulnerabilities in IT systems or human behaviors."
Cyber Risks describe the likelihood of occurrence of a cyber event in which control over IT systems or persons is lost due to one or more of the 10 Top Level Cyber Threat Clusters, leading to consequential damage (impact).
An Attack Path is the Sequence of applied Attack Vectors.
Scope of Server Software: Includes Server APIs, incorporated Library APIs, Socket APIs, and Local APIs that run on server-side systems to provide services and resources to clients.
Scope of Client Software: Encompasses Client APIs, incorporated Library APIs, Socket APIs, and Local APIs that operate on the client side of a communication.
Malicious Code: Distinguished between "Exploit Code", which targets specific vulnerabilities to modify software behavior, and "Malware Code", which operates within expected execution paths for harmful purposes. "Malware Software" refers to the comprehensive suite of tools (foreign code) that may incorporate multiple techniques, including exploit capabilities.
Malvertising: Identified as a method that can deploy either exploits or malware, depending on the attacker's strategy. It's a vector rather than a distinct category of threat.
Phishing: Recognized for its versatility in threat delivery, capable of initiating various attack clusters based on the context of the content it delivers.
Privilege escalation: In the context of the 10 Top Level Cyber Threat Clusters framework, privilege escalation is addressed through multiple clusters, depending on the specific techniques employed by attackers. In the "Exploiting Server" and "Expoiting Client" clusters, privilege escalation often involves exploiting software vulnerabilities, such as buffer overflows or injection flaws, to gain unauthorized higherlevel permissions. However, the Abuse of Functions cluster represents a distinct approach to privilege escalation, where attackers leverage legitimate system features or misconfigurations to elevate their access rights, without necessarily exploiting coding vulnerabilities. Additionally, the Social Engineering cluster can enable privilege escalation by manipulating users into revealing credentials or granting access to restricted resources. While these clusters may lead to similar outcomes, distinguishing the underlying techniques allows for more targeted control implementation and risk management strategies within the framework.
Third-Party Risk and Supply Chain Threat Cluster: A cyber event at a third party only represents a Supply Chain threat when it involves components or services integrated into your IT systems (e.g., software dependencies, update mechanisms, development pipelines) rather than externally managed services. It's crucial to recognize that each third party faces all ten threat clusters themselves, and their compromise through any of these clusters could potentially enable Supply Chain attacks against your organization. This distinction is crucial for accurate threat classification and control implementation within the framework.
Process Injection: Can occur either as #1 (Abuse of Functions) through abuse of legitimate features (like debugging APIs and DLL injection) where the injection capability was intentionally designed, or as #2/#3 (Exploiting Server/Client) through exploitation of code flaws/vulnerabilities (like buffer overflows) where injection was never intended. The key distinction is whether the injection vector was a designed feature being misused versus an underlying software vulnerability being exploited.
A.I. AI AGI - Positioning:
The 10 Top Level Cyber Threat Clusters framework bridges the gap between strategic planning and operational execution in cybersecurity. This two-tiered approach ensures a consistent strategic understanding of cyber risks while allowing flexibility to adapt to emerging threats and evolving attack methodologies at the operational level.
The strategic layer focuses on high-level risk management, policy-making, and program governance. Key components include:
The operational layer is where security controls are implemented, monitored, and adjusted. Key aspects include:
At the center of the bow-tie model are Cyber Risk Events and Cyber Incidents:
Cyber Risk Events: Potential occurrences that could lead to a breach or system compromise Cyber Incidents: Actual security breaches or system compromises that have occurred
The right side of the bow-tie model addresses the potential consequences of cyber risk events and incidents, which are managed at both the strategic and operational levels. Take care of event chains as described in the chapter about the Cyber-Bow-Tie Event Chain.
The framework creates a common language and facilitates dynamic interaction between these layers:
By adopting this comprehensive two-tiered approach, organizations can ensure their cybersecurity efforts are both strategic in planning and adaptable in execution, creating a more resilient and effective security posture that addresses both potential and actual cyber risk events.
Cause Side (Threats): The Top 10 Cyber Threat Clusters, which can lead to a System Risk Event if preventive controls are insufficient.
Risk Event (System Compromise): The central risk event is the compromise of an IT system or human, resulting in a loss of control - Cyber incident.
Consequences (Data Risk Events): The compromised system can lead to data risk events such as loss of confidentiality, integrity, or availability.
Consequences (Business Risk Events): Data risk events can cascade into multiple levels of business risk events and consequences, including financial losses, reputational damage, and operational disruptions.
Cyber Risk describes the probability of occurrence of a cyber event in which IT systems or human actors are compromised due to one or more of the 10 Top Level Cyber Threat Clusters, leading (via Event-Chains) to consequential damage (impact).
Preventive Controls: Controls implemented to mitigate the likelihood of a risk event occurring, aligned with the Top 10 Cyber Threat Clusters. Using NIST functions this includes IDENTIFY (indirect) and PROTECT (direct).
Detective, Reactive, and Corrective Controls: Controls designed to identify risk events (Detective/DETECT), respond (RESPOND) to and recover (RECOVER) from them at the system level (Reactive), and ensure business process continuity (Continuity), minimizing overall impact.
Control Failure: A control failure is a deviation from the control objective, which can allow threats to materialize and impact assets.
Control Objective: A control objective is the specific aim or purpose that a control is intended to achieve. It defines what the control should accomplish in terms of risk mitigation for a particular threat cluster. Each control is aligned with a single, clear objective.
Control Design Effectiveness: Design effectiveness evaluates whether a control, as conceived and structured, is capable of achieving its objective if it operates as intended. It assesses the theoretical capability of the control to address the identified risk within its specific threat cluster.
Control Operational Effectiveness: Operational effectiveness focuses on whether the control is actually working as designed in practice. It examines if the control is being executed correctly and consistently over time to meet its objective.
Relationship to Control Objectives: Both design effectiveness and operational effectiveness are methods of evaluating how well a control meets its single, defined objective. They are not separate objectives themselves, but rather two aspects of assessing the control's ability to achieve its intended purpose within the framework of the Top Level Cyber Threat Clusters.
Considerations: The achievable level of operational effectiveness may vary depending on the nature of the threat cluster. For example, controls for Malware (#7) may never achieve 100% operational effectiveness due to "1st Wave" aspects and detection latencies. Some controls, like Multi-Factor Authentication for Identity Theft (#4), can theoretically achieve near-perfect operational effectiveness within their specific scope. The interplay between different threat clusters (e.g., Social Engineering #9 potentially circumventing Identity Theft #4 controls) necessitates a holistic approach to control design and implementation.
The Bow-Tie model provides a structured approach to identifying, assessing, and managing cyber risks by connecting threats, cyber risk events/incidents, consequences, and controls in a comprehensive framework. This enables organizations to develop targeted risk mitigation strategies and align their defenses with the ever evolving cyber threat landscape, while also ensuring effective response, recovery, and continuity measures are in place.
Example: the bow-tie here is not complete - its exemplary related to the other operational causes, events and paths
The positioning of "Loss of Control" or "System Compromise" as the central event in the Bow-Tie model requires careful explanation. This placement reflects a crucial understanding: when a threat successfully materializes (a threat event), it often results in some form of compromise or loss of control, which may or may not immediately lead to data risk events.
Examples of Delayed Data Risk Events:
Examples of Immediate Data Risk Events:
This distinction is operationally significant because:
1. It creates a critical detection window between initial compromise and data risk events in cases where effects are not immediate
2. It reflects the reality of modern attacks where adversaries often maintain persistence (via complex attack paths) before executing their ultimate objectives
3. It enables more precise mapping of detective and reactive controls in the period between compromise and data risk events
4. It acknowledges that some threats can lead to immediate data risk events, requiring rapid response capabilities
Therefore, the central position of "Loss of Control" serves as a crucial pivot point between threat realization and potential consequences, supporting both the sequence concept of the framework and the practical reality of cyber attacks. This positioning accommodates both scenarios where data risk events are delayed and where they occur immediately upon compromise.
Don't forget:
The Cyber Bow-Tie model serves as a powerful visual tool for structuring a comprehensive, event-centric cyber risk register. By integrating the 10 Top Level Cyber Threat Clusters with IT and business risk events, this framework enables organizations to systematically identify, assess, and manage their cyber risk landscape.
Conceptual Framework
In the Top Level Cyber Threat Clusters (TLCTC) framework, "Loss of Control" or "System Compromise" serves as the central event in the Bow-Tie model, acting as a pivotal point between threat realization (cause) and potential consequences (effect). These effects can themselves become events in an event chain concept, where one outcome triggers subsequent events. This distinction is operationally significant and represents an important conceptual clarification.
Relationship Between Threat Clusters and Data Risk Events
When viewing the TLCTC framework through the lens of the Bow-Tie model, we can methodologically position "Loss of Control" or "System Compromise" as a higher-level classification framework. This represents the initial compromise that may lead to business impact requiring evaluation.
In this approach:
Data Risk Events and Their Sources
Understanding the relationship between data risk events and their triggers is crucial for effective risk management. An important distinction must be made between cyber threat-triggered data risk events and those stemming from other operational risks.
Cyber Threat Cluster-Triggered Data Risk Events
Data risk events often result from one or more cyber threat clusters. Each cluster can lead to specific types of data risks:
Non-Cyber OpRisk-Triggered Data Risk Events
Data risk events can also stem from other operational risk factors, which are not classified as cyber risks:
This distinction is vital for developing targeted risk tolerance statements and appropriate mitigation strategies for each category of data risk events and threat clusters.
Refined Data Risk Event Definitions
It's crucial to separate outcomes (data risk events) from mechanisms or techniques used to achieve those outcomes. This distinction improves risk definition, threat modeling, and control mapping. From an attacker's perspective, these outcomes are:
This refinement represents an important improvement over traditional CIA triad terminology because:
Example Clarifications
These data risk events can trigger further events in a chain. For example, Loss of Confidentiality (data theft) might lead to regulatory fines, reputation damage, and customer loss - each representing subsequent events in the chain following the initial data risk event.
Data Risk Events Matrix
The following matrix shows the relationship between the 10 Top Level Cyber Threat Clusters and the three refined Data Risk Event types:
Threat Cluster/Loss of Control | Loss of Confidentiality (C) | Loss of Integrity (I) | Loss of Availability (A) |
#1 Abuse of Functions | ✓ | ✓ | ✓ |
#2 Exploiting Server | ✓ | ✓ | ✓ |
#3 Exploiting Client | ✓ | ✓ | ✓ |
#4 Identity Theft | ✓ | ✓ | ✓ |
#5 Man in the Middle | ✓ | ✓ | ✓ |
#6 Flooding Attack | ✓ | ||
#7 Malware | ✓ | ✓ | ✓ |
#8 Physical Attack | ✓ | ✓ | ✓ |
#9 Social Engineering | ✓ | ✓ | ✓ |
#10 Supply Chain Attack | ✓ | ✓ | ✓ |
Implications for Cybersecurity Frameworks
This refinement has significant implications for how security frameworks should define and address data risks:
By adopting these refined definitions, organizations can significantly improve the clarity, consistency, and effectiveness of their risk management practices within the TLCTC framework.
Question: There are overlapping Threat Clusters, such as Social Engineering and Identity Theft, with Phishing Emails. How are they related?
Answer: While it may initially appear that threat clusters like Social Engineering and Identity Theft overlap, particularly in scenarios involving phishing emails, it's important to understand these as distinct yet sequentially linked components within an attack. The absence of true overlap is fundamental to the consistency of the 10 Top Level Cyber Threat Clusters framework.
Phishing emails typically initiate through the cluster of Social Engineering (Cluster #9), where the attacker manipulates human psychology to provoke an action. Once this action succeeded, this threat was realized. The action is specific action, such as clicking a link to a website and other threats (eg. #3, #7, #4), exploiting human susceptibility to deception. Once the action is taken, the attack may progress to another cluster, such as Identity Theft (Cluster #4). If the link in the phishing email (#9) leads to a fraudulent website designed to harvest credentials, the threat transitions into later Identity Theft, the use of these credentials. Here, the focus shifts to the unauthorized acquisition and misuse of personal data.
The clear categorization of these threats in sequences:
Understanding these sequences helps in accurately identifying the progression of an attack, enabling targeted interventions for each phase of the threat. This approach emphasizes the need for distinct countermeasures such as user training and awareness to mitigate Social Engineering and robust authentication processes to prevent Identity Theft.
This presentation details how attacks can be better understood by examining the sequence of threat clusters they involve. By distinguishing between different pathways and their targeted vulnerabilities, we can tailor more effective defensive measures specific to each attack vector.
Initial Threat Cluster | Subsequent Threat Cluster | Example Scenario | Primary Exploited Vulnerability |
Social Engineering (#9) | Identity Theft (#4) | Phishing email with a link to a fraudulent form collecting user IDs and passwords #9 then using the credentials #4 | Human susceptibility to deception - #9, weakness of the procedure with credentials - #4 |
Social Engineering (#9) | Exploiting Client (#3) | Phishing email with a link to a website #9 exploiting a zero-day vulnerability #3 | Human interaction - #9, client-side software vulnerability - #3 |
Each scenario showcases the importance of understanding the transition from one threat cluster to another, thereby helping in designing precise and targeted countermeasures.
A more sophisticated attack: #9->#3->#7->#4->#1->#7 (it starts with mail and ends in encrypted systems ;-)
Read Chapter “Attack Path Notation” for further Details.
Based on analysis of the 10 Top Level Cyber Threat Clusters concept, it is indeed applicable at the interface level. This applicability stems from several key aspects of the framework:
By applying this concept at the interface level, organizations can systematically identify and categorize threats specific to their system interfaces, enabling more targeted risk management and security strategies. This approach aligns well with the concept's goal of providing a pragmatic solution for targeted threat identification across diverse IT systems and contexts.
Based on careful consideration and analysis, the 10 Top Level Cyber Threat Clusters concept is applicable at the function call level, with some important considerations:
Call-level mapping rule
This rule prevents overlap: logic misuse (#1) vs. identity presentation/use (#4).
In conclusion, while theoretically applicable, practical implementation would require careful consideration of the trade-offs between security granularity and system performance/complexity. This approach could be particularly valuable for critical functions handling sensitive data or operations.
Core Concepts
Client-Server Relationship
The client-server relationship in a vertical stack is contextual rather than absolute. Key principles:
Directional Analysis
Component Interaction Model
+-------------------+
| Application | Ring 3: User Mode
| (Client) | |
+-------------------+ V (System Call)
|
+-------------------+
| OS Services | Ring 2: Services
| (Client/Server) | |
+-------------------+ V (Driver Request)
|
+-------------------+
| HAL/Driver Level | Ring 1: Drivers
| (Client/Server) | |
+-------------------+ V (Hardware Access)
|
+-------------------+
| Kernel | Ring 0: Kernel Mode
| (Server) |
+-------------------+
Protection Ring Architecture
Ring 0 (Kernel Mode)
Ring 1 (HAL/Driver Level)
Ring 2 (OS Services)
Ring 3 (User Mode)
Attack Surface Analysis
Ring Boundary Interactions
Vulnerability Mapping Principles
Bidirectional Attack Paths
Downward Path Example (Ring 3 → Ring 0):
1. Client exploit of system call interface (#3)
2. Server exploit in Ring 2 service (#2)
3. Server exploit in Ring 1 driver (#2)
4. Abuse of kernel functions (#1)
Upward Path Example (Ring 0 → Ring 3):
1. Server exploit in interrupt handler (#2)
2. Client exploit in Ring 2 callback (#3)
3. Client exploit in Ring 3 handler (#3)
4. Malware execution in application (#7)
Threat Cluster Application
Applicable Clusters by Ring Boundary
Nine threat clusters apply at each boundary (excluding #9 Social Engineering):
Abuse of Functions (#1)
Exploiting Server (#2)
Exploiting Client (#3)
Identity Theft (#4)
Man in the Middle (#5)
Flooding Attack (#6)
Malware (#7)
Physical Attack (#8)
Supply Chain (#10)
Implementation Framework
Security Control Requirements
Ring Boundary Controls
Ring 3 → Ring 2
Ring 2 → Ring 1
Ring 1 → Ring 0
Case Studies and Common Misconceptions
Illustrative Examples
Hypothetical Vulnerability 1 (Server)
A kernel component contains a buffer overflow vulnerability during system call processing. A user-mode process exploits this by crafting a specific system call that overflows the kernel's buffer on the server side code. This is categorized as "#2 Exploiting Server" because the vulnerability exists in the server code processing a user request.
Hypothetical Vulnerability 2 (Client)
A driver handling network data receives a carefully crafted packet that triggers a buffer overflow in the driver's processing code during a network event handling callback. Though triggered by network data, this is a client-side issue in how it processes responses from the network, mapping to "#3 Exploiting Client".
Real-World Case Study: Hyper-V VSP
A vulnerability exists within the Hyper-V VSP component where it acts as a client making calls to the NT Kernel. The vulnerability involves the VSP component mismanaging a response from the Kernel, leading to a buffer overflow on the client side. Despite the final impact involving privilege elevation and kernel code execution, the initial vulnerability is exploited within the client-side code, mapping to "#3 Exploiting Client".
Common Misconceptions
Privilege Escalation vs. Root Cause
Component Roles
Analysis Pitfalls
Key Analysis Requirements
Implementation Guidelines
Critical Success Factors
Best Practices
Here I would expect NIST to incorporate my TLCTC concept and make some refinements. The Goal should be building a bridge from NIST to the (extended) MITRE World (ATT&CK, CWE, CAPEC and CVE)
The Top Level Cyber Threat Clusters (TLCTC) framework proposes a structured approach to categorizing cyber threats through ten distinct clusters. This naturally raises the question: "Why ten clusters?" This analysis explores the rationale behind this number, its implications for practical implementation, and its role in the evolution of cyber threat categorization.
The selection of ten clusters serves as a deliberate challenge to the cybersecurity community, particularly to major bodies like NIST and MITRE. It highlights the limitations of existing frameworks like STRIDE, which has served the industry well but struggles to address the full spectrum of modern cyber threats. The TLCTC framework demonstrates that a more comprehensive and logically consistent approach is possible, while remaining open to evolution as long as the fundamental axioms are not violated.
The framework's structure allows for evolution within certain clusters.
Here I provide examples:
Refinement of #2 Exploiting Server:
The Exploiting Server threat cluster targets vulnerabilities in server-side software to manipulate server behavior or gain unauthorized access using exploit code. This refinement provides a more detailed categorization of the attack vectors within this cluster: imo: job of a NIST & MITRE agreement, but until then:) …
#2.1 Server communication protocol exploit
This vector targets vulnerabilities in the protocols used for communication between servers and clients.
Examples:
#2.2 Server core function exploit
This vector focuses on vulnerabilities within the main functionalities of the server software, including internal data parsing and handling.
Examples:
#2.3 Server external handler exploit
This vector covers vulnerabilities that arise when the server delegates handling to external software or components.
Examples:
Key Characteristics of Exploiting Server:
This refinement maintains the generic nature of the threat cluster while providing a comprehensive framework for categorizing server-side exploits across various types of server software. It aligns with the concept's goal of being universally applicable across different IT systems and contexts.
Refinement of #3 Exploiting Client
The Exploiting Client threat cluster targets vulnerabilities in client-side software to manipulate client behavior or gain unauthorized access using exploit code. This refinement provides a more detailed categorization of the attack vectors within this cluster: imo: job of a NIST & MITRE agreement, but until then:) …
#3.1 Client communication protocol exploit
This vector targets vulnerabilities in the protocols used for communication between clients and servers.
Examples:
#3.2 Client core function exploit
This vector focuses on vulnerabilities within the main functionalities of the client software, including internal data parsing and handling.
Examples:
#3.3 Client external handler exploit
This vector covers vulnerabilities that arise when the client delegates handling to external software or components.
Examples:
Key Characteristics of Exploiting Server:
This refinement maintains the generic nature of the threat cluster while providing a comprehensive framework for categorizing client-side exploits across various types of client software. It aligns with the concept's goal of being universally applicable across different IT systems and contexts.
Refinement of Physical Attack Cluster (#8)
The Physical Attack cluster can be further refined into two subcategories to provide a more nuanced understanding of the different types of physical threats
#8.1 Direct Physical Access Attacks
This subcategory encompasses any attack that requires direct physical interaction with the hardware or its immediate environment.
#8.2 Indirect Physical Access Attacks
This subcategory focuses on attacks that exploit physical vulnerabilities without direct contact with the hardware.
This refinement allows for a more precise categorization of physical threats, enabling organizations to develop more targeted security measures and risk management strategies for each subcategory of physical attacks.
Refinement of the Supply Chain Attack Cluster (#10)
#10.1 Update Vector (active, post-deployment)
This covers attacks on update mechanisms and distribution channels for software, firmware, or hardware already in use. It would include compromised third-party components delivered via updates.
#10.2 Development Vector (silent, pre-deployment)
This encompasses attacks on the development process, including compromises of source code repositories, build systems, or testing environments. It would also cover the incorporation of vulnerable or malicious third-party libraries or components during development.
#10.3 Hardware Supply Chain Vector
This covers attacks that target hardware components or manufacturing processes.
Each of these subcategories represents a distinct and generic vector in the supply chain, following the axiom of distinction.
These examples are intended to show that, taking the axioms into account, the TLCTC concept can be expanded. The notation of an attack path can thus be designed in a more granular way, e.g., #10.1->#7->[Data Risk Event].
As mentioned, the TLCTC concept starts with 10 clusters, primarily for pragmatic reasons and until the TLCTC concept gains more widespread adoption. However, without the key players NIST and MITRE, it will be difficult.
The Need for Consistent Sub-Threat Structures (or TTPs)
At the operational level of cybersecurity, there is a pressing need for a standardized approach to categorizing and managing sub-threats, TTPs (Tactics, Techniques, and Procedures), and attack sequences. While the Top Level Cyber Threat Clusters provide a solid foundation at the strategic level, the operational layer requires further refinement and consistency.
Currently, organizations like NIST, CISA, MITRE, as well as standards such as STIX and RFC 9424, each have their own approaches to describing and categorizing threats at a granular level. This fragmentation leads to several challenges:
To address these issues, I propose that the cybersecurity community should work towards developing consistent subthreat structures within each of the Top Level Cyber Threat Clusters. This standardization effort should aim to:
As examples of how this standardization could be implemented, i have developed detailed integration proposals for two major frameworks:
These proposals serve as starting points for discussion and highlight the potential benefits of a more standardized approach. By adopting a consistent sub-threat structure across different frameworks and standards, we can:
Moving forward, it is crucial for the cybersecurity community to come together and work towards this standardization. This effort will require collaboration between standards bodies, security vendors, researchers, and practitioners to develop a truly unified approach to operational cybersecurity.
While the following examples provide some guidance, they are not always precise, as they are not standardized definitions. I am referring to NIST & MITRE here, with the understanding that MITRE would need to be "expanded." See my proposal for MITRE here: [Standardizing Strategic Cyber Security].
NIST and CISA likely appreciate this as well. I am, of course, open to the idea of creating potential sub-clusters. However, my goal was to define straightforward top-level categories.
Following examples should give you an idea of the direction. IMO: Most are "buzzwords", which means lack of definition - > Hello MITRE and NIST! You are welcome here :-) And AI is welcome either, because only a few will read the complete white paper ;-)
1. **Abuse of Functions** - Sub-Threats: - Abuse of standard services and features - Abuse of information made public - Data Poisoning - Abuse of insecure service configurations - Abuse of legitimate system tools (e.g., lolBins, PowerShell)) - ARP Spoofing -> leads to man in the middle #5 - DNS Spoofing -> leads to man in the middle #5 - 20 BGP Hijacking -> leads to man in the middle #5 - SSL Stripping (attacker needs to be MitM already eg via ARPPoisoning - and SSL Stripping is an abuse of a (downgrade) function
2. **Exploiting Server** - Sub-Threats: - Buffer Overflows - SQL Injections - Cross-Site Scripting (XSS) - XML External Entity (XXE) Attacks - Server Side Request Forgery (SSRF) - Directory Traversal - Ping of Death
3. **Exploiting Client** - Sub-Threats: - Malvertising - Watering Hole Attacks - Clients App Exploits (e.g. Browser, PDF Reader, Java, Flash) - Insecure Deserialization
4. **Identity Theft** - Sub-Threats: - Using Stolen Credentials (eg IDs, Passwords, Certificates, Private Keys) - Session Hijacking - Pass-the-Ticket/Pass-the-Hash Attacks - Token Hijacking - password spray attacks - Brute-Force Attacks - Fake Proxy Websites - Domain Squatting
5. **Man in the Middle** - Sub-Threats: (MitM has a focus on a already compromised environment - you cannot trust any components between the endpoints A and B) - Wi-Fi Eavesdropping (attacker needs to be MitM already eg within physical range -> #8) - Pineapple Attacks (attacker needs to be MitM already eg within physical range -> #8) - Rogue Hotspots (attacker needs to be MitM already eg within physical range -> #8 then eg fakes SSID #4)
6. **Flooding Attack** - Sub-Threats: mostly known as DDOS Attacks on dif erent layers - SYN Flood - UDP Flood - HTTP Flood - ICMP Flooding - Slowloris - NTP/DNS Amplification Attacks - Botnet-Driven Attacks
7. **Malware** - Sub-Threats: - Ransomware - Trojans - Keyloggers - Rootkits - Spyware - Worms - Adware - Mobile Malware - E-Banking Malware
8. **Physical Attack** Direct Physical Access Attacks: - Evil Maid Attacks - Hardware Keyloggers - Direct Hardware Tampering - Device Theft - Physical Intrusion into Secure Areas - USB Baiting (leaving malicious USB devices) - Replacement of Hardware Components - Physical Damage to Infrastructure Indirect Physical Access Attacks: - TEMPEST Attacks (Electromagnetic Emissions) - RFID Skimming - Acoustic Attacks (Sound Wave Exploitation) - Optical Attacks (e.g., Shoulder Surfing) - Thermal Imaging Attacks - Power Analysis Attacks - Environmental Manipulation (e.g., Temperature, Humidity) - Van Eck Phreaking (Remote Screen Viewing)
9. **Social Engineering** (Information Manipulation) - Sub-Threats: - CEO Fraud - Subscription Traps - Fraudulent Contests - Check Fraud - Cyberbullying - Dubious Webshop - Requests for financial help from acquaintances - Fake Support - Financial Agents - Fake Threat Emails from Authorities - Investment Fraud - Classified Ads Fraud - Package Subscription Traps - Invoice Manipulation Fraud (BEC Fraud) - Romance Scam - Defamation - Sextortion - Forbidden Pornography - Advance Fee Fraud - Web Administrators Blackmail - Tailgating (unauthorized access) - Phishing - Vishing - Smishing - Baiting (e.g., with USB sticks)
10. **Supply Chain** - Sub-Threats: - Compromised Libraries or Dependencies - Backdoors - Update-Server Hijacking - Compromised Container Images - Manipulated Hardware (physical attack on Supply Chain)
To further enhance the utility of Cyber Threat Radars and facilitate more precise threat intelligence sharing, I recommend adopting a standardized notation for describing attack sequences:
For example, an attack sequence of #9>#3>#7->#7->#1->#7 could represent:
This standardized notation should be mandatory when exchanging information about attacks, especially when describing APT profiles. It allows for:
By adopting this approach, the cybersecurity community can achieve a new level of clarity and consistency in threat analysis and communication, further enhancing the power of Cyber Threat Radars in global cybersecurity efforts.
The TLCTC framework employs a dual-notation system that addresses the distinct communication needs of strategic management and operational implementation. At the strategic level, the simple #X → #Y format (e.g., #9→#3→#7) provides an intuitive, human-readable notation for executives and security leaders to discuss attack paths, assess risks, and make resource allocation decisions. This notation uses numbers #1 through #10 for the threat clusters, arrows (→) for attack progression, and plus signs (+) for parallel execution (e.g., #1+#7), enabling quick comprehension and effective communication across organizational levels.
Complementing this strategic notation, the operational level employs the structured TLCTC-XX.YY format (e.g., TLCTC-08.00 for Physical Attack, with refinements like TLCTC-08.01 for Direct Physical Access). This machine-readable format enables automated processing, database integration, and systematic tool implementation while maintaining the flexibility for detailed sub-categorization. The prefix ensures proper framework attribution, the zero-padded primary cluster number (01-10) enables consistent sorting, and the suffix (.YY) allows for future refinement without disrupting the core structure.
This dual-layer approach bridges the critical gap between high-level strategic discussions and detailed operational execution. For instance, a CISO can communicate to the board about a "#9→#3→#7 attack pattern" threatening the organization, while the SOC team implements specific controls for "TLCTC-09.00, TLCTC-03.00, and TLCTC-07.00" in their security tools. Both notations remain fully compatible and can be used interchangeably based on context—strategic dashboards might display #8 for Physical Attack, while the underlying SIEM rules reference TLCTC-08.01 and TLCTC-08.02 for precise control implementation. This flexibility ensures that the TLCTC framework serves as an effective communication tool from the boardroom to the security operations center, maintaining consistency while adapting to different organizational needs.
In practice, the dual-notation system proves invaluable across diverse security scenarios. Consider the Emotet ransomware campaign where the incident commander briefs executives using strategic notation: "The attackers used a #9→#7→#7→#4→(#1+#7) sequence—social engineering email, initial Emotet malware, secondary Trickbot download, credential theft, then simultaneous domain admin abuse and Ryuk ransomware deployment." Meanwhile, the technical team documents with operational precision: "TLCTC-09.00 (phishing), TLCTC-07.00 (Emotet dropper), TLCTC-07.00 (Trickbot payload), TLCTC-04.00 (credential harvesting), then parallel TLCTC-01.00 (AD privilege abuse) + TLCTC-07.00 (Ryuk encryption)." The notation clearly shows both the repeated malware stages and the devastating parallel final attack.
The framework's dual notation also enhances threat intelligence sharing and regulatory compliance. When analyzing APT campaigns, analysts can communicate patterns like "#9→#3→#7→#7→#1→#7 attacks" showing how attackers repeatedly deploy different malware stages (reconnaissance tools, then persistence mechanisms, then final payloads) after initial compromise. For CVE analysis, such as the Hyper-V vulnerability (CVE-2025-21333), teams can map potential sequences: "Primary #3 with possible #4→#3 or #7→#3 preceding paths" at the strategic level, while documenting TLCTC-03.00 as the primary cluster with detailed prerequisites in operational systems. This consistency enables both rapid strategic communication and precise technical implementation.
Security tool integration demonstrates the practical benefit when handling complex, multi-stage attacks. A SIEM might alert on a pattern like #9→#3→#7→#4→#4→(#1+#7) where repeated credential theft attempts (#4→#4) indicate persistent lateral movement before the parallel execution of privilege escalation and ransomware. The dashboard shows this strategic view for SOC managers, while correlation rules trigger on specific TLCTC codes—detecting TLCTC-04.00 appearing multiple times within a session, then alerting on simultaneous TLCTC-01.00 and TLCTC-07.00 events. This dual-layer approach ensures that whether tracking repeated exploitation attempts, parallel attack execution, or sequential campaign progression, teams maintain clear, consistent communication from detection through response.
The TLCTC framework adopts a sequential attack-path notation in which Supply Chain (#10) may appear inside the sequence to mark the trust/domain boundary where legitimate actions in one domain become supply-chain compromises for downstream victims.
Core Principle
When #10 appears in the middle of an attack path, it denotes the exact point where:
Boundary test: If removing the third-party trust link would stop the step from succeeding, #10 belongs there.
Standard Notation
#9 → #4 → #1 → #10 → #3
This reads as:
Why this works:
Position alone communicates the boundary:
Refinements for Precision
Use #10 sub-vectors to specify the channel:
Example:
#9 → #4 → #1 → #10.2 → #3 — transition via the development vector.
#7 → #1 → #10.1 → #7 — malware enables function abuse, then update vector propagates malware downstream.
Cluster identity guardrails: #4 remains credentials; #1 remains function abuse; #2/#3 remain server/client exploit; #7 remains foreign/malicious code execution. #10 never absorbs these semantics—it’s the bridge.
Practical Examples with Clear Domain Transitions
Example 1: Repository Compromise
Scenario: Developer credentials stolen; repo modified; downstream devs affected
Path: #9 → #4 → #1 → #10 → #3
Reading: Phishing → creds → repo function abuse → trust boundary → downstream IDE exploit.
Example 2: Build System Compromise
Scenario: CI/CD compromised; backdoors injected into builds
Path: #2 → #4 → #1 → #10.2 → #7
Reading: Server exploit → service creds → build function abuse → dev-vector boundary → malware executes downstream.
Example 3: Malicious Package Publication (typosquatting)
Scenario: Attacker publishes a malicious npm package
Path: #1 → #10 → #7
Reading: Abuse of publish function → immediate supply-chain transition → malware execution at consumers.
Example 4: Update Distribution Compromise
Two precise variants:
Example 5: Insider at Vendor
Variant A — Backdoor intentionally added (executes at customer):
#1 → #10.2 → #7
Insider abuses dev access → dev-vector boundary → malware executes downstream.
Variant B — Vulnerability intentionally introduced (later exploited):
#1 → #10.2 → #2/#3
Insider introduces flaw → dev-vector boundary → attacker later exploits server/client at customers.
Rules for Using #10 in Attack Sequences
Common Attack Patterns with Domain Transitions
Optional Notational Aids (when you want extra clarity)
Advantages of This Notation
Strategic clarity — Leadership instantly sees where supply-chain risk emerges.
Operational precision — Teams see which hop crosses the boundary and keep cluster semantics clean.
Incident analysis — Documents propagation through trust relationships explicitly.
Threat intelligence — Standardized sharing of supply-chain patterns.
Risk & control mapping — #10 hops map directly to targeted controls.
Implementation Guidance
For documentation
Insert #10 exactly where a third-party trust is honored and enables the next step. Keep adjacent steps mapped to their true clusters.
For threat modeling
Identify potential #10 transition points:
For control mapping
Place controls at #10 transitions (examples):
MFA Bombing (also known as MFA Fatigue or MFA Push Spam) is an authentication bypass technique where an attacker, having already obtained valid user credentials, repeatedly triggers Multi-Factor Authentication (MFA) push notifications to the legitimate user's device. By overwhelming the user with continuous authentication requests, the attacker aims to either annoy the user into accidentally accepting a push notification or wear down their security vigilance through alert fatigue. This technique gained prominence in various high-profile breaches, including the 2022 Uber compromise.
Attack Path: #4 -> #1 -> #9 -> #4
1. Initial stage (#4 Identity Theft)
Attacker has already obtained userID and password and is using it here
2. MFA Bombing (#1 Abuse of Functions)
3. MFA Fatigue (#9 Social Engineering)
4. Final stage (#4 Identity Theft again)
This is a great example of how the TLCTC framework helps us understand attack sequences clearly. The ability to request MFA challenges repeatedly is not a code flaw (#2/#3), but rather an abuse of intended functionality (#1), which is then combined with social engineering (#9) to complete the identity theft (#4). In Case of MFA attackers have to do two steps to complete #4.
The cyber threat landscape experiences constant evolution, primarily driven by changes in IT system types, their functional domains, and underlying technologies. From traditional enterprise systems to cloud infrastructure, from Internet of Things (IoT) devices to quantum computing platforms, the variety and complexity of IT systems continue to expand. However, it's crucial to understand that while the technological implementation details may change, the fundamental vulnerabilities that cyber threats exploit remain consistent. The Top Level Cyber Threat Clusters (TLCTC) framework maintains its relevance and applicability precisely because it focuses on these underlying generic vulnerabilities rather than specific technological implementations.
This framework's strength lies in its ability to categorize threats based on root causes and generic vulnerabilities, transcending the specific characteristics of any particular IT system type. Whether analyzing threats to a traditional database server, a cloud-native application, or an emerging quantum computing platform, the same ten clusters provide a comprehensive framework for threat identification and risk management. This consistency enables organizations to maintain effective security strategies even as their technology landscape evolves.
This approach allows organizations to:
A Strategic Perspective
Organizations often attempt to categorize cyber threats based on IT system types – creating separate threat categories for cloud systems, IoT devices, SCADA systems, and other technology-specific implementations. This approach presents several critical problems:
This system-type-based categorization persists despite its limitations, largely due to historical practices and the natural tendency to organize threats around familiar technical boundaries. However, this approach becomes increasingly unsustainable as technology landscapes grow more complex and interconnected.
1. Generic Vulnerabilities vs. System Types
Strategic Level (GOVERN)
Operational Level
The TLCTC framework provides a strategic foundation for threat categorization while acknowledging the operational importance of IT system types. This dual-level approach ensures:
By maintaining this clear separation between strategic threat categories and operational asset management, organizations can build more effective and sustainable security programs.
The NIST CSF functions can be used to organize controls and their objectives (e.g., "Protect from Malware Execution", "Detect Malware Execution") within each of the Top Level Cyber Threat Clusters. This combination would provide a comprehensive framework for both threat identification and risk evaluation.
The "Identify" function, enhanced with the Cyber Threat Clusters, would enable more effective management of both high-level threats and operational sub-threats, ensuring a complete and coherent control framework.
Overview
This framework integrates the 10 Top Level Cyber Threat Clusters with the NIST Cybersecurity Functions to provide a comprehensive approach to cybersecurity risk management.
Structure
Use this Scheme for each Threat Cluster:
NIST Function | Control Objective | Local Controls | Umbrella Controls |
Identify | Identify weaknesses enabling [Threat] Event | [Specific measures] | [Overarching systems/processes] |
Protect | Protect from [Threat] Event | [Specific measures] | [Overarching systems/processes] |
Detect | Detect [Threat] Event | [Specific measures] | [Overarching systems/processes] |
Respond | Respond to [Threat] Event | [Specific measures] | [Overarching systems/processes] |
Recover | Recover from [Threat] Event | [Specific measures] | [Overarching systems/processes] |
Example: #2 Exploit Server (Controls are not complete - its a POC here)
NIST Function | Control Objective | Local Controls | Umbrella Controls |
Identify | Try to identify failures in the code of your Server Software | Fuzzy Testing, Network based Vulscan | Threat Intell this topic, CVE Subscriptions, Bug Bounty Programm |
Protect | Protect Server from being exploited | Patchmanagement, Secure Coding | WAF |
Detect | Detect Exploited Server | Local Event Logging | SIEM |
Respond | Respond to exploited server | Emergency Patch, | CSIRT, Exploit Server Response Plan (Make WAF Rules) |
Recover | Recover Server Exploit Event | Maintain your Repo, Restore | IT-SCM |
Example: #4 Identity Theft (Controls are not complete - its a POC here)
NIST Function | Control Objective | Local Controls | Umbrella Controls |
Identify | Identify weaknesses in identity management (tech and org); | Password policy audits, Penetration testing | Comprehensive Identity and Access Management (IAM) assessment framework , Bug Bounty Program |
Protect | Protect Identity Protect Credentials | Multi-Factor Authentication (MFA), Secure credential distribution | Enterprise-wide Identity Governance and Administration (IGA) system |
Detect | Detect Identity Theft | Anomaly detection rules, User behavior monitoring | Security Information and Event Management (SIEM) system |
Respond | Respond to Identity Theft | Account lockout procedures, Incident response plan activation | Integrated Incident Response Platform |
Recover | Recover Identity | Identity restoration, Credential reset procedures | Enterprise-wide Business Continuity Management System |
While NIST functions provide an excellent structure for organizing controls and their objectives within each Cyber Threat Cluster, ISO standards can play a complementary role in this framework. Organizations can leverage ISO's comprehensive control sets (such as those in ISO 27002) and risk management methodologies (ISO 27005) to enhance control selection and implementation within the NIST function structure, thereby creating a more robust and internationally aligned approach to addressing each threat cluster.
This framework can be applied to all 10 Top Level Cyber Threat Clusters:
#1 Abuse of functions
#2 Exploiting Server
#3 Exploiting Client
#4 Identity Theft
#5 Man in the middle
#6 Flooding Attack
#7 Malware
#8 Physical Attack
#9 Social Engineering
#10 Supply Chain (Attack)
For each cluster, specific Control Objectives, Local Controls, and Umbrella Controls should be defined according to the unique characteristics and risks associated with that threat type.
Important Consideration for Umbrella Controls:
Umbrella Controls provide protection only for specific 'Groups of IT-Systems' within their scope. For example, a firewall or network zone can protect 'inner IT-Systems' but cannot effectively protect exposed IT-Systems. This limitation requires security architects to:
This understanding is crucial for effective control implementation and supports the framework's emphasis on attack sequences and paths.
Where are the GOV controls?
The GOVERN (GV) function in NIST CSF 2.0 operates at a strategic level, focusing on establishing the overall cybersecurity risk management framework rather than addressing specific threats directly. Unlike functions such as PROTECT or DETECT, which have controls directly linked to mitigating or identifying particular cyber threats, GOVERN controls are "assurance controls" that ensure the organization has a comprehensive approach to cybersecurity. These controls create the structure and context within which other functions operate, including setting risk appetite, defining roles and responsibilities, and establishing policies. While the threat categorization, such as the Top Level Cyber Threat Clusters, is indeed a crucial element in the risk register that GOVERN oversees, the GV controls themselves do not directly counter specific threats. Instead, they provide the strategic foundation that enables the organization to effectively manage and respond to the entire spectrum of cyber risks.
NIST NICE: You can also apply the same approach for NICE mappings.
In the context of the Top Level Cyber Threat Clusters (TLCTC), KPIs are defined as measurable values that demonstrate *the outcome and performance* of our security processes in reaching security objectives. KPIs must be time-based and should reflect not only the results but also the effectiveness over time. For instance, when tracking our response time to incidents, the KPI is the “*Average time to restore critical services to full operation within a 4-hour window*”, emphasizing the time constraint.
KCIs measure the operational performance of our security controls, verifying that the intended actions are taken at the appropriate frequency. These indicators provide insights on our ability to apply the correct controls correctly, and also highlight weaknesses in processes, helping to improve our defenses over time. We must also check the effectiveness of our tools. For example, if we have a control that requires "every critical system to be patched within 24 hours", a KCI would be "frequency of patch deployments per day" or a "scan verification of implemented patches".
KRIs focus on indicators that demonstrate the potential for a future cyber threat. They are primarily leading indicators that show the possible risks before a threat occurs. KRIs must be observed in a timeframe that is meaningful. For example, the *"Number of unpatched critical vulnerabilities older than 7 days"* can give a good indication on how our processes handle a critical vulnerability. This helps us identify, understand and prioritize our security efforts to prevent incidents.
Notation and Terminology
KxI represents the integrated framework of:
Base Level Indicators (BxIs): The lowest level of indicators that still make sense. The metrics at the operational level are directly translated into BxIs.
The KxI framework, as outlined below, provides a practical mechanism for organizations to operationalize the 10 Top Level Cyber Threat Clusters. Each Threat Cluster will have associated KRI, KCI and KPI values that help manage the cyber risk. These values can also be used as indicators for the overall performance of a cybersecurity program.
Introduction
The Secure Software Development Life Cycle (SSDLC) provides a structured approach to embedding security throughout the software development process. By integrating the 10 Top Level Cyber Threat Clusters (TLCTC) framework, organizations can establish a consistent, threat-informed methodology that bridges strategic security planning with tactical implementation. Achieving this requires careful consideration of both high-level architectural decisions (programming) and detailed, secure implementation (coding) throughout the lifecycle, guided by the TLCTC framework. This chapter outlines how the TLCTC framework integrates into each phase of the SSDLC, highlighting the differentiated roles of programmers and coders in building secure software.
Fundamental Principles
The integration relies on the core principles of the TLCTC framework:
Differentiating Roles: Coders vs. Programmers in Secure Development
While often used interchangeably, distinguishing between "coders" and "programmers" clarifies responsibilities within a secure SSDLC context:
This distinction is vital because different roles hold primary responsibility for mitigating different facets of the TLCTC threat clusters, requiring collaboration throughout the SSDLC.
Introduction
Secure coding is far more than a final checkpoint before release; it's an ongoing discipline woven into each phase of the Secure Software Development Life Cycle (SSDLC), as detailed in Chapter B. By linking coding and architectural decisions to the 10 Top Level Cyber Threat Clusters (TLCTC), development teams gain clarity on specific risks and the precise measures needed for mitigation. This "threat-to-practice" mapping transforms abstract security policies into concrete, actionable measures at both the code (Coder) and architectural (Programmer) levels.
This chapter details specific secure coding and programming practices pertinent to the TLCTC clusters most directly influenced during software development. It highlights the collaborative nature of security, where programmers establish the secure foundation and coders build upon it with secure implementation details.
Mapping TLCTC Clusters to Secure Development Practices
The following sections outline key practices for Programmers and Coders, organized by the relevant TLCTC clusters.
#1 Abuse of Functions
#2 Exploiting Server & #3 Exploiting Client
#4 Identity Theft
#5 Man in the Middle (MitM)
#7 Malware
#10 Supply Chain Attack
Application Across the SSDLC
These practices are not confined to the implementation phase. As detailed in Chapter B, programmer-level decisions informed by TLCTC occur during Requirements and Design. Coder-level implementation happens during the Implementation phase, guided by those decisions. Both roles contribute to verification during Testing and ongoing vigilance during Maintenance. Secure coding is a continuous effort, contextualized by the SSDLC process and focused by the TLCTC framework.
Conclusion
By explicitly mapping secure coding and programming practices to the Top Level Cyber Threat Clusters, organizations move beyond generic guidelines. This structured approach empowers programmers to make informed architectural decisions and enables coders to apply targeted, effective security controls during implementation. Understanding the distinct responsibilities within the context of TLCTC ensures comprehensive coverage, reduces ambiguity, and fosters a collaborative environment where security is integrated throughout the software development lifecycle, resulting in more resilient and trustworthy software.
In today's interconnected digital world, cybersecurity is a global concern. However, a critical gap exists in how different countries and organizations categorize and communicate about cyber threats. This lack of standardization hinders effective international collaboration in addressing cybersecurity challenges.
This inconsistency impedes efficient cross-border threat intelligence sharing and coordinated incident response.
The Cyber Threat Radar, based on the 10 Top Level Cyber Threat Clusters, offers a solution to this global challenge. It provides:
Cyber Threat Radars can be applied at various scales:
The following examples demonstrate how Cyber Threat Radars can be implemented at both organizational and state levels, showcasing their potential to transform global cybersecurity cooperation.
Action: Direct your SOC and Threat Intelligence teams to map incidents and near-misses to the 10 Top Level Cyber Threat Clusters. Focus on root cause analysis to identify the initial point of compromise. Implement threat radars to visualize threats specific to your organization. Ensure SOC representation in cyber strategy discussions to incorporate emerging threat trends into your risk management approach.
Count each identified threat cluster per incident. multiple count = yes
An example of a threat radar. Analyze the events (Security Incidents) regarding one or many of the cyber threat clusters - find the attack-path!
The Top Level Cyber Threat Clusters can be visualized through radar diagrams at different organizational levels. These visualizations help stakeholders understand threat distributions and impacts across their areas of responsibility.
Organizational View
The first radar represents the organization's cyber threat landscape across three key operational sectors:
"My Company"
Your own organization's environment where you have direct control over security measures:
"My Customers"
Organizations or individuals that depend on your services or products:
"My 3rd Parties"
External entities your organization depends on:
Impact and Movement Indicators
Impact Levels:
Movement Indicators:
▲ Level Up: Threat impact or frequency is increasing
▼ Level Down: Threat impact or frequency is decreasing
State Level View
The second radar expands the perspective to critical infrastructure and societal sectors, demonstrating how the same threat clusters manifest at a national level:
An example of a state level cyber threat radar.
This state-level view enables:
Note: Both radar views demonstrate that all 10 Top Level Cyber Threat Clusters apply universally, regardless of sector or organizational context. The key differences lie in impact levels, frequency, and specific manifestations within each domain.
See how the 10 Top Level Cyber Threat Clusters (TLCTC) framework enables enhanced comparison of threat actors, including APTs. Based on CrowdStrike's 2024 Threat Hunting Report[1], this interactive visualization reveals capability patterns across different adversary groups.
Capability ratings: 1 (Low), 2 (Medium), 3 (High). Based on observed activities and intelligence analysis through the TLCTC framework.
Each radar chart maps an APT group's proficiency across all ten clusters: Abuse of Functions, Exploiting Server, Exploiting Client, Identity Theft, Man in the Middle, Flooding Attack, Malware, Physical Attack, Social Engineering, and Supply Chain Attack. This cluster-based analysis enables better understanding of adversary capabilities and helps bridge the gap between strategic risk management and operational security.
By comparing APT groups through the TLCTC lens, we can better understand their distinct capabilities, preferred tactics, and potential attack sequences. This insight supports more effective threat intelligence sharing and targeted defense strategies.
The cybersecurity landscape faces a critical challenge: fragmented threat intelligence that fails to effectively connect strategic risk management with operational security execution. While frameworks like MITRE ATT&CK and STIX enable detailed threat intelligence sharing, they lack a standardized high-level threat categorization system that aligns threat intelligence with risk management and security operations.
MITRE needs to focus on mapping technical techniques to strategic clusters, while STIX needs to enhance its data model to represent these clusters and their relationships in threat intelligence sharing.
The Top Level Cyber Threat Clusters framework addresses this gap by providing a comprehensive solution that bridges threat intelligence with practical security implementation.
By integrating this framework with established standards like MITRE ATT&CK and STIX, organizations can transform raw threat intelligence into actionable insights that drive both strategic risk decisions and tactical security operations. This integration enables:
Current State: STIX provides a rich set of objects and relationships for describing cyber threat information, but it has limitations:
STIX Component | Purpose | Limitation |
Objects (e.g., Threat Actor, Attack Pattern, Malware) | Describe individual elements of cyber threats | Lacks a standardized high-level categorization system |
Relationships | Connect different STIX objects to represent complex scenarios | No standardized way to represent attack sequences or paths |
Intrusion Set | Represent adversary behaviors and resources | Focuses on actor behaviors rather than threat categories or attack progressions |
Proposed Enhancements:
Implementation Approach:
Create a New STIX Domain Object:
Threat Cluster Object Structure:
{
"type": "x-threat-cluster",
"spec_version": "2.1",
"id": "x-threat-cluster--uuid",
"created": "2024-01-29T18:20:00.000Z",
"modified": "2024-01-29T18:20:00.000Z",
"name": "Abuse of Functions",
"cluster_id": "TC0001",
"definition": "Abuse of Functions involves manipulating the intended functionality of software or systems for malicious purposes",
"generic_vulnerability": "The scope of software and functions",
"asset_type": "Software",
"attacker_vector": "Abuse of functionality, not a coding issue"
}
Attack Sequence Object:
{
"type": "x-attack-sequence",
"spec_version": "2.1",
"id": "x-attack-sequence--uuid",
"created": "2024-01-29T18:20:00.000Z",
"modified": "2024-01-29T18:20:00.000Z",
"sequence_id": "SEQ001",
"initial_cluster": "x-threat-cluster--uuid1",
"subsequent_clusters": [
"x-threat-cluster--uuid2",
"x-threat-cluster--uuid3"
],
"common_pattern_name": "Phishing to Malware Chain",
"observed_frequency": "high",
"first_observed": "2024-01-01T00:00:00Z",
"last_observed": "2024-01-29T00:00:00Z",
"count": 157
}
Enhanced Attack Pattern Object:
{
"type": "attack-pattern",
"spec_version": "2.1",
"id": "attack-pattern--uuid",
"created": "2024-01-29T18:20:00.000Z",
"modified": "2024-01-29T18:20:00.000Z",
"name": "Spearphishing Attachment",
"description": "Adversaries may send spearphishing emails with malicious attachments",
"kill_chain_phases": [{
"kill_chain_name": "mitre-attack",
"phase_name": "initial-access"
}],
"x_tlctc": {
"primary_threat_cluster": "x-threat-cluster--uuid9",
"secondary_threat_clusters": [
"x-threat-cluster--uuid3",
"x-threat-cluster--uuid7"
],
"generic_vulnerability_exploitation": "Exploits human susceptibility to deception",
"attack_sequence_position": {
"can_be_initial": true,
"can_be_subsequent": false,
"typical_sequence": "#9->#3->#7"
}
}
}
Benefits of Integration:
Current State: MITRE ATT&CK excels at the operational security level, providing detailed tactics and techniques for various attack stages across different IT system types. However, it lacks a high-level strategic framework for threat categorization and overemphasizes post-compromise techniques.
Framework | Current Limitations | Integration Need |
MITRE ATT&CK |
| Map techniques to strategic threat clusters |
STIX |
| Enhance with structured threat taxonomy |
Proposed Enhancements:
Implementation Approach:
Enhanced STIX Objects:
STIX Threat Cluster Object:
{
"type": "x-threat-cluster",
"spec_version": "2.1",
"id": "x-threat-cluster--f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
"created": "2024-01-29T18:20:00.000Z",
"modified": "2024-01-29T18:20:00.000Z",
"name": "Abuse of Functions",
"cluster_id": "TC0001",
"definition": "Abuse of Functions involves manipulating the intended functionality of software or systems for malicious purposes",
"generic_vulnerability": "The scope of software and functions",
"asset_type": "Software",
"attacker_vector": "Abuse of functionality, not a coding issue",
"mitre_techniques": ["T1548", "T1559", "T1569"]
}
STIX Attack Sequence Object:
{
"type": "x-attack-sequence",
"spec_version": "2.1",
"id": "x-attack-sequence--d81d4fae-7dec-11d0-a765-00a0c91e6bf6",
"created": "2024-01-29T18:20:00.000Z",
"modified": "2024-01-29T18:20:00.000Z",
"sequence_id": "SEQ001",
"initial_cluster": "x-threat-cluster--f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
"subsequent_clusters": [
"x-threat-cluster--a81d4fae-7dec-11d0-a765-00a0c91e6bf6",
"x-threat-cluster--b81d4fae-7dec-11d0-a765-00a0c91e6bf6"
],
"mitre_techniques": ["T1566", "T1190", "T1105"],
"common_pattern_name": "Phishing to Malware Chain",
"observed_frequency": "high",
"first_observed": "2024-01-01T00:00:00Z",
"last_observed": "2024-01-29T00:00:00Z",
"count": 157
}
Enhanced MITRE ATT&CK Pattern:
{
"type": "attack-pattern",
"spec_version": "2.1",
"id": "attack-pattern--c81d4fae-7dec-11d0-a765-00a0c91e6bf6",
"created": "2024-01-29T18:20:00.000Z",
"modified": "2024-01-29T18:20:00.000Z",
"name": "Spearphishing Attachment",
"description": "Adversaries may send spearphishing emails with malicious attachments",
"kill_chain_phases": [{
"kill_chain_name": "mitre-attack",
"phase_name": "initial-access"
}],
"x_tlctc": {
"primary_threat_cluster": "x-threat-cluster--f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
"secondary_threat_clusters": [
"x-threat-cluster--a81d4fae-7dec-11d0-a765-00a0c91e6bf6",
"x-threat-cluster--b81d4fae-7dec-11d0-a765-00a0c91e6bf6"
],
"generic_vulnerability_exploitation": "Exploits human susceptibility to deception",
"attack_sequence_position": {
"can_be_initial": true,
"can_be_subsequent": false,
"typical_sequence": "#9->#3->#7"
}
}
}
References: MITRE ATT&CK Framework, Enterprise Matrix, 2024 and OASIS STIX Version 2.1 Specification, 2024
Benefits of Integration:
Conclusion
Integrating the Top Level Cyber Threat Clusters into the STIX and MITRE ATT&CK frameworks offers significant benefits, including standardized threat categorization, attack path representation, and enhanced strategic threat analysis. By adopting this approach, organizations can better bridge the gap between technical threat data and high-level risk management, leading to more effective cybersecurity strategies and improved communication across all levels of the organization. This integration maintains the granularity and detail of STIX and MITRE ATT&CK while adding an essential layer of high-level structure, ultimately contributing to a more resilient cyber defense posture.
Based on the Amnesty International report[2], the NSO Group's Pegasus spyware attack paths can be categorized into several main vectors. These attack paths demonstrate the sophisticated and evolving nature of the Pegasus spyware, utilizing various threat clusters in sequence to compromise target devices:
Example | Description |
Campaign 1: | The most common and effective path. Begins with a malicious SMS or iMessage, leading the target to click a link that infects the device with malware. Seen in attacks against Maati Monjib (2019) and many others. |
Campaign 2: | Uses network injection attack (MitM) to redirect the user to a compromised website, which then delivers malware. Used against Omar Radi (2019), redirecting to a fake Yahoo page and then to a malware-delivering domain. |
Campaign 3: | A successful exploit (e.g., zero-day in Apple Photos app) leaves the device vulnerable to a second, more direct malware infection. Seen with French journalist (CODE FRJRN1) in May 2020. |
Campaign 4: | This path, seen with the French journalist (CODE FRJRN1) in 2020, starts with network injection (#1 and #5), which then leads to the delivery of a malicious webpage. The user interacting with the webpage triggers the Client Exploit (#3), resulting in the installation of malware (#7). |
Campaign 5: | Simplest path, used in Apple Music exploits starting in 2020. Leverages a vulnerability in the Apple Music app to directly deliver malware. |
Campaign 6: | Demonstrated with Rwandan activist (CODE RWHRD1) in May and June 2021. Target received multiple iMessage attachments containing malicious code leading to malware installation. |
Campaign 7: | Used against Indian journalist (CODE INJRN1) in June 2021. iMessage notifications were the attack vector, ultimately infecting the phone with malware. |
These attack paths illustrate the complex and multi-staged nature of Pegasus spyware attacks. They demonstrate how different threat clusters are chained together to bypass security measures and compromise target devices. It's important to note that these represent the most common paths identified in the report, and NSO Group continually develops new methods as security measures evolve.
Based on the attack scenario described, we can summarize the attack path using the 10 Top Level Cyber Threat Clusters as follows: (names are fictive)
Here's the breakdown:
1. #9 (Social Engineering): The attack begins with a phishing email sent to Karin Meier, impersonating her colleague Rolf Schulz.
2. #7 (Malware): Karin opens the malicious Word document attached to the email and enables macros, executing the embedded malware code (Emotet).
3. #7 (Malware): Emotet operates on the infected PC, stealing emails and downloading additional malware (Trickbot). Trickbot steals domain administrator credentials
4. #4 (Identity Theft): Use of domain administrator credentials allowing for further network compromise.
5. (#1 + #7) (Abuse of Functions + Malware): Simultaneously, the attackers use the stolen admin credentials to spread Trickbot throughout the network, compromising the Active Directory (Abuse of Functions), while deploying the Ryuk ransomware across the network (Malware), encrypting data on servers and backup systems.
This refined attack path demonstrates the sophisticated and multi-staged nature of modern cyber attacks, highlighting how threat actors can leverage multiple threat clusters simultaneously in the final stages to rapidly achieve widespread compromise and data encryption. The parallel execution of Abuse of Functions and Malware deployment in the last step underscores the complex and interconnected nature of advanced cyber attacks.
Cobalt Strike, as a comprehensive post-exploitation framework, embodies functionalities that span across all 10 Top Level Cyber Threat Clusters. It serves as a prolonged arm of the attacker, providing capabilities that can be leveraged at various stages of an attack.
Mapping to Threat Clusters
Abuse of Functions (#1):
Exploiting Server (#2):
Exploiting Client (#3):
Identity Theft (#4):
Man in the Middle (#5):
Flooding Attack (#6):
Malware (#7):
Physical Attack (#8):
Social Engineering (#9):
Supply Chain (#10):
Enabling Attack Paths
Cobalt Strike's diverse functionality allows attackers to construct various attack paths, chaining multiple threat clusters. The specific path followed depends on the attacker's script or campaign. For example:
Path 1: #9 (Phishing email) -> #3 (Client-side exploit) -> #7 (Beacon deployment) -> #1 (OS-level process injection) -> #4 (Credential theft)
Path 2: #10 (Update server compromise) -> #7 (Malicious update deployment) -> #5 (Network traffic interception) -> #2 (Server exploitation)
Path 3: #8 (USB payload delivery) -> #7 (Beacon execution) -> #1 (Windows DLL search order abuse) -> #6 (Coordinated flooding)
Conclusion
This analysis demonstrates how the 10 Top Level Cyber Threat Clusters framework effectively categorizes the multifaceted capabilities of a complex tool like Cobalt Strike. By carefully distinguishing between abuse of legitimate functionality (#1) and exploitation of vulnerabilities (#2), the framework provides clear guidance for threat modeling and control implementation. Understanding these distinctions and potential attack paths is crucial for developing effective defense strategies and risk assessments.
Purpose
This framework is intentionally simple at the top level—ten mutually exclusive threat clusters—so that mapping is consistent, auditable, and operational. Simplicity here is not "simplism": each cluster is defined by what action occurs in the causal path to loss of control (system compromise). The model is minimal by design, but not reductive. This simplicity at the strategic level enables precision at the operational level.
Design Principles That Prevent Oversimplification
Mutual Exclusivity by Construction
A concrete action maps to one—and only one—cluster when the action is precisely described, based on the generic vulnerability being exploited.
Causal Sequencing
Mapping follows the attack path. Each step in an attack sequence maps to its appropriate cluster, creating chains like #9→#4→#7 that represent real-world attack progressions.
Action Over Actor or Motive
Clusters classify what was done (the exploit of a generic vulnerability), not who did it or why. Actor type, intent, and capability are captured in separate dimensions (threat intelligence, risk context), keeping the taxonomy stable.
Operational Testability
Each mapping rule is falsifiable: provide a precisely described action that matches two clusters simultaneously, and either the action description needs refinement or the framework has identified an edge case requiring clarification.
What This Framework Deliberately Does Not Encode
This separation avoids category creep and preserves the clarity of the core mapping.
Edge-Case Resolution (Worked Examples)
Session cookie intercepted over open Wi-Fi, then reused:
Phishing email leading to credential theft:
Keylogger-based credential theft:
Credential extraction via lsass dump:
Drive-by download exploiting browser vulnerability:
LOLBAS execution after initial compromise:
Note: The invocation mechanism (abusing cmd.exe, Task Scheduler, WMI, etc.) is #1, while the actual script/code execution by PowerShell, PsExec, or other dual-use tools is #7. LOLBAS involves both clusters in sequence.
Compromised software update:
MFA Bombing attack:
Verification Checklist (Comprehensive)
If two clusters seem to apply to the same atomic action, refine the action description until only one applies. If ambiguity persists after refinement, document as a candidate edge case for framework review.
Limitations and When to Refine
Industry Term Decomposition
The framework's precision requirement reveals that many common security terms are actually imprecise conflations of multiple distinct steps:
"OAuth Attack" - A Conflation Requiring Decomposition
The term "OAuth attack" demonstrates imprecise language. The framework requires identifying the specific mechanism:
“RCE" - Always a Multi-Step Sequence
CVEs describing "Remote Code Execution" conflate the vulnerability with its exploitation:
**Key Insight**: The framework isn't creating ambiguity—it's exposing the security industry's imprecise terminology. This precision is not oversimplification but rather necessary rigor for effective threat modeling and control implementation.
Summary
The framework achieves strategic simplicity through ten mutually exclusive clusters while enabling operational precision through:
This is not oversimplification but rather strategic abstraction: complexity emerges from the combinations and sequences of simple, well-defined elements. The framework's strength lies not in exhaustive categorization but in providing a stable, logical foundation for understanding how attacks actually unfold—from initial vulnerability exploitation through to system compromise.
Precision comes from the rules and their consistent application, not from adding more categories.
[1] https://go.crowdstrike.com/2024-threat-hunting-report-thank-you.html
[2] https://www.barnes.ch/Forensic_Methodology_Report_NSO_Groups_Pegasus_Amnesty_International.pdf
