The NIST Cybersecurity Framework (CSF) 2.0 claims to provide "guidance to industry, government agencies, and other organizations to manage cybersecurity risks." However, an analysis of the framework and its supporting documents reveals several significant gaps in how it addresses cyber threats specifically.
NIST's general threat definition from SP 800-30 states that a threat is:
"Any circumstance or event with the potential to adversely impact organizational operations and assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service."
While this definition mentions information systems, it does not distinguish cyber threats as a distinct category nor does it provide a cyber threat categorization framework.
The framework's threat categorization, as outlined in SP 800-30 Table D-2, provides four broad categories: Adversarial, Accidental, Structural, and Environmental. These categories encompass all types of threats without specifically delineating cyber threats from other security threats.
For risk assessment, NIST SP 800-30 states that:
"Risk assessments are used to identify, estimate, and prioritize risk to organizational operations (i.e., mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation and use of information systems."
This risk-based approach is further supported by the CSF Core structure, which organizes outcomes into Functions (GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER) rather than specific cyber threat types.
Critical Limitations
The analysis reveals several critical limitations in the framework:
- Lacks a specific cyber threat definition
- Does not provide a cyber-specific threat categorization
- Does not provide threat-specific control mappings
- Takes a general risk-based rather than cyber-threat-specific approach
What makes this particularly interesting is that the framework still requires organizations to "identify threats" and then "apply controls" without providing specific guidance on what constitutes a cyber threat or which controls map to specific cyber threats. Funny isn't it?
This disconnect between the framework's stated cybersecurity focus and its actual content raises questions about its effectiveness in specifically addressing cyber threats versus general security risks.
A Path Forward: Embracing Structured Threat Categorization
As the cybersecurity community continues to evolve, it's crucial that our frameworks evolve with us. The adoption of a comprehensive threat taxonomy within the NIST CSF could significantly enhance its practical utility in cyber risk management.
Instead of bashing I propose the Top Level Cyber Threat Clusters (TLCTC). This framework offers a structured, consistent method for categorizing threats that bridges the gap between high-level strategy and operational security.
The TLCTC approach addresses many of the shortcomings in the NIST definition by:
- Providing clear, distinct categories for different types of threats
- Separating threats from vulnerabilities and impacts
- Offering a logical hierarchy that can link high-level risks to specific technical controls
The Benefits of a Clear Threat Taxonomy
Integrating a structured threat taxonomy like TLCTC into the NIST CSF could offer several key benefits:
- Consistency: A standardized taxonomy ensures that all parts of an organization are speaking the same language when it comes to threats.
- Completeness: A well-designed taxonomy helps ensure that no significant threat categories are overlooked.
- Clarity: Clear categories make it easier to communicate about threats both within an organization and with external stakeholders.
- Actionability: A structured approach to threats makes it easier to link threat categories directly to specific controls and mitigation strategies.
- Scalability: A good taxonomy can be applied consistently across different scales, from individual systems to entire enterprises.
Integration Framework
Generic NIST Functions Framework
For each Threat Cluster, apply this structured approach:
| NIST Function | Control Objective | Local Controls | Umbrella Controls |
|---|---|---|---|
| GOVERN | Govern the strategy, ownership and risk appetite for [Threat] Cluster | Cluster owner assignment, cluster-specific policy statement | ISMS / RMF integration, board-level risk appetite, KRI/KPI per cluster |
| IDENTIFY | Identify weaknesses enabling [Threat] Event | Specific measures targeting the threat | Overarching detection systems |
| PROTECT | Protect from [Threat] Event | Direct protection measures | Enterprise-wide protection systems |
| DETECT | Detect [Threat] Event | Local detection mechanisms | Security monitoring systems |
| RESPOND | Respond to [Threat] Event | Immediate response actions | Incident response platforms |
| RECOVER | Recover from [Threat] Event | Local recovery procedures | Business continuity systems |
Example: Exploiting Server (#2)
| NIST Function | Control Objective | Local Controls | Umbrella Controls |
|---|---|---|---|
| GOVERN | Govern strategy and ownership for Server Exploitation risk | AppSec/Server-Owner accountability, Secure SDLC policy, patch SLA standard | Risk register entry for #2 with appetite/tolerance, vulnerability management program (ISMS clause) |
| IDENTIFY | Try to identify failures in the code of your Server Software | Fuzzy Testing, Network based Vulscan | Threat Intelligence, CVE Subscriptions |
| PROTECT | Protect Server from being exploited | Patch Management, Secure Coding | Web Application Firewall (WAF) |
| DETECT | Detect Exploited Server | Local Event Logging | Security Information and Event Management (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 Service Continuity Management (IT-SCM) |
Integration with International Standards
While NIST functions provide an excellent structure for organizing controls and their objectives within each Top Level 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.
Application
This framework can be applied to all 10 Top Level Cyber Threat Clusters:
- Abuse of functions
- Exploiting Server
- Exploiting Client
- Identity Theft
- Man in the middle
- Flooding Attack
- Malware
- Physical Attack
- Social Engineering
- 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.
| CLUSTER | GOVERN | IDENTIFY | PROTECT | DETECT | RESPOND | RECOVER |
|---|---|---|---|---|---|---|
| #1 Abuse of functions | Feature/abuse-case review policy Business-logic risk acceptance |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
| #2 Exploiting Server | Secure SDLC policy, patch SLA Vulnerability management program |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
| #3 Exploiting Client | Endpoint hardening standard Browser/email client governance |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
| #4 Identity Theft | IAM policy, MFA mandate IAM governance committee, IGA program |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
| #5 Man in the middle | Cryptographic standard, TLS policy PKI / key-management governance |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
| #6 Flooding Attack | Service-availability tolerance DDoS protection program, capacity governance |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
| #7 Malware | Anti-malware/EDR policy, FEC handling rules Enterprise malware-defense program |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
| #8 Physical Attack | Site/asset access policy Physical security program, facilities governance |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
| #9 Social Engineering | Acceptable-use & awareness policy Security awareness program governance |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
| #10 Supply Chain (Attack) | Vendor/onboarding policy, SBOM mandate Third-party risk management (TPRM) program |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
Umbrella Controls Local Controls |
GOVERN: The Management-System Layer
GOVERN is the speciality function in NIST CSF 2.0 — and once you fill the matrix with per-cluster GOV entries, its distinct nature becomes obvious. The other five functions (IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER) are tactical-operational: they act on the threat itself. GOVERN is strategic-integrative: it is the hook that connects each Top Level Cyber Threat Cluster into the organization's broader management system.
Concretely, GOVERN per cluster is where TLCTC plugs into:
- An ISMS (ISO/IEC 27001): Clauses 4–10 — context of the organization, leadership, planning, support, operation, performance evaluation, improvement. Each cluster carries policy statements, ownership, risk acceptance, KRI/KPI, and management-review inputs that live inside these clauses.
- The NIST RMF (SP 800-37 / 800-39): Organizational risk frame, risk tolerance, control ownership, and the link from cluster-level risk into the enterprise risk register.
The per-cluster GOV cells in the matrix above (cluster owner, cluster-specific policy, risk appetite/tolerance, program-level governance) are not redundant with the tactical functions — they are the steering layer that decides which Local and Umbrella controls in the other five columns get prioritized, funded, and reviewed for each cluster. Without GOVERN, the matrix is a control catalogue; with GOVERN, it becomes a managed system.
Put differently: PROTECT-#2 patches the server. GOVERN-#2 is the policy that says servers must be patched within X days, names the owner accountable when they aren't, and feeds residual #2 risk back to the board. Both belong to cluster #2 — they operate at different altitudes.
Conclusion: Time for Evolution
As we continue to face increasingly sophisticated cyber threats, it's time for our foundational frameworks to adapt. The NIST CSF has served us well, but its approach to threat identification and categorization is due for an upgrade.
By incorporating a structured threat taxonomy, the NIST CSF could provide organizations with a clearer path from threat identification to control implementation, ultimately leading to more robust and effective cybersecurity strategies.
Try the TLCTC × NIST CSF Control Matrix
The companion interactive tool maps each TLCTC cluster against NIST CSF Functions and Categories — so you can see, cluster by cluster, where preventive, detective, and responsive controls actually sit. Use it to turn the integration argument in this article into a working control inventory.
Open Control MatrixReferences
- National Institute of Standards and Technology, "Framework for Improving Critical Infrastructure Cybersecurity, Version 2.0," 2024.
- B. Kreinz, "Top Level Cyber Threat Clusters," Barnes Projects White Paper, September 2024.
- NIST Special Publication 800-30, "Guide for Conducting Risk Assessments"