En matière de cybersécurité, certaines vulnérabilités dépassent le cadre de leur gravité technique et deviennent des événements marquants pour le secteur. Log4Shell, en 2021, en faisait partie. Plus récemment, les vulnérabilités regroupées sous le terme générique de « PHP2Shell » ont ravivé les mêmes inquiétudes au sein des équipes de sécurité du monde entier.
Dans les deux cas, la leçon à en tirer va bien au-delà d’un simple score CVSS.
Les professionnels de la sécurité utilisent souvent des référentiels tels que le CVSS pour hiérarchiser les efforts de correction, et à juste titre. Cependant, les vulnérabilités qui retiennent l’attention mondiale nous rappellent que le risque n’est pas déterminé uniquement par la gravité technique. L’impact réel d’une vulnérabilité sur l’activité d’une entreprise dépend d’une combinaison de facteurs : l’omniprésence de la technologie concernée, la facilité d’exploitation, la disponibilité d’un code de preuve de concept public, l’exposition sur Internet et la rapidité avec laquelle les acteurs malveillants exploitent de nouveaux vecteurs d’attaque.
Lorsque ces facteurs convergent, les organisations sont confrontées à un défi bien plus important que le simple déploiement d’un correctif.
Un score CVSS fournit une évaluation technique importante d’une vulnérabilité, mais il ne rend pas compte de l’intégralité du risque opérationnel.
Voici les questions que les responsables de la sécurité devraient se poser lorsqu’une vulnérabilité critique est révélée :
Les réponses à ces questions fournissent souvent une mesure plus précise du risque pour l’organisation que le score CVSS lui-même.
C’est précisément ce qui a rendu Log4Shell si perturbateur. Les organisations du monde entier ont rencontré des difficultés non pas parce qu’elles ne comprenaient pas la vulnérabilité, mais parce qu’elles ignoraient souvent où le composant vulnérable était déployé. Les dépendances cachées, les logiciels embarqués, les applications tierces et les inventaires d’actifs incomplets ont créé un problème de visibilité qui a persisté pendant des semaines, voire, dans certains cas, des mois.
Aujourd’hui, nous continuons d’observer des schémas similaires chaque fois que des vulnérabilités hautement exploitables apparaissent.
Les cadres de sécurité partent souvent du principe que les vulnérabilités critiques doivent être corrigées aussi rapidement que possible. Bien que ce soit l’idéal, toute personne travaillant dans un environnement d’entreprise comprend les réalités pratiques.
L’application de correctifs sur des systèmes critiques nécessite souvent :
Les systèmes hérités peuvent compliquer davantage les efforts de correction. Dans certains cas, les correctifs ne sont même pas disponibles immédiatement.
Il en résulte une situation courante et délicate : la vulnérabilité est connue, son exploitation est possible, mais la correction ne peut pas être effectuée immédiatement.
À ce stade, la maturité de l’organisation devient le facteur déterminant.
Lorsqu’une correction immédiate n’est pas envisageable, les organisations ont besoin de contrôles alternatifs qui réduisent l’exposition et ralentissent les attaquants.
C’est là qu’une posture de sécurité solide démontre toute sa valeur.
Une organisation résiliente doit être capable de :
Les entreprises ne peuvent pas protéger des actifs dont elles ignorent l’existence.
Des fonctionnalités complètes de gestion des actifs et d’inventaire des logiciels offrent la visibilité nécessaire pour déterminer rapidement l’exposition lorsqu’une vulnérabilité très médiatisée apparaît.
La capacité à répondre à la question « Sommes-nous concernés ? » en quelques heures plutôt qu’en plusieurs jours peut réduire considérablement les risques pour l’entreprise.
Une stratégie de défense en profondeur peut réduire considérablement le risque d’exploitation réussie avant la mise en œuvre d’une correction définitive.
En voici quelques exemples :
Ces contrôles ne peuvent pas éliminer la vulnérabilité, mais ils peuvent réduire considérablement les possibilités pour un attaquant de l'exploiter.
Les organisations doivent partir du principe que des tentatives d’exploitation publiques commenceront peu après la divulgation.
C'est pourquoi les équipes de sécurité doivent rapidement mettre en place :
Une détection précoce peut faire la différence entre bloquer une tentative d’intrusion et devoir réagir à un incident de sécurité majeur.
Deux indicateurs revêtent une importance particulière lors d’événements de vulnérabilité à grande échelle :
Temps moyen de détection (MTTD)
et
le temps moyen de réponse (MTTR)
Plus une organisation est capable d’identifier rapidement une activité suspecte et de mettre en œuvre des procédures de confinement, plus l’impact potentiel est faible.
Dans de nombreux incidents, les dommages les plus importants surviennent au cours des premières heures suivant l'exploitation de la faille. Réduire les temps de réponse limite directement la durée de présence de l'attaquant et les perturbations potentielles de l'activité.
L’importance de la préparation aux incidents
L’un des enseignements les plus précieux tirés de Log4Shell n’était pas d’ordre technique, mais opérationnel.
Les organisations disposant de plans de réponse aux incidents bien définis, de guides d’intervention testés et de processus décisionnels clairs ont pu réagir bien plus efficacement que celles qui ont tenté de mettre en place des procédures en pleine crise.
La préparation implique de disposer :
La prochaine faille majeure ne s’annoncera pas à l’avance. Il faut donc être prêt dès maintenant.
La prochaine faille critique est inévitable.
Qu'elle s'appelle Log4Shell, PHP2Shell ou tout autre nom, les organisations continueront à faire face à des menaces en constante évolution qui mettront à l'épreuve leur capacité de réaction.
Les organisations les plus résilientes ne sont pas nécessairement celles qui parviennent à appliquer immédiatement des correctifs à tous leurs systèmes. Ce sont celles qui comprennent leur environnement, surveillent en permanence les menaces, mettent en œuvre des contrôles compensatoires efficaces et réagissent avec détermination lorsque des incidents se produisent.
La question n’est pas de savoir si la prochaine faille majeure va se produire.
La question est de savoir si votre organisation est prête à en limiter l’impact lorsqu’elle se présentera.
Chez Integrity360, nous comprenons que la gestion des vulnérabilités ne se limite plus à l’application de correctifs. Il s’agit de gérer les risques tout au long du cycle de vie d’un événement de sécurité.
Grâce à des services tels que :
Nous aidons les organisations à renforcer leur posture de sécurité, à améliorer la visibilité sur l’ensemble de leurs environnements et à réduire considérablement les délais de détection et de confinement.
Lorsque la remédiation ne peut pas être effectuée immédiatement, notre priorité est de veiller à ce que les organisations disposent de la visibilité, de la surveillance et des capacités de réaction nécessaires pour limiter le succès des attaquants et maintenir leur résilience opérationnelle.