présentation

Un modèle de menaces est un processus de cybersécurité formel qui vise à identifier les menaces potentielles pour un système ou une application. Il est essentiel de comprendre les concepts de base d'un modèle de menaces pour développer une intuition solide de ce qu'un bon modèle de menaces devrait répondre.

contexte technique

Un modèle de menaces devrait répondre à des questions de base telles que : Qu'est-ce que nous protégeons ? Qui ou quoi veut nuire à ce que nous protégeons ? Comment pourraient-ils attaquer ? Qu'allons-nous faire pour prévenir ces attaques ? Il est également important de considérer les relations entre les actifs, les hypothèses et les menaces que nous ne traitons pas.

Pour développer un modèle de menaces, il est recommandé de commencer par écrire les questions de base, puis de cartographier les composants du système et leurs relations. Ensuite, il faut identifier les entrées et les sorties de chaque composant et essayer de répondre aux questions du modèle de menaces.

implications et limites

Les modèles de menaces sont censés être des documents vivants, mis à jour régulièrement. Il est important de être clair sur les hypothèses et les limites du modèle de menaces. Les exemples de modèles de menaces, tels que celui de l'auteur pour son travail sur la transparence des clés pour le Fediverse, peuvent aider à comprendre les concepts et les limites d'un modèle de menaces.

exemples et mise en pratique

Un exemple de modèle de menaces bien conçu est celui de l'auteur pour son projet de transparence des clés. Cependant, un exemple de modèle de menaces mal conçu est celui de Matrix, qui ne répond pas aux questions de base et ne fournit pas d'hypothèses claires.

Exemple de modèle de menaces :
   - Assomptions (stated up front)
   - Assets
   - Actors (both attackers and people we want to protect), given role names
   - The risks, which have one of four statuses attached
   - Prevented by design: Attack simply won’t work lol 😀
   - Mitigated: Attacks shouldn’t succeed, unless an assumption is wrong. Most interesting for researchers to focus on.
   - Addressable: There’s a way to mitigate the risk, but it requires effort or care. Operators should be aware of this.
   - Open: This is a risk we cannot or will not mitigate. These are the attacks that will succeed.