Pourquoi automatiser la gestion des certificats : les 5 leçons à retirer de la vulnérabilité Heartbleed

En 2014, une vulnérabilité critique d'OpenSSL a été rendue publique. Partout dans le monde, les entreprises ont entamé, manuellement, une course contre la montre pour résoudre le problème. Alors qu'une automatisation de la gestion des certificats aurait fait le travail plus efficacement, qu'en est-il aujourd'hui ?

En 2014, une vulnérabilité critique d’OpenSSL a été rendue publique de la pire façon qui soit. En cause : une faille baptisée Heartbleed, dont le nom qui signifie "cœur qui saigne" est particulièrement bien trouvé. Il s’agit d’une vulnérabilité de type "buffer over-read" (dépassement de tampon en lecture) qui existait spécifiquement dans l’implémentation de l’extension Heartbeat (ou "battement de cœur") du protocole TLS. La plupart des grands noms de la tech, comme Facebook, Google, Netflix, et le service AWS d’Amazon, ont été affectés par le bug Heartbleed.

Heureusement, ce bug n’a donné lieu à aucune violation majeure, même si des attaques mineures ont pu être observées çà et là. Mais partout dans le monde, les entreprises ont dû entamer une véritable course contre la montre pour résoudre le problème. Bien souvent, leur méthode consistait à parcourir manuellement la feuille de calcul où étaient consignées les informations relatives à leurs certificats afin d’identifier les serveurs touchés.

Ce processus est non seulement incroyablement fastidieux, mais en refusant de basculer vers un système de gestion automatisée des certificats, de nombreuses entreprises n’ont toujours pas retenu la leçon. La question reste donc entière : quels enseignements peut-on tirer de la gestion de certificats dans un monde post-Heartbleed ?

Optez pour une automatisation effective de vos certificats

Cela peut sembler évident, mais la première étape pour automatiser la gestion de vos certificats consiste effectivement à en automatiser le processus. En clair, abandonnez la traditionnelle feuille de calcul utilisée pour stocker vos numéros de licences et de certificats. Au regard du temps qu’il a fallu aux victimes pour retrouver leurs certificats et les mettre à jour sur les serveurs et autres équipements, cette pratique a fortement contribué à l’efficacité de Heartbleed. Or d’après les résultats de l’enquête réalisée cette année sur les infrastructures à clés publiques, 36% des professionnels IT continuent à gérer leurs certificats à l’aide de feuilles de calcul — plutôt inquiétant. 

Il existe plusieurs façons d’automatiser la gestion du cycle de vie des certificats. L’une d’entre elles consiste à automatiser le processus de provisionnement et d’inscription des certificats. 

Prenez en charge des protocoles récents et forts

Il est indispensable de prendre en charge le protocole TLS si l’on veut éviter des problèmes similaires à ceux provoqués par Heartbleed. Mais surtout, il faut abandonner les protocoles TLS 1.1 et TLS 1.2. Depuis l’arrivée de TLS 1.3, rien ne justifie de conserver l’une ou l’autre de ces anciennes versions.

C’est d’autant plus évident que des attaques d’envergure sont toujours menées contre les certificats SSL/TLS et que l’ancienne version de ces protocoles n’est pas sûre. En résumé : déployez le plus vite possible TLS 1.3.

Sachez exploiter les revues internes

Heartbleed était basée sur une vulnérabilité OpenSSL. Il est donc essentiel pour les organisations d’organiser régulièrement des revues internes de leurs logiciels open source. Ces revues peuvent notamment prendre la forme d’analyses dynamiques ou statiques, mais l’important est d’y intégrer la recherche exhaustive sur le web de vulnérabilités peu connues. Dans la mesure où elles conservent une longueur d’avance, les entreprises mettent toutes les chances de leur côté pour éviter les vulnérabilités négligées. Rappelons que Heartbleed est restée tapie dans l’ombre pendant près de deux ans.

