Gestion des vulnérabilités - Stratégie et automatisation

C’est lundi matin, vous arrivez au bureau, prenez votre café (goût noisette bien sûr) puis ouvrez la console de votre scanneur de vulnérabilités préféré et là … 5 000 nouvelles vulnérabilités découvertes, un nombre qui vous fait presque recracher ce délicieux nectar. Et pourtant, il va bien falloir les traiter !

Cet article décrit deux stratégies pour traiter les vulnérabilités découvertes, tout en gardant à l’esprit la réalité du terrain car, comme toujours, « on ne peut pas tout corriger pour hier », même si on aimerait bien.

Remarque : Dans le cas où vous souhaiteriez suggérer une amélioration ou simplement me contacter, vous pouvez le faire à contact@lionsec.lu.

Source des vulnérabilités

Au sein d’une organisation, il existe plusieurs méthodes de détection et de recensement des vulnérabilités qui affectent (et parfois impactent) vos actifs : serveurs, postes de travail, systèmes HVAC, IoT, équipements réseau, applications web, cloud, etc.

Parmi ces sources, les principales sont généralement :

Scanneurs de vulnérabilités (avec ou sans agent)
Scanneurs de code statiques (SAST)
Scanneurs dynamiques (DAST)
Scanneurs de dépendances (tels que l’OWASP Dependency Check)
Rapports de pentests internes ou externes
Bug bounty, pas obligatoire mais recommandé
Services cloud (comme, par exemple, Security Hub sur AWS)
D’autres que vous pourriez avoir en place

Remarque : L’agrégation de toutes ces sources peut engendrer des doublons ainsi que des rapports dans des formats différents.

Seulement voilà : en général, un rapport de pentest ne contient pas de faux positifs, car le prestataire s’assure de livrer à ses clients un rapport final qui prouve, éléments de preuve à l’appui, que la vulnérabilité existe et explique comment la rejouer (sinon, changez de prestataire !). En revanche, les différents outils évoqués plus haut peuvent en générer énormément (ce que l’on qualifie notamment de bruit, ou noise), ce qui alourdit le tri des vulnérabilités découvertes.

Nous allons maintenant découvrir deux stratégies (une manuelle et une automatisée) pour gérer un grand nombre de vulnérabilités le plus rapidement possible, tout en évitant le bruit généré par les scanneurs.

La stratégie manuelle

Lorsque vous agrégez différentes sources ayant découvert différentes vulnérabilités, et que le temps manque à l’appel (ce qui est très souvent le cas), il va falloir rapidement différencier les plus importantes du reste afin de réduire l’impact potentiel sur vos actifs les plus critiques. Souvent (et bien malheureusement), certaines organisations le font avec un fichier Excel, ce qui peut rester acceptable selon la taille de l’organisation et le nombre de vulnérabilités découvertes. Passons maintenant en revue cette stratégie, en plusieurs phases.

Phase 1 - Trier par actif

Le premier filtre consiste à se concentrer, non pas sur le score CVSS, mais sur la valeur des actifs et leur niveau d’exposition (car les acteurs malveillants ne passent pas forcément par les plus valorisés). Plus leur valeur est importante, plus l’impact d’une cyberattaque serait grand. De même, plus ils sont exposés, plus la probabilité d’attaque est élevée. Il va donc falloir se concentrer sur ces actifs en particulier.

Le choix difficile de laisser momentanément les autres de côté nous laisse toujours perplexes, mais comme ces actifs sont plus critiques que les autres et que nous ne disposons pas d’un temps illimité, il faut bien prioriser.

Phase 2 - Niveau de sévérité et exploitabilité

Une fois les vulnérabilités filtrées sur ces actifs, plusieurs indicateurs peuvent nous aider à les départager :

Le score CVSS : le Common Vulnerability Scoring System (en version 4.0 au moment de la rédaction de cet article) permet de mesurer le niveau de gravité d’une vulnérabilité en fonction de plusieurs critères (vecteur, complexité, privilèges, etc.). C’est souvent l’indicateur fourni au minimum par les rapports de pentest ou les outils automatisés.
Le score EPSS : l’Exploit Prediction Scoring System est un modèle de machine learning permettant d’estimer la probabilité qu’une vulnérabilité publique soit exploitée dans la nature au cours des 30 prochains jours.
Le catalogue CISA KEV : le catalogue KEV (Known Exploited Vulnerabilities) contient une liste de vulnérabilités déjà connues pour être exploitées.

Certaines solutions comme Cyberwatch regroupent ces trois indicateurs en un seul, parfois appelé Priorisation 3D, ce qui permet aux organisations de savoir directement quoi prioriser.

Phase 3 - Matrice Impact x Effort

C’est l’étape où votre expertise dans la compréhension des vulnérabilités est la plus importante. En effet, malgré les deux premières étapes, il vous reste probablement plusieurs vulnérabilités de niveau critique ou élevé, et il devient plus subtil de les départager.

En vous appuyant sur votre connaissance de l’environnement, cette étape consiste à établir une matrice des vulnérabilités, classées par impact potentiel si elles venaient à être exploitées, puis par niveau d’effort requis pour les corriger.

