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 limites d’une approche centrée sur le 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 :

    • Dans quelle mesure la technologie vulnérable est-elle déployée au sein de l’organisation ?
    • Est-elle exposée à Internet ?
    • Son exploitation peut-elle conduire à l’exécution de code à distance (RCE) ?
    • À quelle vitesse les acteurs malveillants adoptent-ils les techniques d’exploitation ?
    • Dans quelle mesure est-il difficile d’identifier avec précision chaque instance affectée ?
    • Combien de temps la correction prendra-t-elle réellement ?

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.

La réalité : une correction immédiate n’est pas toujours possible

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 :

    • Des autorisations de gestion des changements
    • Des tests de compatibilité des applications
    • Des fenêtres de maintenance
    • Des processus de validation par les fournisseurs
    • Des évaluations des risques opérationnels
    • Validation par les parties prenantes métier

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.

 

IR FRA

 

La posture de sécurité est plus importante que jamais

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 :

    • Connaître sa surface d’attaque

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.

    • Mettre en place des défenses en plusieurs couches

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 :

    • Pare-feu d’applications Web (WAF)
    • Systèmes de prévention des intrusions (IPS)
    • Segmentation du réseau
    • Renforcement des applications
    • Contrôles compensatoires
    • Technologies de correctifs virtuels

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.

Renforcement de la détection et de la recherche de menaces

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 :

    • des règles de détection SIEM
    • des analyses XDR
    • Cas d'utilisation de la chasse aux menaces
    • une surveillance des indicateurs de compromission
    • des stratégies de collecte et d’enrichissement des journaux

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.

Réduction du MTTD et du MTTR

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 :

    • des guides d’intervention en cas d’incident prêts avant l’apparition de la prochaine vulnérabilité critique
    • Des procédures de confinement bien définies
    • Des voies de remontée hiérarchique
    • Des plans de communication de crise
    • L'intégration des renseignements sur les menaces
    • Capacités de surveillance continue

La prochaine faille majeure ne s’annoncera pas à l’avance. Il faut donc être prêt dès maintenant.

 

 

La véritable leçon

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.

Comment Integrity360 aide les organisations à renforcer leur résilience

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.

 

Contactez-nous