For a while now I was preparing to write a series of articles on various threat models that are present in the ecosystem. My goal is to create a couple of simplified threat models for various solutions based on the functionality provided and business / mission processes that are executed using this functionality. The problem is complexity.

One of the simplest blockchain network that I can think of is Bitcoin. But even in this instance, there are several layers of functionality that have different threats facing them. For example, for the final user one of the most prevalent threat is wallet compromise. But if we for a moment suspend all the assumptions about security features provided by the network (such as blockchain integrity) and delve in the details of the consensus protocol (Proof of Work at the time of writing), we will see several more scenarios in which things go wrong.

For example, if we would find a way to produce a block colliding (in context of crypto) with the target block, i.e. containing a different set of transactions while having the same SHA-256 hash value, we might try to compromise the settlement layer of the network.

These are two entirely different threats that correspond to two different functions of the whole network. How do I come up with a system to navigate these?

Currently my approach is to group threat models in categories of functionality relevant from a perspective of a specific (legitimate) actor using the solution. Main groups of actors:

1. End users
2. web3 Service providers (crypto-exchanges, investment brokers, lenders, etc.)
3. Node operators / block validators
4. Network/solution creators/maintainers

This categorization allows for some models (meaning, simplification by abstracting parts of threat model complexity) with assumptions on security features from perspective of an actor. For example, as a customer of an exchange service, I assume that infrastructure (with emphasis on web3 parts) of the service are secure. As a service provider of exchange service, I assume that functionality that providers runtime for my smart contracts is secure (e.g., an L2 solution is relying on L1 properly, all layers in an L1 solution are secure, etc.).

This approach is similar to the shared responsibility model which is often used in cloud environment (AWS, Azure, GCP), only with more layers.

For estimating risk of individual threats I will use the following risk matrix:

‍

‍

I hope that using this approach I will be able to navigate the threat models in an efficient manner and prepare a series of articles that will explore these perspective in a complete, comprehensive manner.