Un petit rituel pour lire les threat models des autres

Quand quelqu’un me tend un document de threat model, je ne le lis pas de bout en bout. J’ai appris, après en avoir relu peut-être deux cents, que la première chose à comprendre n’est pas ce qu’il y a dans le document, mais ce que le document croit être.

Voici les cinq questions que je pose, dans l’ordre, avant même de regarder un schéma :

Qui a écrit ça, et quand ? Si l’auteur a quitté l’entreprise ou si le document a plus de six mois, je lis probablement de la fiction. Les threat models se dégradent plus vite que le code.
Quelle décision ce document a-t-il été écrit pour appuyer ? Un threat model qui existe parce que « la conformité a dit qu’il nous en fallait un » est une tout autre bête que celui écrit parce que « l’équipe n’arrivait sincèrement pas à décider si cette architecture était sûre ». La plupart des documents échouent ici. Ils existent, mais ils n’ont pas de but.
Quelle est la chose la plus coûteuse qui puisse mal tourner ? Pas la plus probable, la plus coûteuse. Si le document n’a pas de réponse claire à cette question dans les deux premières pages, les auteurs n’ont pas fait le travail difficile.
Qu’ont-ils décidé de ne pas modéliser ? Tout threat model a une frontière de périmètre. La question intéressante est de savoir si cette frontière a été choisie délibérément ou si c’est un artefact de ce que les auteurs connaissaient par hasard.
Qu’est-ce qui a changé depuis l’écriture ? L’architecture évolue. Les dépendances changent. De nouvelles fonctionnalités se greffent. Un threat model correct en janvier peut être dangereusement incomplet en juin.

Ce n’est qu’une fois que j’ai des réponses à ces cinq questions que je commence à lire le contenu lui-même. À ce stade, je sais généralement si le document vaut mon temps, et ce que je dois y chercher si c’est le cas.