Fixer le même délai de correction à toutes les vulnérabilités dites « critiques » paraît simple, mais laisse de côté des questions décisives : l’actif est-il exposé, l’exploitation est-elle plausible, quel service métier serait touché et existe-t-il une mesure temporaire vérifiable ? À l’inverse, une liste de scores sans échéance ne permet pas aux équipes de décider. Cette page propose une matrice reliant ces éléments à une priorité, un délai interne, une escalade et une preuve de clôture.
Les Cybersecurity Performance Goals de la CISA et la méthode d’évaluation de NIST SP 800-53A servent de contexte de priorisation et de vérification. Les délais illustratifs ci-dessous sont des décisions de gouvernance à adapter; ils ne sont ni des délais légaux universels ni une garantie de sécurité. Une organisation doit vérifier ses obligations contractuelles et sectorielles particulières avant d’adopter une matrice.
Définir ce qui entre dans la file de correction
Une entrée correspond à une faiblesse identifiée sur un actif, avec sa version, son exposition et son responsable. Le même identifiant de vulnérabilité peut toucher plusieurs applications et produire des priorités différentes. Une bibliothèque dans un environnement de laboratoire isolé ne présente pas automatiquement la même urgence qu’une passerelle accessible depuis Internet. Regroupez les occurrences lorsque la correction est commune, mais gardez le lien avec chaque service affecté afin de vérifier que toutes les instances ont été traitées.
Incluez les découvertes issues des scans, des équipes de développement, des fournisseurs et des incidents. Une alerte publiée par un fournisseur ne prouve pas que votre version ou configuration est concernée; une absence dans un scanner ne prouve pas l’inverse. Associez une source, une date et un état de confirmation. Si l’analyse de portée prend du temps, prévoyez une mesure conservatoire et une date de réévaluation, plutôt que de supprimer l’entrée avant de disposer des faits.
Le guide d’hygiène informatique de l’ANSSI situe les mises à jour dans une pratique de sécurité plus large. La matrice ici sert à prendre une décision par occurrence et à en garder la trace.
Séparer exploitabilité, exposition et impact
L’exploitabilité décrit les conditions nécessaires à une attaque et les informations disponibles sur une utilisation réelle. Vérifiez la fiabilité de ces informations et la possibilité technique dans votre configuration. Un score de gravité publié est utile pour commencer, mais ne remplace pas l’analyse de la version installée ni des protections en place. Une vulnérabilité exploitée activement sur une technologie que vous n’utilisez pas n’a pas la même portée qu’une faille confirmée sur votre interface publique.
L’exposition décrit le chemin d’accès à l’actif vulnérable: Internet, partenaires, réseau interne, poste utilisateur ou environnement isolé. Notez les droits préalables et les mécanismes qui limitent effectivement l’accès. N’écrivez pas simplement « non exposé » parce qu’une adresse n’est pas publique; une intégration partenaire, un poste compromis ou une administration distante peut constituer un chemin. Quand l’architecture est incertaine, indiquez le niveau de confiance de l’évaluation.
La criticité métier porte sur le service qui pourrait être perturbé, les données concernées et la capacité de récupération. Le propriétaire métier doit confirmer la conséquence plausible, sans transformer chaque application en service vital. La méthode EBIOS RM peut aider à relier un scénario technique à un événement redouté; la matrice de correction reste un instrument opérationnel plus court.
Construire une matrice utilisable
Définissez quelques classes observables plutôt qu’une formule opaque. Par exemple, une exposition directe et une exploitation crédible sur un service essentiel appellent une priorité immédiate; une faiblesse non exploitable dans la configuration actuelle appelle une validation documentée avant de fixer la suite. Le délai doit courir à partir d’un événement défini, tel que la confirmation de l’occurrence ou la réception d’un avis fournisseur, et le référentiel doit préciser ce point de départ.
| Situation illustratrice | Priorité | Mesure temporaire interne | Correction vérifiée interne | Escalade si échéance menacée |
|---|---|---|---|---|
| Exploitation observée, actif exposé, impact métier élevé | P1 | Décider confinement ou isolement sous 4 h | Viser 72 h, ou décision explicite de maintien sous contrôle | Direction sécurité immédiatement, puis décideur métier si 72 h impossibles |
| Exploitation plausible, exposition limitée, service important | P2 | Vérifier la restriction sous 2 jours ouvrés | Viser 14 jours calendaires | Propriétaire de service et sécurité avant le dépassement |
| Faiblesse confirmée, accès très restreint, impact limité | P3 | Confirmer l’isolement sous 5 jours ouvrés | Viser 45 jours calendaires | Responsable de service avant la fenêtre manquée |
| Applicabilité non établie | Analyse | Qualifier la version et le chemin d’accès sous 1 jour ouvré | Fixer ensuite P1, P2 ou P3 | Sécurité si la qualification reste impossible |
Ces durées sont un exemple fictif de politique interne, non des délais légaux, sectoriels ou contractuels universels. Dans cet exemple, l’horloge part de la confirmation de l’occurrence sur un actif et de son exposition, horodatée dans la fiche. Une information crédible d’exploitation active peut justifier le confinement avant la fin de cette qualification; l’équipe n’attend pas artificiellement pour faire démarrer l’horloge. Les jours ouvrés et calendaires sont distingués pour que deux lecteurs calculent la même date. Adaptez les valeurs à la capacité opérationnelle, au type d’actif, à la période de disponibilité et aux obligations particulières. Une échéance annoncée mais impossible à tenir ne crée pas un contrôle utile.
Supposons une occurrence P2 confirmée un lundi à 10 h. La restriction d’accès doit être vérifiée au plus tard mercredi selon l’exemple, tandis que la correction définitive doit être testée dans les quatorze jours calendaires. Si le fournisseur annonce dès le jeudi que son correctif arrivera dans trois semaines, le propriétaire n’attend pas le quatorzième jour : il remonte l’écart avec mesure temporaire vérifiée, conséquence métier, nouvelle date et décision du niveau prévu. La fiche conserve l’échéance initiale et la décision de report, au lieu de remplacer silencieusement la date.
Relier la priorité à une décision concrète
Chaque fiche indique l’identifiant de la faiblesse, les actifs et versions touchés, le scénario d’exploitation retenu, l’exposition constatée, l’impact métier, le responsable technique, la priorité, le point de départ de l’échéance et l’approbateur en cas de dérogation. Conservez les preuves qui étayent les hypothèses: résultat de scan, inventaire de composants, schéma d’accès, avis fournisseur ou compte rendu d’essai. La fiche doit permettre à un autre analyste de comprendre pourquoi une occurrence P2 n’a pas été classée P1.
Ajoutez l’action choisie et son effet attendu. Une mise à jour, la désactivation d’une fonction, une règle d’accès temporaire ou l’arrêt d’un service ne traitent pas exactement le même problème. Une mesure compensatoire exige une vérification propre et une date de réexamen. Ne la présentez pas comme une correction définitive si la faiblesse subsiste. Le guide de rédaction de la PSSI peut définir les responsabilités générales; la fiche doit renseigner la décision pour ce cas particulier.
Ne déduisez pas l’absence de risque de l’absence de preuve d’exploitation. Écrivez plutôt « exploitation non observée dans les sources consultées » avec les limites de visibilité. Si une information nouvelle apparaît, la fiche doit permettre de revoir immédiatement la priorité sans reprendre l’analyse de zéro.
Exemple chiffré sans faux universalisme
Prenons une faiblesse fictive dans un composant de gestion de fichiers. Elle apparaît sur trois actifs: portail client accessible depuis Internet, serveur interne utilisé par une équipe de support, environnement de recette isolé. Le fournisseur publie un correctif et les équipes confirment les versions. La matrice produit trois décisions liées à la même faiblesse, et non une seule date copiée partout. Le portail, parce qu’il reçoit des fichiers de tiers et soutient une activité sensible, est traité comme une priorité haute. Le serveur interne demande une vérification du chemin d’accès et une fenêtre de correction documentée. La recette peut être traitée avec le prochain cycle si l’isolement annoncé est réellement vérifié.
Supposons que la mise à jour du portail impose une interruption longue. Le responsable technique propose de désactiver temporairement la fonction vulnérable et de filtrer les accès. La sécurité vérifie que ces mesures couvrent le scénario d’attaque pertinent; le responsable métier accepte l’effet sur les clients; une date est fixée pour le correctif définitif. Si la désactivation empêche l’exploitation mais rompt une fonction essentielle, la décision remonte au niveau prévu par l’appétence au risque. Ce n’est pas le score seul qui tranche.
Dans la fiche, les délais exacts restent des choix internes du cas fictif. Ce qui doit pouvoir être audité est la séquence: constat, qualification, mesure temporaire, approbation, correction, nouvelle vérification et fermeture. La sécurité des traitements selon l’article 32 du RGPD fournit un contexte supplémentaire lorsqu’un traitement de données personnelles est concerné, sans fixer elle-même un délai unique pour toutes les failles.
Organiser les escalades avant un dépassement
Fixez un seuil d’alerte avant l’échéance, pas uniquement une notification après retard. Lorsque l’équipe responsable sait qu’elle ne pourra pas corriger dans le temps prévu, elle explique le blocage, l’exposition résiduelle, les mesures provisoires et la nouvelle proposition. La personne autorisée à accepter ce risque n’est pas nécessairement celle qui déploie le correctif. Définissez les niveaux d’escalade selon l’impact potentiel et gardez la preuve de la décision.
Une exception ne devrait pas devenir une prolongation automatique. Indiquez sa durée, les conditions de maintien, les signaux de réexamen et l’éventuel plan de sortie. Si la mesure compensatoire est un filtrage réseau, vérifiez qu’elle reste active après un changement d’architecture. Si elle dépend d’une surveillance renforcée, précisez la couverture et la durée de cette surveillance. À défaut, l’exception masque une vulnérabilité sans la maîtriser.
Lorsque la faiblesse provient d’un fournisseur, la politique de sécurité des fournisseurs peut préciser les échanges attendus. Conservez le dossier de correction et les communications contractuelles dans la chaîne de suivi interne. La responsabilité du fournisseur de livrer une correction ne supprime pas la décision de l’organisation sur son exposition immédiate.
Vérifier la fermeture
Un ticket marqué « corrigé » n’est pas la preuve que chaque occurrence a disparu. Confirmez la version ou la configuration sur les actifs identifiés, relancez une vérification adaptée et examinez les systèmes absents du scan initial. Un correctif peut échouer sur un nœud, être annulé par un déploiement ou laisser une fonction exposée sous une autre configuration. Notez la date, l’outil ou la méthode, la population testée et les exceptions restantes.
Les preuves d’audit périmées posent la même question temporelle: une capture valable avant la correction peut ne plus représenter l’état présent. Conservez l’avant et l’après, sans écraser l’historique. Si la fermeture repose sur un contrôle compensatoire permanent, nommez-le clairement et réévaluez-le périodiquement. Une faiblesse toujours présente ne doit pas disparaître de la vue par changement d’étiquette.
Un contrôle qualité simple consiste à échantillonner les dossiers fermés: le périmètre affecté est-il complet, le délai réel est-il calculé depuis le point de départ annoncé, l’exception a-t-elle été approuvée au bon niveau, et la vérification finale prouve-t-elle l’effet recherché ? Les réponses font évoluer la matrice mieux qu’un objectif de pourcentage sans examen des cas.
Faire évoluer les seuils avec les faits
Revoir la matrice après un incident, un changement de surface exposée ou plusieurs dépassements répétés. Si toutes les occurrences tombent dans P1, la classification n’aide plus à prioriser; si presque aucune n’y tombe malgré des exploitations réelles, les critères sous-estiment l’urgence. Comparez décisions et résultats, puis ajustez les exemples, propriétaires et seuils avec les responsables métiers. Conservez la version applicable au moment de chaque décision pour éviter de juger rétrospectivement une fiche avec un barème ultérieur.
Le bilan utile ne se limite pas au délai moyen. Suivez séparément les vulnérabilités ouvertes hors échéance, les exceptions expirées, les actifs sans responsable, les mesures temporaires non vérifiées et les corrections déclarées sans preuve. Un faible temps moyen peut cacher un petit nombre de failles dangereuses laissées ouvertes longtemps. Présentez ces cas à la direction avec leur conséquence métier et une décision attendue, plutôt qu’un seul graphique flatteur.
Tester la matrice sur des cas contradictoires
Avant d’adopter un barème, soumettez-lui quelques cas qui poussent dans des directions opposées. Une vulnérabilité au score élevé peut toucher un composant installé mais inactif. Une autre, au score moins spectaculaire, peut concerner une interface exposée avec un chemin d’exploitation bien documenté. Le barème doit permettre d’expliquer les deux résultats sans modifier les critères après avoir vu l’actif concerné. Faites analyser chaque cas par technique et métier séparément, puis comparez les désaccords. Ils révèlent souvent des définitions trop floues d’« exposition » ou de « service essentiel ».
Ajoutez un cas où l’information est incomplète. La matrice devrait produire un état d’investigation avec responsable et échéance, pas une priorité basse par défaut. Ajoutez également un cas où le correctif existe mais risque d’interrompre le service. Le résultat attendu doit combiner mesure temporaire, calendrier de changement et approbation de l’exposition résiduelle. Si le barème ne sait exprimer que « appliquer immédiatement » ou « reporter », il n’aidera pas les responsables à choisir une voie réaliste.
Enfin, confrontez les délais proposés à la capacité effective des équipes. Combien d’actifs faut-il corriger, quelles validations sont nécessaires et quel créneau de maintenance existe ? Une classe P1 ne devrait pas attendre une réunion mensuelle pour obtenir un décideur. Une classe moins urgente ne devrait pas être oubliée faute d’une file de suivi. Cette simulation ne transforme pas les délais en loi; elle permet de vérifier que l’organisation peut tenir la promesse qu’elle écrit.
La matrice aboutit à une règle de travail claire: pour chaque occurrence, l’équipe connaît l’exposition, l’exploitabilité et la conséquence métier; elle dispose d’une date, d’un décideur pour les écarts et d’un critère de fermeture vérifiable. Cette chaîne de décision rend le délai défendable et révisable lorsque la réalité technique change.