Structured Approaches on tplat

Focusing on Assets

Mon, 01 Jan 0001 00:00:00 +0000

Focusing on Assets

An asset-focused approach to threat modeling-centering on “things of value" seems intuitive but is often less effective than expected.

Method

identify assets;
map them to systems;
model interactions;
analyse threats.

Limitations

Definition ambiguity: “Assets” can mean three overlapping things:

Things attackers want (e.g., passwords, financial data)
Things you want to protect (often intangible, like reputation)
Stepping stones to other assets (e.g., systems that provide access)

venn-beta
  title "The overlapping definitions of assets"
  set A["Things you protect"]
  set B["Stepping stones"]
  set C["Things attackers want"]
  union A,B,C
  union A,B
  union B,C
  union A,C

Teams often lack a shared definition, leading to confusion or unproductive discussions.

Focusing on Attackers

Mon, 01 Jan 0001 00:00:00 +0000

Focusing on Attackers

An attacker-focused approach to threat modeling—starting from “who might attack us and why”-is intuitive but generally not very effective.

Method

Create attacker profiles (from simple lists to detailed personas).
Use these to guide brainstorming about possible attacks.
Often shifts toward human-centric scenarios (e.g., social engineering).

Appeal and use cases:

It feels logical: if attackers drive risk, understanding them should help.
It can work for experienced security practitioners, for incorporating less-technical input, and for communicating risk or prioritisation.
Makes threats more tangible, especially for non-technical stakeholders.
Useful for explaining who might attack and why, aiding communication and buy-in.

Limitations

Discussions easily get bogged down in debating attacker capabilities (e.g., “state-sponsored or not?”).
Personas lack enough structure to reliably derive concrete threats.
Engineers may project their own assumptions onto attackers, leading to bias and missed risks.
Human-centric scenarios can be hard to translate into actionable system security measures.

Attacker-centric modelling does not produce consistent or systematic threat identification. It does not reliably answer the key question: what will attackers actually do to the system?

Focusing on Software

Mon, 01 Jan 0001 00:00:00 +0000

Focusing on Software

Shostack argues software-centric threat modelling (focusing on the system’s actual architecture and behavior) is more effective and practical than asset or attacker-centric modelling.

Method

Model the software itself (architecture, data flows, components, APIs).
Use diagrams or shared representations to build a common understanding of how the system works.

Advantages

Shared understanding: Exposes mismatches in how team members think the system behaves, often revealing security gaps.
Handles complexity: Helps untangle and make visible the accumulated complexity of long-running or large systems.
Surfaces assumptions: Forces explicit identification of hidden or incorrect assumptions between components.
Immediate security value: Even before identifying threats, aligning understanding improves security posture.
Works across different types of software:
- “Boxed” software (clearly defined boundaries like apps or packages)
- Deployed systems (evolving infrastructure and services)
Developers are familiar with their own software. This is reliable, unlike assumptions about assets or attackers.
Doesn’t rely on vague or inconsistent concepts (like “assets” or “attacker personas”).
Provides a concrete, structured foundation for systematically identifying threats.

Takeaway

Software-centric modeling works because it starts from something concrete, shared, and well-understood: the system itself. This makes it more reliable, reproducible, and effective for identifying and addressing threats than asset or attacker-focused approaches.