Avalanche de vulnérabilités : Sauvons les équipes…
Avalanche de vulnérabilités : Sauvons les équipes opérationnelles !
25 000 nouvelles vulnérabilités CVE en 2024. 5 jours pour corriger les critiques selon les référentiels. Résultat ? Des équipes opérationnelles submergées et des RSSI frustrés. Et si le problème n'était pas de patcher plus vite, mais de patcher mieux ?
Dans un contexte où les vulnérabilités se multiplient de manière exponentielle (plus de 25 000 nouvelles entrées CVE recensées en 2024), la gestion des vulnérabilités est souvent présentée comme la première ligne de défense technique contre les cybermenaces. Les référentiels normatifs, tels que l'ANSSI, le NIST, l'ISO 27001 et le PCI-DSS, prescrivent généralement un délai de correction rigide, généralement de 5 jours pour les vulnérabilités critiques. Cette exigence contribue à la propagation de l'idée simpliste selon laquelle toute vulnérabilité non corrigée dans ce délai serait automatiquement considérée comme une non-conformité. Cependant, cette confusion entre vulnérabilité technique et non-conformité réglementaire peut générer des tensions lors des discussions entre les équipes opérationnelles et les équipes risques.
Le piège de la confusion : vulnérabilité ≠ non-conformité
Pour commencer, définissons ce qu’est une vulnérabilité et sa distinction avec une non-conformité.
- Une vulnérabilité est une faiblesse technique dans un système, une application ou une configuration, pouvant être exploitée par un attaquant pour compromettre la sécurité. Elle peut être liée à un bug logiciel, un défaut de conception, une mauvaise configuration ou encore l’absence de correctif (par exemple : la vulnérabilité Log4J).
- Une non-conformité, elle, correspond à l’écart entre l’état réel d’un contrôle et l’exigence fixée par une norme, une politique interne ou une réglementation. Elle ne traduit pas forcément une faille exploitable, mais plutôt le non-respect d’une règle. Par exemple : Il convient que l'organisation procède régulièrement à la surveillance, à la révision, à l'évaluation et à la gestion des changements des pratiques de sécurité de l'information du fournisseur et de prestation de services. (ISO 27002 : 5.22 Surveillance, révision et gestion des changements des services fournisseurs)
Une vulnérabilité n’est pas nécessairement une faille exploitable, et un patch non appliqué ne signifie pas obligatoirement que l’organisation est en défaut de sécurité Lorsqu’elle est publiée, le délai avant qu’elle ne soit exploitée « dans la nature » n’est pas prédictible (on pourrait parler de l’EPSS mais ça nécessiterait un article dédié.) C’est ce que l’on a pu constater en décembre 2021 avec Log4Shell, une vulnérabilité dans la bibliothèque d’Apache Log4j permettant d’exécuter du code arbitraire à distance (RCE) et donc potentiellement de prendre le contrôle d’un serveur. Elle était exploitée bien avant sa publication et sa « disclosure » a entrainé une recrudescence des tentatives d’exploitation. Cette dynamique soulève des questions quant à la pertinence du délai réglementaire de 5 jours souvent imposé pour corriger une vulnérabilité critique.
La réalité du terrain : quand patcher devient impossible
Dans la pratique, les équipes opérationnelles, notamment en environnements critiques ou fortement contraints (Mainframe, Legacy, OT), sont souvent confrontées à l’impossibilité d’appliquer les patchs dans les délais imposés, sans prendre le risque de provoquer des interruptions de service (et donc des impacts métiers) ou des régressions techniques. Cette tension permanente entre conformité réglementaire et réalité opérationnelle soulève une question : comment et quand patcher ?
Le respect des délais de correction issus des référentiels normatifs est une illusion si la vulnérabilité n'est pas replacée dans son contexte opérationnel. Ainsi replacer le risque d’exploitation d’une vulnérabilité dans le contexte opérationnel de l’actif qu’il impact prend tout son sens.
Alors, comment replacer la vulnérabilité et le contexte opérationnel au centre du débat ? Commençons donc par le début, le vulnerability management.
Pendant des années, le vulnerability management a suivi une méthode presque industrielle, pensée comme un cycle bien huilé. On commence par identifier les vulnérabilités, soit grâce aux scans réguliers, soit par des programmes de bug bounty ou lorsque des chercheurs remontent des failles connues (ou inconnues) sur des actifs IT/OT (c’est ce que l’on appelle la disclosure).
Vient ensuite l’évaluation de la vulnérabilité, traditionnellement dominée par le CVSS : un chiffre, une sévérité, une hiérarchie des priorités. Puis une illusion confortable : traiter en priorité les vulnérabilités “critiques” semble rationnel. Mais ce modèle ne dit rien du risque réel pour l’actif impacté et donc pour l’organisation.
Puis, l’étape la plus lourde : le traitement de la vulnérabilité, qui consiste soit à patcher (remédier) ou appliquer des correctifs (mitiger). Dans le monde OT, elle est même souvent impossible : mettre à jour un automate ou un contrôleur industriel peut signifier et arrêter une chaîne de production. Ici, la logique du patch massif est tout simplement inapplicable. Après la correction, la boucle de traitement prévoit la vérification (une pure utopie) : vérifier que la solution choisie (remédiation ou mitigation) est effective, que la vulnérabilité n’est plus exploitable et que l’exposition est réduite, etc. Une étape indispensable, mais qui, dans la pratique, révèle souvent l’écart abyssal entre ce que l’on croit avoir corrigé et ce qui reste en réalité exploitable. Sans parler des potentielles régressions lors des éventuelles montées en version... Une boucle sans fin.
Enfin, la phase de reporting. Elle devrait être le moment où l’on traduit l’effort technique en indicateurs de risque intelligibles pour la Direction : “Voici ce que nous avons neutralisé, voici ce qui reste à risque, voici l’impact business”. Mais trop souvent, elle se limite à un décompte infernal : nombre de vulnérabilités ouvertes, nombre de correctifs appliqués, taux de patching, taux de conformité.
Ce processus, en apparence structuré, est aujourd’hui dépassé par la réalité. L’identification produit une avalanche ingérable de vulnérabilités. L’évaluation par la criticité (ou par le CVSS) trompe plus qu’elle n’éclaire lorsqu’elle est utilisée seule, sans rapprochement avec le contexte environnemental de l’asset impacté. La remédiation, quand elle est possible, n’absorbe jamais le flux de nouvelles vulnérabilités. Et le reporting se transforme en tableau de bord de métriques creuses, loin d’une vraie vision du risque.
Recentrer la gestion sur le risque réel : la priorisation contextualisée
C’est ici que la priorisation contextualisée devient la seule voie viable. Elle ne supprime pas le processus, elle le transforme. À l’étape d’identification, on ne se contente plus de collecter tout ce qui existe, on hiérarchise dès la source selon la criticité métier des actifs concernés. À la classification, on abandonne l’obsession du score CVSS pour croiser plusieurs signaux : menace active issue de la threat intelligence, exposition externe révélée par l’Attack Surface Management et valeur métier de l’actif concerné. À la remédiation, on intègre la mitigation, on accepte que patcher ne soit pas l’unique option, surtout en OT : on compense par segmentation, monitoring, durcissement. Et au reporting, on ne présente plus des volumes de vulnérabilités, mais un récit du risque : “Nous avons neutralisé les scénarios d’attaque plausibles qui menaçaient nos actifs critiques.”
La gestion des vulnérabilités telle que nous l’avons connue n’est donc pas morte dans son principe, mais dans sa pratique. Elle s’est enfermée dans une logique de volume qui n’a plus de sens face à l’inflation des vulnérabilités. La priorisation contextualisée ne consiste pas à réinventer la roue : elle consiste à redonner au processus son objectif initial, protéger l’entreprise, plutôt que de courir après des chiffres.
Et vous, êtes-vous encore en train de compter les vulnérabilités ou bien gérez-vous efficacement les risques ?
Il est temps de passer d'une logique de volume à une logique de valeur. Votre prochaine réunion de COMEX ne devrait plus porter sur le nombre de patchs appliqués, mais sur les risques réels neutralisés. C'est ce changement de paradigme qui sauvera vos équipes opérationnelles.