Log4shell, en conclusion, il est impératif de durcir la conception et le logiciel autant que les infrastructures
Les chapitres précédents, nous ont conduits, tour à tour:
- à exposer les faits au sujet des vulnérabilités d’un composant open source JAVA préfabriqué très populaire;
- à rappeler le traitement ordinaire de ces vulnérabilités par les activités de patch management;
- à démontrer le bien-fondé d’éradiquer les faiblesses de code, qui sont les causes qui engendrent les vulnérabilités, en utilisant une analyse des menaces de sécurité, nommée STRIDE
A partir d’un exemple d’actualité de la fin 2021: “les failles Log4J” nous avons exposé les limites des anciennes pratiques de sécurité et la nécessité de ne pas demeurer au milieu du gué. Les pratiques de détection des vulnérabilités sur des applications et des infrastructures en opération sont nécessaires mais ne suffisent pas. Le patch management pour colmater les brèches est compliqué et lent. L’utilisation très fréquente de composants préfabriqués, open source ou commerciaux, impose d’anticiper les vulnérabilités en amont, lors du développement du code de l’application et lors de l’assemblage des composants.
Par conséquent, la modélisation des menaces doit être systématique, pragmatique et intégrée aux développements logiciels afin de détecter et de traiter les faiblesses de code connues sans attendre la détection des vulnérabilités. Cette méthode est préférable à un éventuel Bug Bounty déclenché après une mise en production.
Un autre argument fort est directement lié à la transformation numérique et à l’utilisation des conteneurs d’application. Rappelons qu’un conteneur d’application est une petite machine virtuelle qui utilise les ressources et les fonctionnalités de gestion d’un orchestrateur comme Kubernetes. L’aspect remarquable est qu’un conteneur ne se patche pas. En conséquence, le colmatage de vulnérabilités par du patch management n’a aucun sens.
Ajoutons que, dans un monde sans confiance, dit Zero Trust, il s’agit de sécuriser la conception, de durcir le code, de réceptionner les composants préfabriqués et d’utiliser uniquement ceux qui sont fiables.
A l’heure de la mobilité, de l’utilisation massive du cloud, de l’émergence de nouveaux services financiers, des paiements mobiles, du télétravail, de la co-création, la stratégie de la poussière sous le tapis, qui encensait des croyances erronées telles que “notre forteresse imprenable nous protégera”, est devenue à la fois obsolète et dangereuse puisque les terminaux, qui contiennent une partie des données et qui exécutent une partie des traitements, sont très exposés et le plus souvent hors des murs de l’entreprise. Pensons à l’utilisation que nous faisons des suites collaboratives qui sont disponibles, en même temps, sur nos smartphones, sur nos ordinateurs portables, sur nos tablettes.
En Europe, notre aptitude à accepter la sécurisation du code est équivalente à notre capacité à réussir un déploiement compétitif de la 5G et des services associés.
