Les attaques zero-day sont en augmentation. Il est temps de planifier une stratégie défensive.

Une version de cet article a été publiée dans Revista SC. Il a été modifié et distribué ici.


Si votre domicile a déjà été cambriolé, vous comprendrez ce sentiment initial d'effondrement, cette impression que quelque chose ne va pas, suivie de la prise de conscience que vous avez effectivement été victime d'un vol et d'une violation de votre intimité. Cela se traduit généralement par un malaise durable, sans parler de la mise en place de mesures de sécurité dignes de Fort Knox.

Imaginez maintenant que votre maison soit cambriolée parce que les voleurs se sont procuré une clé. Ils se déplacent librement, allant et venant à leur guise, mais en prenant soin de ne pas être détectés. Puis, un jour, vous vous rendez compte trop tard que les bijoux que vous aviez cachés dans le congélateur ont disparu, que votre coffre-fort est vide et que vos effets personnels ont été dérobés. C'est la même réalité à laquelle est confrontée une organisation victime d'une cyberattaque de type « zero day ». En 2020, une étude de l'Institut Ponemon a révélé que 80 % des fuites de données réussies étaient le résultat d'exploits de type « zero day » et, malheureusement, la plupart des entreprises restent mal préparées pour améliorer significativement cette statistique.

Les attaques zero-day, par définition, ne laissent pas le temps aux développeurs de détecter et de corriger les vulnérabilités existantes qui pourraient être exploitées, car l'auteur de la menace a été le premier à s'introduire. Le mal est déjà fait et il faut alors s'atteler à réparer les dommages causés tant au logiciel qu'à la réputation de l'entreprise. Les attaquants ont toujours un avantage, et il est essentiel de réduire cet avantage autant que possible.

Le cadeau de Noël dont personne ne souhaitait faire l'objet, Log4Shell, est actuellement en train de perturber Internet, et il est estimé que plus d'un milliard d'appareils sont affectés par cette vulnérabilité catastrophique de Java. Cela s'annonce comme la pire attaque jamais enregistrée en une seule journée, et ce n'est que le début. Malgré certains rapports affirmant que les exploits ont commencé quelques jours avant leur divulgation publique, une présentation faite lors de la Black Hat Conference en 2016 suggérerait que ce problème est connu depuis un certain temps. De plus, il est extrêmement facile à exploiter, et tous les scénaristes et acteurs malveillants de la planète cherchent à tirer profit de cette vulnérabilité.

Alors, quelle est la meilleure approche pour se prémunir contre une menace insidieuse et insaisissable, sans oublier les vulnérabilités qui ont été négligées dans le processus de développement logiciel ? Examinons cela.

Les attaques « zero-day » contre des cibles importantes sont rares (et coûteuses).

Il existe un vaste marché d'exploits sur le dark web, et les exploits zero-day peuvent atteindre des montants considérables. Par exemple, dans cet article, leur valeur était estimée à 2,5 millions de dollars au moment de la rédaction. Il s'agirait d'une vulnérabilité du système iOS d'Apple, il n'est donc pas surprenant que le chercheur en sécurité soit enthousiaste ; après tout, cela pourrait constituer une porte d'entrée pour compromettre des millions d'appareils, collecter des milliards d'enregistrements de données confidentielles et le faire le plus longtemps possible avant d'être découvert et corrigé.

Cependant, qui dispose d'une telle somme d'argent ? En général, les syndicats organisés de cybercriminalité s'approprient l'argent s'ils le jugent intéressant, en particulier pour les attaques par ransomware, qui sont de plus en plus courantes. Cependant, les gouvernements et les ministères de la défense du monde entier font partie de la clientèle des exploits qu'ils peuvent utiliser pour obtenir des informations sur les menaces et, dans des scénarios plus positifs, les entreprises elles-mêmes peuvent acheter leurs propres vulnérabilités potentielles de type « zero-day » afin d'atténuer les catastrophes.

En 2021, des records ont été battus en matière de découverte d'exploits en temps réel à partir de zéro, et ce sont les grandes organisations, les services gouvernementaux et les infrastructures qui courent le plus grand risque d'être examinés à la recherche de failles. Il n'existe aucun moyen d'être totalement à l'abri d'une attaque de type « zero day », mais il est possible de « jouer » d'une certaine manière en proposant un programme de récompense généreux et bien structuré pour les erreurs. Au lieu d'attendre que quelqu'un vous remette les clés de votre château logiciel sur un marché du dark web, recherchez des améliorations légitimes en matière de sécurité et offrez des récompenses adéquates pour la divulgation éthique et les solutions possibles.

