Votre plan d’actualisation présente un angle mort CVE

La conversation est simple, mais le problème qui se cache derrière ne l’est pas. Le client a acheté des serveurs en 2017 et les actualise généralement tous les cinq à six ans. En général, entre 2022 et 2023, ils auraient cherché à acheter du neuf.

Historiquement, c’est ce qui se serait produit. Mais la COVID a frappé, et il y a eu des contraintes sur la chaîne d’approvisionnement pendant la pandémie. L’avis de fin de vie initial qui aurait dû arriver vers 2023 a été prolongé : 2026 pour les mises à jour générales des logiciels et 2028 pour les failles de sécurité.

Cela a donné au client environ dix ans de vie sur cette plate-forme de serveur, ce qui signifie que le collège est juste au coin de la rue pour ce petit gars, et qu’il s’agit d’un environnement de soins de santé.

Dès que le COVID s’est calmé, ils auraient alors dû se rafraîchir. Ils ne l’ont pas fait. Avance rapide jusqu’à présent, ils nous ont demandé de parcourir une conception et une nomenclature, et nous nous trouvons maintenant au milieu d’une contrainte de chaîne d’approvisionnement sans précédent, où nous ne pouvons pas leur fournir d’équipement à cause de ce qui se passe avec la fabrication de puces d’IA et les hyperscalers.

Cela allait prendre huit à dix mois. En plus de cela, le coût était plus élevé qu’il ne l’aurait été l’année dernière, car les COGS ont considérablement augmenté.

Cela les met dans une position où acheter du neuf dépasse leur budget. Mais même s’ils en avaient les moyens, ils n’obtiendraient toujours pas d’équipement avant peut-être un an. Ensuite, ils devraient travailler sur le déploiement et la migration proprement dits. Cela les rapproche de 2028, date à laquelle la prise en charge des vulnérabilités de sécurité prendra fin, tout en les poussant certainement au-delà de 2026 pour les mises à jour logicielles générales.

Cela ne tient même pas compte du retard dans la prise en charge du système d’exploitation sur ces serveurs en raison de leur âge. Les versions ultérieures de VMware ne sont pas prises en charge, y compris VCF 9, et Broadcom encourage fortement ses clients à faire cette transition. Ils sont donc entre le marteau et l’enclume, sans options propres.

Le CTO a demandé : « Que sommes-nous censés faire ? Je n’arrive pas à croire que vous nous faites ça. »

Plus que tout, je veux les aider. Mais nous ne pouvons rien faire pour les aider comme ils le souhaitent.

Nous parlons beaucoup du fait que l’âge n’est pas un bon indicateur du risque, et c’est vrai. Alors maintenant, nous essayons de passer en revue et de réduire les risques là où nous le pouvons et de rechercher les vulnérabilités que nous pouvons corriger. Ensuite, il y a les choses que nous ne pouvons pas corriger ou avec lesquelles nous ne pouvons rien faire. Pour ceux-là, nous devons explorer des options telles que l’achat de nouveau matériel ou la transition vers le cloud lorsque nous ne pouvons pas obtenir de nouveau matériel à temps et que les exigences de conformité le permettent.

Cela met le client dans une position difficile, et il n’existe pas de réponses claires à cette question. Ainsi, s’il n’y a pas de réponse claire, la meilleure solution consiste à réduire l’incertitude.

Construire l’inventaire et cartographier l’exposition

La réalité est que vous ne pouvez pas évaluer le risque si vous ne connaissez pas vos actifs, et la plupart des CMDB présentent des lacunes.

La façon dont vous obtenez cet inventaire dépend de ce que vous possédez déjà. Si vous utilisez un scanner de vulnérabilités comme Nessus, Qualys ou Rapid7, vous disposez probablement de ces données. Exportez-le au format CSV et vous avez maintenant à moitié terminé l’évaluation.

Si vous ne disposez pas de scanner, Greenbone OpenVAS est gratuit, open source et fonctionne dans Docker ou sur une VM. Une analyse vous donne des plates-formes hôtes, des CVE mappés avec des scores de gravité et une sortie structurée.

Si vous préférez quelque chose d’un peu plus léger, Nmap reste le standard. Vous souhaitez l’exécuter avec la détection de version du service et la sortie XML sur vos propres plages réseau. De cette façon, vous obtenez des adresses IP d’hôte actives, des ports ouverts et des bannières de service.

runZero propose un niveau gratuit et gère généralement mieux les empreintes digitales des appareils que Nmap, en particulier pour des éléments tels que les appareils réseau et les contrôleurs de stockage.

N’importe lequel de ces chemins vous amène au même endroit : inventaire structuré, noms d’hôtes, plates-formes, versions et suffisamment de détails pour rechercher ce qui est vulnérable.

Désormais, la fin de vie correspond au moment où le vendeur cesse de vendre un produit. La fin du support se produit lorsque le fournisseur cesse de publier des éléments tels que des correctifs de sécurité. C’est la date qui détermine votre exposition. Une fois qu’une plate-forme franchit cette ligne, la liste CVE s’allonge de façon permanente et la liste des correctifs s’arrête.

Il existe une ressource gratuite, endoflife.date. Il s’agit d’une base de données gérée par la communauté couvrant des centaines de plates-formes avec des dates de cycle de vie et une API publique. Pour toute autre chose, consultez les pages de cycle de vie des fournisseurs.

Le résultat est votre inventaire avec les dates de fin de support attachées et un indicateur sur chaque actif qui a franchi sa limite de support.

