The asset is dead! Long live the asset!

The threat modelling technique of using assets to find attacks is something of a zombie. But assets are still indispensable, just not for this purpose.

Introduction

Asset‑based (or asset‑centric) threat modelling treats assets as first‑class model objects. The premise is attractive and deceptively simple: first enumerate the things that need protecting, then look for ways to compromise them.

An asset is intuitively something "valuable" that needs protecting — either because an attacker wants it (but shouldn't "have" it), or because it is intrinsically important (for example, an engineering secret — an attacker may want this too) [2] [3].

For clarity, asset enumeration and compromise fits the threat modelling process like so [4]:

This differs from approaches where assets emerge as a by‑product of finding attacks. In a strict asset‑based approach, assets are enumerated first and attacks are derived by compromising them.

There is a contradiction that is hard to escape, namely the model (what are we building) is descriptive and yet it must simultaneously contain assets — whose value derives from how they are threatened (what can go wrong).

Although this approach is less useful than it first appears, assets remain indispensable — but not for finding threats.

A quick detour

To make this a little more concrete consider a system with four components, one asset, a control, and three external entry points. From any entry point, an attacker must find a way to compromise an asset.

The blue lines are connections (or data flows). I haven't labelled these because they are not relevant here. Controls (for example, an authorization check) are typically modelled explicitly and treated as first‑class objects. Usually the model (diagram) is annotated with both controls and assets, although this is not strictly required. The model is intended to be purely descriptive.

In this worldview, controls protect assets, and attackers compromise assets by violating their security properties. If you can find an interaction "path" that violates an asset property, you have found a defect. Conversely, if there is no asset "behind" a component, the theory suggests there is nothing worth attacking.

What it means to "compromise" an asset, which security properties to use, and how controls intercept attack paths are left to the adopter. Asset‑based threat modelling therefore denotes a family of approaches that share the premise of "first enumerate then compromise".

Now, let's look at the practical pitfalls.

1. What is the asset aka never-ending asset discovery?

After an initial asset sweep, are you done?

A password is an obvious asset. But the adaptive hash of that password in the database is also an asset. So is the password table. The database itself.

Preventing online password guessing relies on a bad‑try count. That counter must not be subverted because that defeats the control itself. But is the control an asset too? There may be other ways to bypass the control effectiveness.

Remember, first enumerate assets without thinking about attacks — but without threat criteria there is no reliable stopping rule.

Those familiar with early object‑oriented design will recognize this issue: everything could be an object, and it is hard to judge object‑worthiness in isolation. The same applies to assets and asset-worthiness.

Time spent enumerating assets (in isolation) is time not spent finding attacks [3].

2. But everything needs protecting

If everything needs protecting, then everything is an asset [5].

• The integrity of the web server? Yes.
• The executing control plane [6]? Yes.
• The at-rest control plane? Yes
• Transport channels, messages, configuration, secrets, keys, certificates? Yes.
• Software artifacts, runtime state, credentials, PII, business data, logs? Yes.

Architectural elements — such as communication channels — require protection and therefore, are assets.

Suggestions to narrow the list by evaluating desirable security properties offer little help when everything is an asset. This dilemma is a straightforward consequence of the original contradiction. The model is both descriptive and yet it contains assets which are whose value derives from how they are threatened.

3. Attackers want … abstractions

Assets elicited during model discovery are overwhelmingly engineering artefacts. This is unsurprising: models are software models, expressed in software engineering terms — components, data flows, data stores, events, cloud services, tokens, credentials, keys.

But attacker "wants" are frequently abstractions — be root, win a game, bypass a payment check, crypto mine (steal compute), spend a voucher twice. These concepts are not first‑class objects in a (software) model. Tooling also reflects this effect by synthesizing assets from the technology context.

4. Where is the asset?

Consider an online multiplayer game. Bob locks other players out by triggering session lockouts against his competitors (Bob knows their login ids). Uncontested, Bob accumulates the most points and wins.

The model shows two assets: Play and Scores. This is a sensible asset-based model [7].

Now, try to answer the following two questions. Which asset is compromised? Where is this asset?

Bob never compromises the Scores asset. He wants to manipulate his relative position — being top of the leaderboard at the end of the game. The asset is a system-wide state, not a piece of data or a thing. It cannot be placed at a location or reached via an attack path.

If an asset cannot be located or reached, it cannot be "compromised" — not in the manner described.

5. What else can go wrong?

Thinking of an asset as being exclusively … an asset is frequently unhelpful. A password must remain confidential — clearly an asset. But in an online guessing attack, it is part of the attack surface and its use in this way needs defending against. This applies to all input because input is axiomatically malicious.

The concept of "compromising assets" is hard to translate into a set of prescriptive, repeatable steps. Attackers interact with (attack) surfaces, not assets. An attack realised elsewhere can impact an asset simply by changing system state.

Likewise, "controls protect assets" is a category error. Offline hash cracking and online guessing target the same asset (password), but the mitigation is specific to the attack vector (reducing the velocity of authentication attempts versus adaptive hashing), not asset.

Long live the asset!

If assets are only somewhat useful for finding threats, then what are they good for? Answer: risk scoring. Risk is defined by damage to something (with some impact and likelihood), and that something emerges naturally as a by‑product of attack modelling. Put another way: don't discover assets, let them come to you.

Here are some assets from attack goals (the asset is bold, damage is italicized):

• Become domain admin (use domain admin's account)
• Execute a fraudulent stock trade
• Forge a Json Web Token
• Bypass multi-factor authentication
• Own a (victim's) account
• Steal compute time (crypto mining)

Here are some assets from attacks (the attack surface is italicized, asset is bold):

• An Insecure Direct Object Reference (IDOR) [business resource] is an attempted horizontal privilege escalation against a system's business logic tier.
• XML External Entity is an injection attack against the XML parser at the target [control plane]
• Online password guessing acts against the unauthenticated HTTP login endpoint
• Attaching to the RS232 serial (or JTAG) interface of an (embedded) device — is an attempt to gain direct access to the ****"data link" surface.

In this formulation, assets do not exist independently of threats — but they remain essential for assessing impact. The ability to use the domain admin's account has value.

Summary

This is an opinionated critique of using assets to find threats, assuming a strict asset-based approach. The key takeaways: avoid over discovering assets up-front and avoid relying on asset-compromise for analysis. Assets are still useful, being fundamental to attack goals and they remain indispensable for risk treatment. Here are the key pitfalls:

1. Up-front asset discovery is time‑consuming with little payoff.
2. If everything needs protecting, everything is an asset.
3. Assets from attack goals are abstractions. They can't be enumerated up front.
4. Abstract assets can't be placed in a software model (diagram).
5. Assets emerge naturally when we consider what can go wrong.

References

[1] Thank you to my colleagues David Johansson and Chris Cummings whose feedback helped to improve this article.

[2] This article discusses using assets without defining them to avoid an unnecessary detour. See Shostack for an extensive definition of assets.

[3] A. Shostack, "Threat Modeling: designing for security," Wiley, pp. 36–37,39.

[4] I'm assuming a strictly linear, "pure" asset-based approach. In reality it is iterative. Therefore some, or none, of the pitfalls may apply to you (assuming you use assets as part of your threat modelling process).

[5] David Johansson, personal communication.

[6] A. Lee-Thorp, "Is this the threat you've been looking for?," 9 May 2025. [Online]. Available: Is this the threat you've been looking for? | by Signal & Noise | Medium.

[7] Albeit simplified