Sécurité
STRIDE : Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege, méthode de classification des menaces créée chez Microsoft. « Six questions à poser à chaque élément d'une architecture avant qu'un attaquant ne les pose à sa place », par analogie avec la liste de contrôle du pilote, qui paraît puérile jusqu'au moment où l'on a oublié le train d'atterrissage.
Les six catégories : Usurpation d'identité (atteinte à l'authentification), altération (intégrité), répudiation (non-répudiation, c'est-à-dire la preuve de qui a fait quoi), divulgation d'information (confidentialité), déni de service (disponibilité) et élévation de privilèges (autorisation). Chaque lettre correspond à une propriété de sécurité violée.
Origine : Formalisée en 1999 par Loren Kohnfelder et Praerit Garg chez Microsoft, puis intégrée au cycle de développement sécurisé de l'éditeur. Elle s'applique classiquement à un diagramme de flux de données, élément par élément et à chaque franchissement de frontière de confiance.
Limite : STRIDE aide à ne rien oublier, pas à hiérarchiser : il faut y ajouter une estimation de vraisemblance et d'impact. Appliquée mécaniquement, elle produit un tableau exhaustif, dûment archivé, que personne ne relit avant l'incident.
Ce qui arrive si on s'en passe
Sans méthode de modélisation des menaces, la conception oublie systématiquement les mêmes catégories : la journalisation qui permettrait de prouver une action, la limite de débit qui éviterait le déni de service, le contrôle d'autorisation sur un appel interne jugé sûr. Ces oublis se découvrent en test d'intrusion ou en production, quand leur correction exige de revoir l'architecture au lieu d'ajouter une ligne au cahier des charges. Le coût est alors multiplié, et la responsabilité soigneusement diluée.
Explication de la marmotte
Avant de construire un logiciel, on peut se demander ce qu'un pirate pourrait faire contre lui. STRIDE propose six questions, une par lettre : peut-on se faire passer pour quelqu'un d'autre, modifier des données, nier avoir fait une action, voler des informations, bloquer le service, ou obtenir plus de droits que prévu ? En posant ces questions pour chaque partie du système, on trouve les problèmes quand ils sont encore faciles à corriger.
Où ce terme est utilisé
- Threat modeling STRIDE avant écrire le code (7 occurrences)
- Culture de sécurité dans une équipe produit (2 occurrences)
