Tailored Coding
The initial draft of NIST SP 800-154 describes data-centric threat modeling as a form of risk assessment focused on the attack and defense aspects of selected data. The methodology characterizes the system and data, selects attack vectors, identifies controls, and analyzes the model. Because the publication is not yet final and covers a specific approach, it serves here as a methodological reference, not a universal definition or a completed standard.
This change in perspective matters because not every incident begins with the selection of an individual victim. CISA warns that misconfigurations, default credentials, and outdated software can leave systems publicly exposed and easy to exploit. The practical inference is limited: in some attacks, exposure may be discovered before anyone knows who is behind it. This does not mean that all people or businesses face the same risk.
The value someone else may see
When building the model, do not limit possible interest to fame or visible wealth. One account may provide access to other accounts. An internal document may reveal clients, suppliers, prices, or decisions. A calendar may reveal relationships and routines. Metadata may indicate who communicates with whom, when, from where, and how often.
Data may also have value as a means to an end. Compromised credentials may enable access, depending on the other controls in place; personal information may support fraud or social engineering; operational files may support extortion; access to contacts may extend the reach of an attempted scam.
These possibilities do not prove that an attack will happen. They help identify why particular information, accounts, or relationships deserve protection even when the person responsible for them does not consider themselves a target.
Legitimate access also belongs in the model
A threat model should map more than criminals. It needs to record the entities with authorized access: internal administrators, cloud providers, support operators, subcontractors, identity services, integrations, and tools that analyze content or telemetry.
Security and privacy overlap. Both address the risks of improper access; security also protects integrity and availability and considers error, abuse of privilege, and compromise. Privacy adds another question: even when processing works as designed, does it have a purpose and legal basis, meet the requirements of necessity and transparency, and protect the applicable rights? The NIST Privacy Framework 1.0 makes this overlap explicit; in Brazil, the legal criteria depend on the LGPD and the specific circumstances.
Content and metadata should be recorded separately. A service may protect a file while still recording its name, size, timestamp, IP address, device, participants, or activity history. This information may constitute personal data when it identifies or can be associated with a person, especially in combination.
Five questions for building the first model
- Which data, metadata, accounts, and relationships need protection at rest, in transit, and in use, and what harm would result from exposure, alteration, unavailability, or use beyond the intended purpose?
- What are the system boundaries, flows, inputs, outputs, and trust assumptions between people, devices, services, and suppliers?
- Which entities currently have access to content or metadata, with what responsibilities, and where could privilege abuse, errors or integrations increase exposure?
- Through which vectors could access or harm occur, and which controls prevent, detect, limit, and enable recovery from each scenario?
- Who accepts the residual risk, which trade-offs between protection, cost, usability, and performance have been accepted, and how are data, keys, and access removed when the relationship ends?
The answers should prioritize plausible scenarios by impact and exposure, not fear. Password reuse and the absence of phishing-resistant authentication in the access path are two conditions that may require action before a sophisticated scenario that depends on several unlikely conditions.
The first result is an initial assessment, not a guarantee
The first cycle should produce a concise map: boundaries, relevant data and metadata, entities with access, vectors, existing controls, gaps, trust assumptions, responsible parties, and residual risks. It should also distinguish what was observed, what is a contractual promise, and what remains unknown.
This map guides prioritization. It does not replace technical testing, legal assessment, incident response, or ongoing review. The model needs to be updated when tools, suppliers, data, flows, or authorized people change.
How we work
We begin with the data, metadata, flows, and relationships that sustain the operation. We map entities with legitimate access, exposure paths, and trust assumptions; test controls and evidence; and distinguish observed access, contractual authority, and possibilities that remain unknown. The deliverable is a prioritized model with scenarios, controls, residual risk, responsible parties, and decisions to reduce or accept risk or investigate further.
Which exposures could interrupt your operation or compromise client information? The answer helps prioritize security investment by business impact.