déploiement de la sécurité des applications

La course pour patcher OpenSSL est à nouveau lancée

Version imprimable, PDF et e-mail

Quelque chose a changé dans le mode de divulgation des nouvelles vulnérabilités et nous devrions nous en réjouir. Les responsables du projet OpenSSL ont annoncé la semaine dernière que le 1er novembre, ils publieraient une mise à jour du projet qui, entre autres, résout une vulnérabilité critique inconnue.

Cela signifie que cette semaine, tout le monde, y compris les cybercriminels, aura connaissance de cette vulnérabilité. Cependant, les équipes chargées de la cybersécurité sont désormais prévenues qu'elles doivent s'assurer que leurs entreprises sont prêtes à installer immédiatement une mise à jour d'OpenSSL.

La communauté OpenSSL supervise le développement d'un kit d'outils cryptographiques pour sécuriser les communications sur le protocole TLS (Transport Layer Security) sur lequel reposent largement les sites Web et les applications. Le célèbre bug Heartbleed découvert dans OpenSSL en 2014 avait permis aux cybercriminels d'envoyer une demande Heartbleed malformée avec une petite charge utile de malware et un champ plus long vers n'importe quel site Web ou application vulnérable.

La découverte de cette faille a créé de fortes perturbations. Dans certains cas, jusqu'à trois ans après la découverte du bug Heartbleed, des signalements de failles ayant exploité ce bug émergeaient encore. Le correctif qui sera publié cette semaine mettra à nouveau à l'épreuve les capacités de réponse aux incidents de sécurité de nombreuses entreprises, alors qu'une autre course contre la montre démarre. Les cybercriminels s'intéresseront sans aucun doute, comme le reste du monde, à l'annonce d'OpenSSL qui sera ouvertement partagée cette semaine.

La façon dont les vulnérabilités sont divulguées est, bien sûr, un sujet sensible pour de nombreux professionnels de la cybersécurité. La communauté open source avait tendance à privilégier une approche dans laquelle les divulgations sont partagées publiquement, pour rester dans les valeurs d'un projet géré de façon communautaire. Au fil des ans, c'est devenu de plus en plus difficile, car le volume de code open source intégré à une large gamme d'applications a augmenté de façon exponentielle. De nombreuses organisations informatiques recherchent toujours toutes les instances d'une vulnérabilité du logiciel open source Log4J largement utilisé pour collecter des données de log à partir d'applications Java.

Point positif, cette crise de la sécurité open source aura au moins servi à quelque chose. Les responsables de projets logiciels open source adoptent désormais de nombreuses technologies, de la signature cryptographique du code à la création automatique de nomenclatures logicielles (SBOM) qui promettent d'identifier plus facilement où sont exécutées les instances d'extraits de codes.

La question est maintenant de savoir dans quelle mesure les processus de réponse aux incidents de sécurité sont améliorés pour réagir suite à la divulgation de ces informations. Les équipes informatiques doivent d'abord pouvoir déterminer la gravité d'une vulnérabilité, puis s'assurer que les bonnes pratiques DevSecOps sont employées pour corriger les vulnérabilités les plus critiques le plus rapidement possible.

Dans les mois à venir, des failles de sécurité liées à des instances vulnérables d'OpenSSL qui n'ont pas été corrigées émergeront certainement. Cependant, il est clair que les équipes de sécurité informatique seront de plus en plus tenues pour responsables si les mises à jour nécessaires n'ont pas été installées.

Remonter en haut de page
Tweeter
Partager
Partager