Bien évidemment, les entreprises ne sont pas toutes dotées d’équipes de sécurité en interne. Si vous êtes dans ce cas, vous pouvez envisager de faire appel à un indépendant ou un cabinet de conseil pour mener un audit et sécuriser votre site web et votre système de backend. Vous pouvez tabler sur un tarif journalier moyen compris entre 300 euros et 500 euros, selon l’expérience du développeur choisi. Or, au regard de la tranquillité d’esprit qu’offre une telle démarche, surtout si votre développeur freelance possède une expérience du codage sécurisé, l’investissement en vaut largement la peine. Vous pouvez aussi envisager d’ouvrir un département en interne, mais cette solution est plus onéreuse.

L’importance de l’importance de l’étape de la revue ne doit donc pas être sous-estimée. Surtout au regard de la façon dont la plupart des bibliothèques open source sont bâties et du fait qu’elles ne sont pas signées cryptographiquement. Ce genre de vulnérabilités qui échappent à la vigilance explique, en partie, pourquoi le marché mondial de la cybersécurité devrait avoisiner les 420 milliards de dollars d’ici 2028.

Imaginez une entreprise qui développe son propre logiciel ou son propre service en s’appuyant sur une bibliothèque open source qui n’est pas forcément signée ou qui ne l’est, qu’une fois le logiciel ou le service publié. Or, si des vulnérabilités sont présentes dans les bibliothèques open source, elles peuvent être introduites dans le produit de l’entreprise, même si ce dernier est par ailleurs sécurisé sur le plan cryptographique. La faille dans SolarWinds illustre parfaitement la façon dont une vulnérabilité contenue dans un logiciel peut se propager à d’autres logiciels dépendants du premier. 

Prise en charge des chiffrements cryptographiques forts et des échanges de clés éphémères

La confidentialité persistante, ou Perfect Forward Secrecy (FPS), est un concept cryptographique autour de la sécurité des clés à long terme. En d’autres termes, elle permet de sécuriser les clés de session existantes, même si certaines sessions d’échanges de clés sont compromises. Un peu à la manière d’un réservoir de carburant auto-obturant. Même en cas de violation, l’intégrité de l’ensemble est préservée.

En fait, plusieurs protocoles utilisent une forme de confidentialité persistante, comme IPsec et SSH — deux protocoles fréquemment utilisés dans le monde des messageries. Vous serez également rassurés d’apprendre que TLS 1.3 ne prend pas en charge les chiffrements qui n’intègrent pas une forme de confidentialité persistante — d’où l’importance de le déployer dès que possible. 

Maintien d’une culture du security-by-design

Dans le développement de produits, l’un des principaux problèmes tient à l’équilibre à trouver entre vitesse et sécurité. C’est sur ce point qu’un certain nombre d’entreprises semble rogner sur les processus CI/CD, alors que ces derniers contribuent à maintenir une bonne cybersécurité. Or avec la sophistication croissante des cyberattaques, la situation ne peut que s’aggraver. Ce n’est donc pas en s’en remettant aux autres que le problème disparaîtra.

Il est par conséquent primordial de vous doter d’une culture axée sur la sécurité. C’est la pierre angulaire de votre démarche de sécurité. En anticipant, vous n’aurez pas à mettre en place des mesures de sécurité dans la précipitation lorsque vous serez dans la tourmente.

Les organisations doivent mettre en place un processus simplifié pour le DevSecOps, ainsi que des formations appropriées, et offrir des perspectives de développement des compétences sur ce créneau. Il leur faut, de même, intégrer une étape de signature de code à leur processus CI/CD afin de faciliter la tâche des développeurs non spécialisés dans la cybersécurité. Il s’agit de les aider à créer leurs produits avec un minimum d’interférences et en laissant le moins de place possible au doute. 

Conclusion

Heartbleed a redéfini notre approche des certificats et des bibliothèques open source. Cela dit, de nombreuses organisations doivent encore passer à un système plus moderne et intégrer la sécurité à leur façon d’aborder le développement. L’adoption d’une gestion automatisée des certificats permet aux organisations de réagir beaucoup plus rapidement à ce genre de vulnérabilités et de protéger leurs systèmes et les données de leurs clients.