NIST Cybersecurity Framework, MITRE ATT&CK, and a data-centric security product such as Seclore are sometimes discussed as competing answers. They are different layers.
NIST CSF describes risk-management outcomes for an organisation. MITRE ATT&CK organises observed adversary behaviour. A data-centric security platform applies and enforces controls to sensitive information. None replaces the other, and buying a product does not mean a framework has been implemented.
What “Framework” Means in Security
A framework is a structured way to organise a problem, establish common language, and make decisions repeatable. It can define outcomes, categories, relationships, evidence, and improvement cycles without prescribing one vendor or command.
That is different from:
- a standard containing mandatory requirements;
- a compliance regulation backed by law;
- a knowledge base of observed behaviour;
- a product that enforces a technical control;
- a procedure such as testing a port or reviewing a log.
Confusing these layers creates false assurance. A vulnerability scanner can produce findings but cannot decide the organisation’s risk tolerance. A matrix can describe attacker behaviour but cannot classify the company’s contracts. A policy can require document protection but cannot enforce revocation by itself.
NIST CSF 2.0: The Risk-Management Layer
NIST released CSF 2.0 for organisations of all sizes and sectors. Its Core organises cybersecurity outcomes under six concurrent Functions:
- Govern
- Identify
- Protect
- Detect
- Respond
- Recover
The added Govern Function makes strategy, roles, policy, legal obligations, supply-chain risk, and risk tolerance visible rather than burying them inside technical work. NIST’s official CSF 2.0 announcement and CSF FAQ stress that the Core describes outcomes, not one implementation process.
Use CSF to answer questions such as:
- Which business services and data are critical?
- Who accepts cybersecurity risk?
- What protection and detection outcomes are required?
- How will incidents be communicated and contained?
- Which recovery objectives must be tested?
- How will suppliers and exceptions be governed?
A CSF Profile can compare current and target outcomes. It does not award a universal “CSF compliant” certificate and should not become a checklist where every subcategory receives the same priority.
MITRE ATT&CK: The Adversary-Behaviour Layer
MITRE describes ATT&CK as a globally accessible knowledge base of adversary tactics and techniques based on real-world observations. Tactics represent why an adversary acts; techniques and sub-techniques describe how a tactical goal may be achieved. The official ATT&CK resources also warn users not to chase 100 percent matrix coverage.
Use ATT&CK to:
- structure threat intelligence;
- model likely attack paths;
- map telemetry and detection logic;
- design purple-team exercises;
- identify gaps in defensive visibility;
- describe incidents in a common language.
ATT&CK is strongest after scope and priorities are known. A hospital, manufacturer, hosting provider, and design agency face different adversaries and impact. Colouring every cell green does not prove that alerts are reliable, analysts can investigate them, or recovery works.
ATT&CK is also not a vulnerability catalogue. A missing patch is a weakness; the adversary technique describes behaviour that may exploit a weakness or abuse legitimate functionality.
Data-Centric Security: The Enforcement Layer
Traditional perimeter and endpoint controls protect locations and devices. Data-centric controls travel closer to the information: classification, encryption, identity-aware access, usage restrictions, revocation, and activity tracking.
Seclore describes its data-centric security platform as an integration of data discovery, classification, rights management, and usage tracking, with connectors to systems such as DLP, content repositories, email, and SIEM. That is a vendor description, not independent proof that the product fits every environment.
Evaluate any rights-management product against concrete requirements:
- supported file formats, applications, browsers, and mobile platforms;
- offline access and expiry behaviour;
- identity federation and guest collaboration;
- printing, copy/paste, screen-capture, and download controls;
- key ownership, availability, disaster recovery, and vendor exit;
- audit export and SIEM integration;
- user experience when a partner is outside the tenant;
- data residency, privacy, and legal discovery;
- behaviour after the subscription or policy service is unavailable.
“The file stays protected after sharing” is useful only when authorised recipients can still work and the organisation can recover encrypted data during an outage.
How the Three Layers Fit Together
Consider confidential engineering documents shared with a supplier.
| Layer | Question | Example output |
|---|---|---|
| NIST CSF | What outcome and ownership are required? | Sensitive data is identified, protected according to risk, monitored, and recoverable; supplier obligations and exceptions have owners |
| MITRE ATT&CK | How might an adversary obtain or exfiltrate it? | Prioritised techniques involving valid accounts, collection from repositories, archive staging, email, cloud services, or alternative protocols |
| Data-centric controls | What enforces policy on the document? | Classification triggers encryption and recipient rights; access can expire or be revoked; usage events feed monitoring |
| Operational procedures | How do we prove it works? | Test cases, alert review, access-revocation drill, recovery test, and evidence retained for audit |
Start with the CSF target outcome. Use threat modelling and ATT&CK to select relevant behaviours, not the entire matrix. Then choose identity, DLP, rights management, endpoint, email, backup, and monitoring controls that address the prioritised paths. Finish with tests that produce evidence.
Do Not Turn Product Events into Detection by Default
A rights-management platform may log authorised opens, denied access, exports, or policy changes. Sending every event to a SIEM is not a detection strategy. Define:
- which event indicates risk rather than normal collaboration;
- required context such as user, device, document class, geography, and time;
- suppression and threshold logic;
- an owner and response runbook;
- retention and privacy limits;
- a test that demonstrates the alert fires.
Map a detection to ATT&CK only when the telemetry actually observes the relevant behaviour. A product being capable of logging access is not evidence that it detects exfiltration.
A Port Test Is a Procedure, Not a Framework
From Windows, an administrator can test whether a specific TCP connection succeeds:
Test-NetConnection example.net -Port 443 -InformationLevel Detailed
This confirms whether that client can complete a TCP connection at that moment. It does not prove that a remote port is universally open, that the service is safe, or that a firewall meets policy. The result can support an investigation or control test, but it belongs inside a defined process.
Only test systems you own or are authorised to assess. Broad scanning can trigger monitoring and may violate policy or law.
Build a Small, Traceable Crosswalk
For each critical data flow, document:
- business owner, data class, and impact;
- selected CSF current and target outcomes;
- relevant adversary behaviours and assumptions;
- preventive, detective, response, and recovery controls;
- product configuration and dependency owners;
- evidence source and test frequency;
- accepted gaps and expiry date for exceptions.
This crosswalk is more valuable than a large spreadsheet of unverified mappings. It shows why a control exists, what it protects, what evidence supports it, and who must act when it fails.
The practical division is simple: NIST CSF directs the programme, MITRE ATT&CK informs threat-focused analysis and detection, and data-centric products enforce selected protections. Security improves when those layers are connected by ownership and tested evidence—not when their names are placed next to one another in a slide.
