Commencer par vérifier le périmètre

Avant de décider de l’urgence d’une alerte, établissez son lien avec votre patrimoine. Quel produit est déployé ? Dans quelle version ? Sur quel système et pour quel usage ? Une référence trouvée dans un inventaire mérite parfois une vérification auprès du responsable technique.

Conservez les éléments qui soutiennent la qualification : source de l’alerte, version observée, date de vérification et personne ayant confirmé le périmètre. Cette trace facilite les réexamens lorsque l’information évolue.

Rapprocher l’alerte de l’exposition réelle

La gravité technique aide à lire une vulnérabilité. Pour choisir une action dans votre organisation, complétez cette lecture par des questions concrètes : le composant est-il accessible ? Les conditions nécessaires sont-elles réunies ? Quel service dépend du système concerné ?

Notez les informations confirmées et celles qui manquent. Pour chaque point à vérifier, précisez qui peut apporter la réponse et à quelle échéance. Le dossier pourra être réévalué dès que ce complément sera disponible.

Décider d’une action réalisable

Pour chaque cas retenu, définissez un responsable, une action et une date cible. La correction peut nécessiter des essais, une validation applicative ou une fenêtre de maintenance. Faites apparaître ces dépendances dans le plan de traitement.

Si la correction doit attendre, documentez les mesures envisagées, leurs limites et la décision prise par la personne habilitée. Fixez aussi les conditions d’un réexamen. Une dérogation doit pouvoir être comprise après le comité qui l’a validée.

Clore avec un élément vérifiable

Définissez dès le départ ce qui permettra de clôturer l’action : contrôle de la version, résultat d’une vérification ou confirmation du retrait du composant. La preuve attendue dépend du contexte et des moyens disponibles.

Commencez par une trame simple : actif, vulnérabilité, qualification, décision, responsable, échéance et preuve de clôture. Faites évoluer le dispositif à partir des difficultés réellement rencontrées par les équipes.

Pour appliquer cette méthode, partez de vos versions déployées, de vos contraintes de maintenance et des informations de support de vos fournisseurs.