Pour chaque actif signalé, l’étape suivante consiste à découvrir ce qui est réellement exploitable. Vous pouvez avoir une version logicielle incluse dans un CVE, mais elle a été renforcée par l’OEM et n’est pas réellement exploitable.

Si vous travaillez à partir de Nmap ou effectuez un inventaire manuel, vous devez connaître deux bases de données : la base de données nationale sur les vulnérabilités du NIST et le catalogue de vulnérabilités exploitées connues du CISA.

La différence entre un système avec 40 CVE et aucune entrée KEV et un système avec 12 CVE et 3 entrées KEV est la différence entre un risque gérable et un danger actif. L’âge de l’équipement ne vous dit pas lequel vous regardez, c’est pourquoi nous avons besoin du profil CVE.

Trouvez-le, notez-le, réparez-le

Nous utilisons désormais une formule pondérée pour évaluer chaque actif.

La formule que j’utilise est le nombre de KEV multiplié par 20, plus le CVSS le plus élevé multiplié par 4, plus les mois après la fin du support, plus des bonus pour une sensibilité élevée des données, une exposition sur Internet et des actifs qui ne peuvent pas être mis à niveau vers les normes cryptographiques post-quantiques. Ajustez les pondérations en fonction de l’appétit pour le risque de votre organisation.

Cette approche s’aligne sur le cadre de catégorisation des vulnérabilités spécifiques aux parties prenantes de CISA, qui donne la priorité au statut d’exploitation et au contexte de la mission plutôt qu’aux scores de gravité globaux. Les poids spécifiques sont réglables. Le principe selon lequel les entrées KEV l’emportent sur la gravité du CVSS et le CVSS l’emporte sur l’âge est la partie qui reste cohérente.

La file d’attente basée sur l’âge les faisait reculer. La file d’attente basée sur les risques les classe dans le bon ordre et en trois catégories.

1. Niveau 1 : action immédiate requise. Il s’agit d’actifs dont la prise en charge avec les entrées du catalogue KEV est terminée, en particulier dans les environnements réglementés ou dans le traitement de données sensibles. Ceux-ci ont connu et activement exploité des vulnérabilités sans qu’aucun correctif ne soit apporté. Dans la plupart des cadres réglementaires, il est difficile de défendre une position d’acceptation des risques sans contrôles compensatoires tels que la segmentation du réseau, le WAF ou l’IDS et doit inclure des mesures correctives dans un délai défini.
2. Niveau 2 : gestion des risques avec documentation. Il s’agit d’actifs ayant dépassé la fin du support avec des comptes CVE mais aucune entrée KEV actuelle, ou d’actifs approchant de la fin du support dans les 12 mois. Documentez la position d’acceptation du risque : qui a signé, dans quelles conditions et pour combien de temps. L’absence de cette documentation est en soi une constatation dans la plupart des cadres de conformité.
3. Niveau 3 : surveillé. Tout cela reste dans leur fenêtre de support, recevant des correctifs, avec des profils gérables. Ceux-ci appartiennent au calendrier de planification sans action immédiate. La clé ici est de s’assurer que leurs dates de fin de support sont visibles dans le calendrier de l’infrastructure pour éviter qu’ils ne deviennent des actifs de premier niveau par inattention.

Dernière couche, le NIST a finalisé les normes cryptographiques post-quantiques en 2024, et tous les matériels existants ne peuvent pas prendre en charge les nouveaux algorithmes. Certains remplacements seront motivés par des exigences de migration cryptographique indépendantes du profil CVE.

Ne sautez pas le post-quantique. Récolter maintenant, décrypter plus tard, c’est réel.

Ce avec quoi tu repars

Une fois l’évaluation terminée, il vous reste trois éléments qui changent la conversation sur la planification.

Tout d’abord, vous disposez d’une file d’attente d’actualisation prioritaire qui est séquencée par risque plutôt que par âge. Cela répond à la question de savoir où nous dépensons en premier, et c’est une analyse défendable.

Deuxièmement, vous obtenez une position documentée d’acceptation des risques pour tout ce que vous choisissez de ne pas actualiser pour le moment. Il s’agit de l’instrument de conformité qui manque à la plupart des organisations. Il nomme l’actif, le profil d’exposition, la justification commerciale et la personne qui a signé.

Troisièmement, vous obtenez une séquence de rafraîchissement que les auditeurs, les dirigeants et votre propre équipe peuvent défendre. À un moment donné, un RSSI, un membre du conseil d’administration ou un auditeur se demandera pourquoi un système particulier fonctionnait toujours. La réponse ne peut pas être : « Eh bien, nous n’en sommes pas encore au collège. » La réponse est documentée, tient compte des risques et est liée à des données réelles.

Si vous souhaitez que la file d’attente d’actualisation reste à jour à mesure que de nouveaux CVE et vulnérabilités sont découverts, vous pouvez déployer une plate-forme comme Wazuh qui croise automatiquement vos actifs avec les bases de données CVE. Cette évaluation ponctuelle devient alors un processus périodique alimenté par ce flux continu.

Aujourd’hui, vous repartez avec un point de départ que n’importe quelle équipe peut exécuter sans consultants externes ni budget important. La plupart des entreprises qui le parcourent découvrent au moins une partie de l’image qu’elles n’avaient pas auparavant, et cela suffit généralement à modifier l’ordre de la file d’attente.

Dans un environnement où les budgets de rafraîchissement sont serrés et les délais serrés, l’ordre de la file d’attente compte le plus.

Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?