Et s'il s'agit d'une menace grave de type « jour zéro », il ne fait aucun doute que vous devrez investir davantage qu'une simple carte cadeau Amazon (et cela en vaudra la peine).

Vos outils pourraient constituer une responsabilité pour votre personnel de sécurité.

Les outils de sécurité complexes constituent un problème depuis longtemps, et le responsable de la sécurité des systèmes d'information (RSSI) gère en moyenne entre 55 et 75 outils dans son arsenal de sécurité. En plus d'être le couteau suisse le plus déroutant (au sens figuré) au monde, 53 % des entreprises ne sont même pas certaines qu'ils fonctionnent efficacement, selon une étude de l'Institut Ponemon. Une autre étude a révélé que seuls 17 % des RSSI estimaient que leur système de sécurité était « totalement efficace ».

Dans un domaine connu pour son épuisement, le manque de personnes qualifiées en sécurité pour répondre à la demande et le besoin d'agilité obligent les professionnels de la sécurité à travailler avec une surcharge d'informations sous forme de données, de rapports et de surveillance d'énormes ensembles d'outils, ce qui constitue une charge importante. C'est précisément ce type de scénario qui peut les amener à manquer une alerte critique, ce qui aurait très bien pu être le cas lorsqu'il s'agissait d'évaluer correctement les vulnérabilités de Log4j.

La sécurité préventive doit inclure des modèles de menaces développés par les développeurs.

Les développeurs introduisent souvent des vulnérabilités au niveau du code et ont besoin de conseils précis et de formations régulières pour développer des compétences en codage sécurisé. Cependant, les développeurs de systèmes sécurisés avancés ont eu l'occasion d'apprendre et de pratiquer la modélisation des menaces dans le cadre de leur processus de création de logiciels.
‍
Il n'est pas surprenant que les personnes qui connaissent le mieux votre logiciel soient les développeurs qui l'ont créé. Ils ont une connaissance approfondie de la manière dont les utilisateurs interagissent avec celui-ci, des endroits où les fonctionnalités sont utilisées et, lorsqu'ils sont suffisamment sensibilisés à la sécurité, des scénarios possibles dans lesquels il pourrait échouer ou être exploité.

Si nous revenons à l'exploit Log4Shell, nous sommes malheureusement confrontés à une situation où les experts et les ensembles d'outils complexes n'ont pas été en mesure de détecter une vulnérabilité catastrophique ; cependant, celle-ci n'aurait peut-être pas eu lieu si la bibliothèque avait été configurée pour désinfecter les entrées des utilisateurs. La décision de ne pas le faire semble avoir été une fonctionnalité peu connue pour plus de commodité, mais elle a rendu l'exploitation extrêmement facile (pensez au niveau d'injection SQL, certainement pas à des choses géniales). Si la modélisation des menaces avait été réalisée par un groupe de développeurs passionnés et experts en sécurité, il est très probable que ce scénario aurait été théorisé et pris en compte.

Un programme de sécurité efficace comporte une composante émotionnelle, dans laquelle l'intervention et les nuances humaines sont essentielles pour résoudre les problèmes créés par l'homme. La modélisation des menaces nécessite de l'empathie et de l'expérience pour être efficace, tout comme le codage et la configuration sécurisés au niveau architectural des logiciels et des applications. Ce n'est pas quelque chose que les développeurs doivent entreprendre du jour au lendemain, mais l'idéal est de trouver un moyen clair d'améliorer leurs compétences jusqu'à un niveau où ils peuvent soulager la pression exercée sur l'équipe de sécurité pour accomplir cette tâche importante (et c'est un excellent moyen d'établir une bonne relation entre les deux équipes).

Les jours zéro conduisent à n jours

La prochaine étape pour faire face à un jour zéro consiste à déployer les correctifs le plus rapidement possible, dans l'espoir que tous les utilisateurs du logiciel vulnérable les appliquent dès que possible et, bien sûr, avant qu'un attaquant n'y parvienne en premier. Avec Log4Shell, il pourrait surpasser Heartbleed en termes de résistance et de puissance, étant donné qu'il est intégré à des millions d'appareils et crée des dépendances complexes dans une compilation de logiciels.

En étant réalistes, il n'existe aucun moyen d'empêcher complètement ce type d'attaque insidieuse. Cependant, si nous nous engageons à utiliser tous les moyens possibles pour créer des logiciels sûrs et de qualité, et à aborder le développement avec le même état d'esprit que pour les infrastructures critiques, nous pouvons tous avoir une chance de lutter.