Gestion des vulnérabilités
Lancer un scanner de vulnérabilités est la partie la plus facile. N’importe quel outil vous fournira un rapport contenant un millier de résultats classés selon un score CVSS qui n’a pratiquement rien à voir avec la capacité réelle d’un attaquant à exploiter cette vulnérabilité contre vous aujourd’hui. La gestion des vulnérabilités consiste à transformer cette multitude de résultats en une liste restreinte d’éléments réellement importants, puis à s’assurer qu’ils soient corrigés.
La lacune que je constate le plus souvent n’est pas un manque d’analyses de sécurité, mais un manque de hiérarchisation des priorités et de suivi. Les équipes reçoivent un rapport, corrigent les problèmes faciles, puis laissent le reste de côté, car il n’y a pas de responsabilité clairement définie quant à savoir qui est chargé de la correction ou quelle est réellement la date limite. Pendant ce temps, la seule vulnérabilité critique réellement exploitable depuis Internet — peut-être un service accessible au public fonctionnant sous une ancienne version comportant une faille connue — reste enfouie à la douzième page, à côté d’une centaine de vulnérabilités de faible gravité sur des systèmes internes auxquels personne ne peut accéder depuis l’extérieur.
Comment je gère cela
J’ai mis en place un processus d’analyse qui couvre ce qui compte réellement : la surface d’attaque externe, le réseau interne, la configuration du cloud et, le cas échéant, le code des applications. Mais le véritable travail réside dans la hiérarchisation des priorités : recouper ce qui est exploitable, ce qui est exposé et ce qui causerait réellement du tort s’il était compromis, afin que votre équipe corrige les cinq points essentiels de la semaine au lieu de se focaliser sur un score de gravité. Je mets en place des workflows de correction avec une responsabilité clairement définie et des SLA réalistes, basés sur le risque réel, et non sur une politique générale du type « tout corriger en 30 jours » qui finit par être ignorée car inapplicable.
Je suis également l’évolution du programme dans le temps, et pas seulement les résultats individuels. Si une même catégorie de vulnérabilités réapparaît sans cesse, il s’agit d’un problème de processus, et non d’un problème de correctifs, et il convient d’en corriger la cause profonde : un pipeline de compilation qui n’inclut pas la mise à jour de l’image de base, ou une équipe dont le calendrier de déploiement ne prévoit pas de fenêtre dédiée à l’application des correctifs.
À qui s'adresse ce document ?
Si vos rapports d’analyse s’accumulent sans être lus, si vous ne pouvez pas affirmer avec certitude quelle est actuellement votre vulnérabilité la plus susceptible d’être exploitée, ou si vous effectuez des analyses sans pour autant mener à bien les mesures correctives, cela mérite d’être corrigé.
Contactez-moi et discutons ensemble de ce qui est réellement analysé dans votre environnement et de ce qu’il advient des résultats.