Barre d'erreurs et matrice de contrôles : quoi réparer en premier

Après une modélisation de menaces bien faite, la liste de menaces est en général plus longue que le budget de sécurité. Le cadre génère des menaces et des façons de réduire le risque, mais ne les priorise pas ni ne recommande des contrôles en couches selon leur type et fonction. Prioriser, c'est décider où vont les ressources limitées : entre journaliser toutes les actions administratives ou utiliser SSL/TLS pour chiffrer le trafic, entre implémenter des listes de contrôle d'accès (ACL) ou renforcer d'abord la validation d'entrée. « Prioritize your issues and apply security controls » sur Microsoft Learn donne la méthode pour décider, et ce post la parcourt : d'abord comment un problème se hiérarchise, ensuite comment se choisit le contrôle.

Prioriser par gravité du risque

Le cadre de menaces ne priorise pas seul, et ce n'est pas un oubli : la gravité d'un problème dépend du contexte du système et de l'appétit pour le risque de l'organisation, qui sont deux choses que seule l'équipe peut poser sur la table. C'est pourquoi la priorisation est un processus humain avec des critères écrits, et pas un champ de plus du générateur.

Le processus est en deux étapes : déterminer l'importance du problème dans le système et ensuite sélectionner les contrôles qui donnent la plus grande protection au moindre coût. Chaque problème reçoit une priorité selon son facteur de risque, et des contrôles qui fonctionnent ensemble sont sélectionnés pour créer une protection en couches, avec l'aide des collègues et de l'équipe de sécurité. Les problèmes se priorisent selon la gravité du risque si un attaquant exploite la menace. Les étiquettes varient entre organisations, mais suivent le motif du risque bas au critique.

La référence est la barre d'erreurs de sécurité interne de Microsoft :

Critique : impact critique pour les utilisateurs. L'exemple donné : des violations avec divulgation d'informations confidentielles et des menaces qui requièrent vie privée et implication légale.
Important : impact grave. Un système qu'on ne peut pas utiliser sans solution alternative connue.
Modéré : impact modéré. Problèmes de disponibilité avec solutions alternatives possibles.
Bas : impact bas.
Information : menace considérée, évaluée et déterminée comme non pertinente.

Le dernier niveau est le plus instructif du tableau : écrire « Information » signifie que la menace a été regardée, évaluée et décidée comme non applicable. Ce papier évite de rouvrir la même discussion à chaque revue. La barre ne remplace pas le jugement de l'équipe : elle le rend discutable. Deux problèmes avec la même étiquette partagent la priorité, et cette comparaison écrite est le vrai matériel de la réunion de priorisation. La distinction entre Modéré et Important fonctionne aussi : le modéré a des solutions alternatives possibles ; l'important laisse le système inutilisable jusqu'à ce que quelqu'un agisse. En pratique, la discussion de priorisation la plus commune arrive justement à cette frontière, quand un problème a une alternative mais que l'alternative fait aussi mal que le problème.

Le problème priorisé devient une tâche dans un service de gestion d'incidents, avec Azure DevOps Services comme exemple de la source, ce qui renforce la propriété du problème, suit l'historique et permet des modèles standardisés. Sans cette étape, la priorité vit dans un tableur que personne ne rouvre jamais. Et le suivi n'est pas de la bureaucratie : c'est ce qui permet de démontrer, des mois plus tard, quelles menaces ont été fermées, avec quel contrôle, et qui a signé l'acceptation de celles restées ouvertes.

Les trois types de contrôle

Un contrôle de sécurité se classe selon comment il se manifeste. Les trois types :

Physique : empêchent ou détectent l'accès non autorisé physiquement. Portes, badges, caméras, éclairage et systèmes de suppression.
Technique : protège logiquement le système. Pare-feu, antivirus, ACL et chiffrement.
Administratif : des politiques qui définissent des processus. Classification des données, audits et restrictions.

La recommandation de la source : appliquer des contrôles de tous les types pour créer des couches. Un chiffre qui fixe la catégorie des administratifs : une classification des données est aussi administrative qu'une politique d'admission, et sans elle les contrôles techniques ne savent pas quoi protéger d'abord. L'exemple de contrôle administratif que donne la source est la création d'un plan de réponse aux incidents : un document, avec tout ce que ça implique de processus.

Les cinq fonctions

La deuxième classification dit quand le contrôle agit, avec cinq fonctions qui protègent avant, pendant et après une possible violation :

