Dossiers et rapports du modèle de menace
Sytance · Mis à jour
Un modèle de menace consigne l’architecture du produit, les scénarios d’attaque, les mesures de sécurité et les résultats de vérification. La mise en relation de ces dossiers permet à un examinateur de suivre le raisonnement depuis une attaque jusqu’à la mesure choisie pour y répondre. L’exemple de passerelle montre comment ces dossiers s’articulent ; les sections ci-dessous expliquent quoi consigner et comment l’examiner.
Organiser le modèle
Conservez le diagramme et l’analyse ensemble ou reliez-les au moyen d’identifiants stables. Un document convient à une petite revue ; des dossiers structurés deviennent utiles lorsqu’une même mesure répond à plusieurs menaces ou lorsque l’équipe doit comparer des versions.
Dans Sytance, l’équipe modifie l’architecture et les dossiers de menace dans l’espace de travail, puis relie les exigences de sécurité, conceptions et dossiers de vérification pertinents. Le module de documentation utilise les informations de l’espace de travail pour préparer des rapports.
Informations produit et hypothèses
Identifiez la version du produit, son déploiement, sa finalité et ses utilisateurs. Précisez les éléments inclus dans l’analyse, les dépendances externes et les exclusions qui influent sur un chemin d’attaque.
Les recommandations de décomposition de l’OWASP distinguent les points d’entrée, les actifs et les niveaux de confiance. Utilisez ces distinctions pour expliquer l’architecture au lieu de transformer chaque actif en processus distinct sur le diagramme.
- Contexte : produit, version, environnement, finalité et responsable de la revue.
- Architecture : révision du diagramme, processus, magasins de données, entités externes et flux.
- Objectifs de protection : données et fonctions nécessitant confidentialité, intégrité ou disponibilité.
- Hypothèses : chaque condition incertaine, son responsable et un moyen de la confirmer.
Rédiger un scénario d’attaque par dossier
Attribuez un identifiant stable à chaque menace et reliez-la à l’élément ou au flux correspondant du diagramme. Décrivez qui pourrait attaquer, l’accès nécessaire, l’action, la faiblesse et la conséquence. Indiquez toutes les conditions dont dépend le scénario.
Exemple TM-01 : un utilisateur de passerelle en lecture seule appelle l’API d’écriture de configuration. Si l’API vérifie l’authentification sans vérifier le droit d’écriture, l’utilisateur peut modifier la destination de télémétrie. Le flux concerné va du navigateur à l’API de gestion, et l’attaque menace l’intégrité de la configuration enregistrée.
Une entrée indiquant seulement « élévation de privilèges, risque élevé » n’explique pas ce scénario. Ajoutez la justification du risque : compte nécessaire, exposition du point d’accès, impact réaliste et contrôles existants pris en compte.
Mesures, mise en œuvre et vérification
Pour TM-01, la mesure proposée AC-01 exige que l’API de gestion vérifie les autorisations relatives à l’action et à la ressource lors de chaque écriture de configuration. Le dossier de mise en œuvre doit identifier la modification concernée. Le dossier de vérification doit inclure le résultat réel de l’essai pour la version indiquée.
- Décision : réduire, éliminer ou accepter le risque, avec une justification et un responsable.
- Mesure : comportement requis et étapes d’attaque concernées.
- Mise en œuvre : composant, référence de modification et version du produit.
- Vérification : configuration de l’essai, action, résultat attendu et observé, et lien vers les preuves.
- Risque résiduel : conditions non résolues et décision de revue autorisée.
Résultats attendus et observés
Pour la passerelle fictive, le résultat attendu est le rejet d’une demande d’écriture faite par un utilisateur en lecture seule et l’absence de changement de la configuration enregistrée. Le résultat observé consigne ce qui s’est produit pendant l’essai. Tant que l’essai n’a pas eu lieu, ce champ reste en attente.
La même distinction s’applique aux mesures. « Vérification de signature prévue » et « vérification de signature mise en œuvre et testée » indiquent des niveaux de confiance différents. Conservez cette distinction lors du transfert du dossier dans un rapport ou un autre outil.
Examiner le modèle achevé
Demandez à un examinateur de suivre une attaque depuis le diagramme jusqu’à la mesure choisie et au résultat d’essai. Si les liens sont difficiles à suivre, déterminez si un dossier manque ou si l’attaque doit être expliquée plus clairement.
Vérifiez que la version indiquée correspond au diagramme, que chaque scénario fait l’objet d’une décision de traitement et que les risques acceptés précisent qui les a acceptés. Les hypothèses non résolues restent listées avec un responsable et un moyen de les confirmer.
Après avoir mis à jour les dossiers de l’espace de travail, ouvrez Documentation et sélectionnez le rapport pertinent. Selon la configuration et le plan de l’espace de travail, Sytance fournit des aperçus HTML et des fichiers PDF ou DOCX. Avant de l’utiliser lors d’une revue, vérifiez le rapport rendu par rapport à la version actuelle du produit, à l’analyse et aux preuves de vérification.