Il peut simplement s’agir d’un faux positif, ce qui règle rapidement le problème, ou bien plusieurs vulnérabilités peuvent simplement nécessiter une mise à jour (et c’est souvent le cas sur un serveur critique de production auquel tout le monde a peur de toucher :)).

Remarque : J’entends régulièrement que certaines personnes se focalisent uniquement sur le score CVSS d’une vulnérabilité pour en exiger la correction. C’est une erreur de jugement : votre solution peut être affectée par une vulnérabilité qui ne s’exploite (par exemple) que via l’API de cette solution, que vous n’avez jamais activée.

En bref, cette étape nécessite de passer les vulnérabilités retenues au peigne fin et demande des connaissances métier afin de prioriser plus efficacement.

Remarque : De même, vos connaissances en sécurité offensive auront leur rôle à jouer. Entre une injection SQL et une XSS réfléchie, en général, la question ne se pose pas, mais qu’en est-il d’une XSS stockée ? :)

Phase 4 - Parallélisation

Selon votre structure et les vulnérabilités retenues, il peut être possible de paralléliser la correction des vulnérabilités entre différentes équipes : la vulnérabilité A pourra peut-être être assignée aux développeurs car elle provient d’un code vulnérable, la vulnérabilité B devra attendre, tandis que la vulnérabilité C pourra être assignée à l’équipe réseau / infrastructure puisqu’il s’agit d’un mauvais paramètre de configuration.

Ce cycle se répète indéfiniment dans une démarche d’amélioration continue et progresse d’actif en actif. Bien sûr, il faut mettre à jour vos politiques et processus pour réduire les vulnérabilités dans le temps, avec des SLAs bien définis car, si vous êtes éditeur, vos clients vous les demanderont, surtout lorsqu’il s’agit de vulnérabilités comme celles touchant PHP (CVE-2026-109618 et CVE-2026-109619), qui font beaucoup parler d’elles au moment de la rédaction de l’article. Ou encore, la fameuse vulnérabilité Log4Shell, impactant la librairie Log4j, provoquant une vague de messages des clients (et bien entendu, tout à fait légitimes) afin de demander des preuves de la correction de cette dernière dans vos produits et environnements.

Remarque : La divulgation de cette vulnérabilité datant du 10 décembre 2021, oui, juste avant les vacances de Noël :)

Explorons maintenant la stratégie automatisée car, comme vous vous en doutez, lorsque le nombre de vulnérabilités à traiter est beaucoup trop important, la stratégie manuelle prend énormément de temps, et c’est bien pour cela que des solutions existent pour nous aider.

La stratégie automatisée

Fort heureusement, il existe des solutions qui permettent d’automatiser cette stratégie (et bien au-delà). L’une d’entre elles est DefectDojo de l’OWASP, qui existe en version gratuite (community) et professionnelle. La page du GitHub officiel fournit les adresses des démos des deux versions, identifiants compris, pour un aperçu en direct de ce qu’elles permettent de faire.

Parmi les fonctionnalités clés, on retrouve :

Une vue d’ensemble de toutes les vulnérabilités et de leurs sources de découverte
La suppression des doublons
Des possibilités d’auto-remédiation via l’agent SenseiAI (version Pro)
Des connecteurs vers différentes solutions de scan de vulnérabilités (Acunetix, Cyberwatch, BurpSuite Enterprise, etc.) (version Pro)
Un centre de remédiation (très pratique pour voir quelles mises à jour peuvent éliminer de nombreuses vulnérabilités d’un coup) (version Pro)
Un explorateur d’actifs (URLs, code source, dépendances, ressources cloud, etc.)

Une autre option open source est Faraday, qui utilise également des connecteurs vers différents scanneurs de vulnérabilités et outils de pentest. Elle existe elle aussi en version community et professionnelle.

Après avoir installé la solution, déployé vos connecteurs et configuré vos politiques avec vos SLAs, vous voilà avec une solution d’automatisation bien plus complète qu’un simple fichier Excel difficile à maintenir.

Ignorer les vulnérabilités à faible criticité ?

Le sujet fait généralement débat et dépend de la tolérance au risque de l’organisation. Certaines décident de ne pas s’en préoccuper, par manque de temps ou simplement parce que « le risque est indiqué comme faible ».

Je recommande toujours d’y jeter au moins un œil car une cyberattaque ne consiste (généralement) pas en un mouvement direct d’un point A vers un point B, mais plutôt en une succession de vecteurs. Les acteurs malveillants peuvent utiliser toute information utile afin d’étendre leur attaque vers d’autres vecteurs plus intéressants. Parfois, corriger des vulnérabilités de criticité faible ou informationnelle (et même moyenne) peut aider à casser une chaîne d’attaque que l’acteur aurait pu tenter d’utiliser.

Conclusion

La gestion des vulnérabilités peut s’avérer complexe au premier abord, surtout lorsqu’une organisation s’y attelle pour la première fois, mais avec la bonne stratégie et les solutions appropriées, il est possible de gagner énormément de temps et d’efficacité dans la correction de ces faiblesses qui pourraient passer sous les radars et vous causer du tort. Toute organisation est libre de gérer ses vulnérabilités selon sa propre méthodologie, mais les stratégies présentées dans cet article permettent déjà d’y voir plus clair sur la façon de procéder.

Liens

Contact

Pour toute suggestion d’amélioration ou simplement me contacter : contact@lionsec.lu.