4 min de lecture
Vous ne corrigerez pas toutes les vulnérabilités
Un vendredi à 16 h 05, l’éditeur de l’équipement d’accès à distance d’une société d’ingénierie de 150 personnes publie un avis : une faille critique, notée 9,8 sur 10, touche toutes les versions, et il n’existe pas encore de correctif. L’équipement est exposé sur internet, et c’est par lui que quarante ingénieurs se connectent depuis chez eux. L’informatique compte trois personnes, et deux cents correctifs attendent déjà dans leur file. La société est fictive, la situation est courante : aucune équipe ne corrige tout, tout de suite, partout, et la gestion des vulnérabilités est donc une suite de choix, dont certains seront mauvais. C’est la préparation qui limite les dégâts quand ils le sont.
Un volume qui impose des choix
Chaque année, des dizaines de milliers de nouvelles vulnérabilités sont publiées. Corriger demande de tester, de trouver une fenêtre d’arrêt acceptable pour l’activité, parfois d’attendre un fournisseur qui n’a pas encore publié son correctif, comme ce vendredi. Certains systèmes ne peuvent tout simplement pas être mis à jour : équipements industriels, matériel médical, applications anciennes dont plus personne ne maintient le code. Dans ces conditions, établir des priorités revient à accepter un risque sur tout le reste, et ce n’est pas une négligence, c’est la nature du travail.
L’équipe de notre société fictive le sait bien. Ses deux cents correctifs en attente ne sont pas tous égaux, mais rien, dans la liste, ne le dit : les mises à jour de postes de travail côtoient des failles de serveurs, et l’avis du vendredi arrive dans un flux où tout paraît urgent. La question devient alors celle du tri, c’est-à-dire de ce qu’on regarde pour décider.
Prioriser n’est pas trier par score
Le réflexe est de trier par score de gravité. Le score CVSS mesure la gravité technique d’une faille, pas la probabilité qu’elle soit exploitée chez vous, et les deux diffèrent souvent. Plusieurs questions comptent davantage. La faille est-elle déjà exploitée dans la nature ? Le catalogue des vulnérabilités connues comme exploitées, tenu par l’agence américaine CISA et désigné par le sigle KEV, recense celles pour lesquelles c’est établi. Le système concerné est-il exposé sur internet ? Quelle est son importance pour l’activité ? Existe-t-il une mesure de compensation, comme la désactivation d’une fonction ou le filtrage de certains accès ? Le score EPSS, qui estime la probabilité qu’une faille soit exploitée, aide en outre à départager des cas voisins.
Appliquée à notre société, cette grille donne un résultat net, même si le vendredi n’offre pas encore toutes les réponses : un équipement exposé, essentiel au travail de quarante personnes, touché par une faille critique sans correctif, passe devant des dizaines de failles plus anciennes mais enfouies dans un réseau interne.
Le jour où la faille non corrigée est exploitée
Lors de la faille Log4Shell, en décembre 2021, la question la plus difficile pour beaucoup d’organisations n’était pas « comment corriger ? » mais « où utilisons-nous ce composant ? ». Savoir ce que l’on possède, et dans quelle version, fait partie de la préparation, et cela ne se règle pas le jour de l’avis. Le délai entre la publication d’une faille et sa première exploitation peut, de plus, être très court, parfois quelques jours.
Reprenons le vendredi à 16 h 05. Plusieurs décisions doivent être prises, et elles se prennent mal dans l’urgence. Qui décide d’isoler l’équipement, et peut le faire sans attendre ? Qui accepte l’impact sur l’activité, c’est-à-dire quarante ingénieurs qui ne se connectent plus ? Comment saura-t-on si l’on a été compromis avant l’annonce, et depuis combien de temps conserve-t-on les journaux de connexion ? Qui informe les clients si des données ont pu être consultées, et dans quel délai ? Ces questions se posent beaucoup mieux un mardi en salle de réunion qu’un vendredi soir. Les réponses peuvent d’ailleurs prendre la forme de seuils convenus à l’avance : si une faille est exploitée et le système exposé, on l’isole dans un délai fixé, et le responsable métier est informé, non consulté.
Corriger moins vite, répondre plus vite
Un retard de correctif se compense par la capacité à détecter et à réagir, et cette capacité se répète. Disposer des journaux au bon moment, connaître le contact chez le fournisseur et son numéro de week-end, savoir lancer un changement en urgence, et savoir revenir en arrière si ce changement casse quelque chose : tout cela s’apprend en le jouant, pas en le lisant. Une organisation qui l’a joué une fois n’improvise pas le vendredi soir.
Pour notre société fictive, la différence est concrète. Sans préparation, le vendredi de 16 h 05 débouche sur une soirée de discussions et, peut-être, sur un week-end d’incident. Avec une règle d’isolement convenue, une liste des équipements à jour et un accès de secours testé, il débouche sur une demi-journée de travail dégradé et sur une décision consignée : le risque restant a été accepté par quelqu’un, nommément, jusqu’à la publication du correctif.