D'un problème de vulnérabilité à un changement en production

L'équipe de sécurité reçoit un long export du dernier scan. Des milliers de lignes, chacune avec un ID de vulnérabilité, une adresse IP et un score de gravité. Quelqu'un les divise par équipe et les envoie. Les opérations essaient alors de déterminer quels sont les serveurs concernés, à quel service ils appartiennent et quand ils peuvent être modifiés. Un mois plus tard, le prochain export arrive, et personne ne peut dire avec certitude ce qui a été corrigé depuis le précédent.

Derrière cette situation se trouvent des personnes fatiguées des deux côtés. La sécurité a l'impression que les opérations ne l'écoutent pas. Les opérations ont l'impression de recevoir des listes sans contexte ni priorités. Et la direction pose une question simple à laquelle personne ne peut répondre rapidement : sommes-nous dans une meilleure position qu'il y a un mois ?

Pourquoi un export de scanner ne suffit pas

Un scanner fait ce pour quoi il est conçu : il trouve des versions de logiciels vulnérables. Ce qu'il ne sait pas, c'est quel rôle joue un serveur, quel service s'exécute dessus et qui est responsable de ce service. Sans cela, une découverte ne peut pas être transformée en travail de manière sensée.

Nous voyons souvent les mêmes faiblesses :

• les découvertes sont classées par score seul, même si dans la réalité des opérations, il importe davantage de savoir si une vulnérabilité est activement exploitée,
• les délais de correction ne sont pas dérivés de la gravité, de sorte qu'une découverte critique peut attendre autant qu'une mineure,
• le chemin de la découverte à la modification passe par e-mail et par des tickets créés manuellement,
• l'état de la correction est reconstitué à partir de plusieurs feuilles de calcul et est toujours à la traîne.

Comment aborder le problème

Une découverte de vulnérabilité ne devient significative que lorsqu'elle est connectée à la CMDB. Une fois que nous savons sur quel serveur elle se trouve, nous savons également quel service elle met en risque, qui est le propriétaire de ce service et quelle est la fenêtre de maintenance. Ce n'est que alors que nous pouvons décider de l'ordre et du moment.

La priorité devrait suivre deux questions : quelle est la gravité de la vulnérabilité et est-elle activement exploitée ? Le délai suit de la réponse. Le chemin vers une correction devrait passer par le processus normal de changement, de sorte que même une correction urgente respecte l'impact sur les services, avec des délais plus courts.

Comment Eywo Stratum gère le problème

Eywo Stratum importe les découvertes de votre scanner et les fait correspondre à des éléments de la CMDB. Les vulnérabilités sont alors visibles par serveur et par service, de sorte que chaque propriétaire de service voit ce qui le concerne.

La priorisation s'appuie sur cela :

• les vulnérabilités activement exploitées (KEV) sont clairement signalées afin qu'elles ne se perdent pas parmi les autres,
• les délais de correction basés sur la gravité fixés lorsqu'une découverte doit être corrigée,
• un mode accéléré pour les problèmes critiques, convenu à l'avance dans l'accord de correctif avec le propriétaire du service, fournit un chemin plus court sans contourner la responsabilité.

Le chemin de la découverte à la correction est un plan de correctif par vagues. Les serveurs sont regroupés par service et fenêtre, et le plan génère les changements en une seule étape. Chaque changement passe par le calcul de l'impact, la vérification des fenêtres de maintenance, les gels et la détection des collisions. Les nœuds redondants peuvent être corrigés un à la fois de sorte que le service reste disponible.

Le tableau de bord de vulnérabilité et de correction montre combien de découvertes sont ouvertes, lesquelles approchent de leur délai et comment la correction progresse par service. La sécurité et les opérations regardent les mêmes données, ce qui met fin au débat sur quelle feuille de calcul est à jour.

Une image partagée au lieu de passer des listes

La gestion des vulnérabilités n'est pas seulement une discipline de sécurité. C'est un travail opérationnel qui nécessite un contexte : serveurs, services, propriétaires et changements. Lorsque ces informations sont connectées, la sécurité n'a pas à poursuivre et les opérations n'ont pas à deviner. Les deux parties peuvent voir ce qui doit être corrigé en premier, qui approuve et quand cela se produira. Et la question de la direction sur le fait de savoir si les choses sont meilleures qu'il y a un mois a une réponse sur un seul écran.

L'importation de découvertes, la priorisation des vulnérabilités, la planification des correctifs et le tableau de bord de correction sont inclus dans l'édition Business.