Les pirates agissent très vite. On ne connaît même pas le nombre des ennemis qui agissent dans l'ombre, guettant la prochaine vulnérabilité à exploiter. Ils trouvent parfois une vulnérabilité qui n'a pas été identifiée par les chercheurs au chapeau blanc ou par les fournisseurs, ce qui résulte en une exploitation « Zero Day ». Cependant, le plus souvent, ils guettent les divulgations publiques et les mises à jour des fournisseurs pour identifier les changements apportés au code. C'est là que la course commence. Ils essaient de créer une exploitation fonctionnelle avant que les entreprises du monde entier n'aient corrigé les vulnérabilités.

Plusieurs exemples récents montrent à quelle vitesse les pirates agissent :

  • BlueKeep (CVE-2019-0708) : Cette vulnérabilité, qui a fait tant de bruit car on voyait en elle la prochaine attaque WannaCry potentielle, a été résolue le 14 mai 2019. En raison de sa notoriété, nous avons pu voir le développement des exploitations en action, car plusieurs équipes de recherche indépendantes ont conçu des exploitations opérationnelles en seulement 14 jours (dès le 28 mai 2019, plusieurs vidéos POC (Proof of Concept) montraient une exploitation complète de cette vulnérabilité). Les pirates n'ont pas utilisé ces exploitations immédiatement, mais on a vu un grand nombre d'utilisations actives en minage de cryptomonnaie.
  • ZeroLogon (CVE-2020-1472) : Cette vulnérabilité de NetLogon a été résolue par la mise à jour du 11 août 2020. Cette résolution a nécessité des changements dans le mode de fonctionnement de NetLogon, si bien que Microsoft a déployé la mise à jour en corrigeant la vulnérabilité mais en mettant le changement en mode Audit pour commencer. Microsoft a annoncé une application de ce changement dans les publications du Patch Tuesday de février 2021, mais les entreprises pouvaient l'appliquer plus rapidement si elles étaient prêtes, en modifiant un paramètre de registre. Le 15 septembre 2020, des POC ont été annoncés et, le 18 septembre, le Department of Homeland Security – la sécurité intérieure des Etats-Unis – a publié une directive d'urgence (Emergency Directive 20-04) qui conseillait aux agences gouvernementales de déployer et d'appliquer la mise à jour dès le lundi suivant, le 21 septembre 2020. Il s'avère que cette urgence était justifiée, puisque les premières exploitations sur le terrain ont été détectées avant la fin du mois de septembre.
  • .Net\SharePoint RCE Flaw (CVE-2020-1147) : Initialement résolue lors du Patch Tuesday du 14 juillet. Dès le 21 juillet, du code d'exploitation POC circulait. Cette mise à jour a été publiée une nouvelle fois pour le Patch Tuesday d'octobre.

Dans ces trois cas, le délai entre publication et mise à disposition du code d'exploitation est compris entre 14 et 28 jours. Cela concorde avec les résultats du 2016 Data Breach Investigations Report de Verizon, qui montre que 50 % des exploitations se produisent dans les quatre semaines qui suivent la publication par le fournisseur. Les résultats du rapport « Zero Days, Thousands of Nights », publié par RAND Corporation, montrent que le délai moyen d'exploitation d'une vulnérabilité est de 22 jours. Sur la base de ces preuves, il est recommandé de cibler un SLA de correction des vulnérabilités de 14 jours maximum. Et cela nous amène à d'autres difficultés.

Pourquoi un SLA de 14 jours est-il difficile à mettre en place ?

Des solutions de gestion des vulnérabilités et des correctifs sont disponibles sur le marché depuis plus de dix ans, et ce sont des solutions relativement matures. Les technologies servant à identifier, préparer, traiter et signaler rapidement l'état des vulnérabilités présentent peu de difficultés.

Les plus grands défis sont notamment le fait que le processus de correction des vulnérabilités implique plusieurs équipes et jeux de technologies. Ce processus est truffé d'étapes manuelles, de tests et d'impacts opérationnels, et de problèmes de communication de base qui provoquent des délais. Je peux vous citer sans trop réfléchir un grand nombre d'entreprises qui ont réussi à appliquer des SLA de 14 jours maximum pour la correction des vulnérabilités. Certaines sont de grandes entreprises de fabrication, de vente, etc. Qu'ont-elles fait pour y parvenir, puisqu'elles utilisent les mêmes technologies que d'autres entreprises, dont le cycle est toujours de 30 jours ?

Les 4 principaux défis de la correction des vulnérabilités :

  • Combler le fossé entre sécurité et opérations IT : Soyons honnêtes. Il n'est pas fréquent que les équipes Sécurité et Opérations « s'entendent » réellement. L'équipe Sécurité parle de risques et de CVE, alors que l'équipe Opérations parle de fonctionnement et de correctifs. La résolution d'une CVE a un impact opérationnel, parce que le correctif peut endommager quelque chose. Cela entraîne de nombreuses difficultés pour l'équipe Opérations. Lorsque les opérations quotidiennes empêchent la résolution rapide des problèmes de sécurité et qu'un incident se produit, cela provoque de nombreuses difficultés pour l'équipe Sécurité.
  • La définition de priorités en fonction des risques est essentielle pour résoudre d'abord les bonnes vulnérabilités : Très souvent, le niveau de gravité défini par le fournisseur et le score CVSS ne reflètent pas ce qui est le plus urgent. On compte de nombreux exemples de résolution d'un « Zero Day », alors que la gravité fournisseur est seulement « Important » et que le score CVSS est de 7,0, voire moins. Des mesures et métadonnées supplémentaires sont nécessaires pour s'assurer que les éléments les plus dangereux sont corrigés. Par exemple, quelles sont les vulnérabilités activement exploitées ?
  • Connaître la fiabilité des mises à jour : Retour au SLA de correction des vulnérabilités et au délai d'application des correctifs. L'un des plus grands obstacles qui empêchent d'agir rapidement est l'incapacité à faire des tests efficaces. Les administrateurs ont deux options : 1) Essayer de mettre leurs tests à l'échelle pour garantir qu'ils n'ont pas d'impact opérationnel. - ou - 2) Laisser jouer le temps dans leur processus de tests, les choses se résoudront d'elles-mêmes si l'on attend assez longtemps. Le problème, c'est que les pirates adorent ça, lorsque vous attendez. Je vous ai parlé du rapport RAND qui a montré que la durée de vie moyenne d'une exploitation est de sept ans ? Apparemment, certains problèmes n'ont pas été résolus pendant très longtemps... autant de fruits défendus à portée de main pour les pirates.
  • Conformité des correctifs : Les rapports de conformité sont très variés, mais la plupart vérifient l'heure d'ouverture de votre fenêtre de maintenance, pas la date initiale de publication de la mise à jour. Microsoft, Adobe et Oracle publient la plupart des mises à jour de sécurité à des dates régulières et prévisibles, mais Google, Apple, Mozilla et de nombreux autres ne le font pas. Le suivi de la conformité d'une vulnérabilité nécessite de se concentrer sur un niveau plus granulaire pour tenir compte de la nature des logiciels actuels, distribués en continu.

Si la fiabilité des correctifs, la définition de priorités en fonction des risques et la conformité des correctifs sont des défis qui vous empêchent de respecter un SLA de 14 jours pour la correction des vulnérabilités, il vous faut peut-être une expérience plus performante que votre solution actuelle de gestion des correctifs. Ivanti® Neurons for Patch Intelligence a été spécialement conçu pour relever ces défis. Découvrez-le dès maintenant.