Préventive : réduit la probabilité ou l'impact de la menace. Serrures, pare-feu, classification des données.
Détection : identifie les attaques au moment où elles se produisent. Surveillance, honeypots, journaux d'audit.
Corrective : contrôle la réponse à une attaque entrante. Réparation physique, revues du système, plans de réponse aux incidents.
Récupération : aide le service à se remettre de l'attaque. Sites actifs, sauvegardes système, plan de reprise après sinistre.
Dissuasive : empêche les attaquants de s'éloigner du système avec lui. Barrières, privilèges minimaux, politique d'usage autorisé.

La distinction entre détection et corrective est celle qui se confond le plus : la détection avertit pendant que l'attaque se produit ; la corrective décide ce que fait le système pendant que l'attaque est en cours. Une équipe qui investit seulement dans la détection finit par savoir qu'elle a perdu, à temps. Et la source donne les deux exemples qui fixent la différence : créer un plan de réponse aux incidents est un contrôle administratif ; réviser et restaurer le système après une attaque malveillante, avec revues du système et plans de réponse, est un contrôle correctif.

Les fonctions se lisent aussi comme une ligne de temps de la violation : avant (prévention et dissuasion), pendant (détection et correction), après (récupération). Un système avec seulement des contrôles préventifs n'a pas de réponse écrite pour le jour où la prévention échoue.

La matrice type par fonction

En croisant les deux classifications on obtient une matrice de sélection de quinze cellules qui fonctionne comme une checklist : la protection couvre avant, pendant et après la violation.

	Physique	Logique	Administratif
Préventive	Serrures	Pare-feu	Classification des données
Détection	Surveillance	Honeypots	Journaux d'audit
Corrective	Réparation physique	Revues du système	Plans de réponse aux incidents
Récupération	Sites actifs	Sauvegardes	Plan de reprise après sinistre
Dissuasive	Clôtures	Privilège minimum	Politique d'usage autorisé

Un honeypot est un système piège exposé exprès pour que l'attaquant s'en occupe et trahisse sa présence : la cellule Détection/Logique de la matrice. Lue par lignes, la matrice raconte l'histoire temporelle d'une violation : la ligne préventive empêche qu'elle arrive, celle de détection l'annonce pendant qu'elle passe, la corrective contient les dégâts, celle de récupération rend le service, et la dissuasive fait que l'attaquant préfère une autre cible. Lue par colonnes, elle montre combien de votre stratégie dépend du code (logique) et combien des processus (administrative).

La matrice a aussi un usage pédagogique : une colonne vide de votre liste de contrôles est une question que l'équipe de sécurité ne s'est pas encore posée.

flowchart LR
    P[Problème identifié] --> PR[Prioriser<br/>barre d'erreurs]
    PR --> T[Tâche dans le gestionnaire d'incidents]
    T --> C[Sélectionner le contrôle<br/>type × fonction]
    C --> R[Réduire, transférer<br/>éviter ou accepter]

En clair : le problème entre par la barre d'erreurs, sort converti en tâche, et la tâche se ferme avec un contrôle choisi dans la matrice.

Les contrôles qui rapportent le plus

Le conseil le plus pratique de ce parcours : les contrôles les plus bénéfiques se retrouvent dans plusieurs catégories STRIDE et sont en général relativement peu coûteux à implémenter. L'implication pour qui priorise : si un contrôle couvre usurpation et altération à la fois et qu'il est peu coûteux, il va en premier de file, même si sa cellule de matrice n'est pas la plus voyante.

La protection en couches ne se construit pas en achetant le contrôle le plus cher ; elle se construit en choisissant des contrôles qui fonctionnent ensemble. C'est le critère qui transforme la matrice en outil de décision et pas en liste de courses : chaque cellule que vous choisissez doit s'appuyer sur les autres. Et la fonction dissuasive, la plus silencieuse de la ligne, sort en général moins chère que le reste : privilèges minimaux et politique écrite coûtent moins qu'un pare-feu et couvrent le scénario le plus commun de tous, l'accès légitime utilisé pour quelque chose de non prévu.

De la lecture à l'exécution

Ce parcours a été de lecture : je n'ai priorisé aucune liste réelle de menaces ni sélectionné de contrôles contre un budget à soi. Ce que la source rend clair, c'est la méthode complète, de la gravité à la matrice ; ce qui manque, c'est la pratique, parce que c'est là qu'apparaissent les vrais doutes : quel niveau votre organisation assigne à ce que la barre de Microsoft appelle « Modéré », et si votre équipe applique la même règle à deux problèmes différents. Le premier pas est d'appliquer la barre à la dernière liste de menaces qui vous est restée sur la table : si aucun problème ne tombe en Critique, la discussion de budget change de ton. Et le second, choisir un seul contrôle de la matrice qui couvre plus d'une catégorie et soit peu coûteux : cette ligne, si elle existe, est le meilleur premier argent de sécurité du trimestre.

---

*Source : le module « Prioritize your issues and apply security controls » de Microsoft Learn.*