Les attaques de type "zéro jour" se multiplient. Il est temps de planifier un avantage défensif.

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


Si vous avez déjà été victime d'une effraction, vous comprendrez ce sentiment initial d'insécurité, suivi de la prise de conscience que vous avez bel et bien été volé et violé. Il en résulte généralement un malaise durable, sans parler de l'adoption de mesures de sécurité qui rivaliseraient avec celles de Fort Knox.

Imaginez maintenant que votre maison soit violée, parce que les voleurs se sont procuré une clé. Ils se faufilent partout, vont et viennent à leur guise, mais veillent à ne pas se faire repérer. Un jour, vous vous apercevez trop tard que les bijoux que vous aviez cachés dans le congélateur ont disparu, que votre coffre-fort a été vidé et que vos effets personnels ont été saccagés. C'est la réalité à laquelle une organisation est confrontée si elle est victime d'une cyberattaque de type "zero-day". En 2020, une étude de l'Institut Ponemon a révélé que 80 % des violations de données réussies étaient le résultat d'exploits de type "zero-day" et, malheureusement, la plupart des entreprises restent mal équipées pour améliorer de manière significative cette statistique.

Les attaques de type "jour zéro", par définition, ne laissent pas aux développeurs le temps de trouver et de corriger les vulnérabilités existantes qui pourraient être exploitées, parce que l'acteur de la menace est entré en premier. Le mal est fait et c'est alors une course effrénée pour réparer le logiciel et l'atteinte à la réputation de l'entreprise. Les attaquants ont toujours un avantage, et il est crucial de combler cet avantage autant que possible. 

Le cadeau de Noël que personne ne voulait - Log4Shell - fait actuellement exploser l'internet, avec plus d'un milliard d'appareils qui seraient affectés par cette vulnérabilité Java catastrophique. Il s'agit de la pire attaque de type "0day" jamais enregistrée, et elle ne fait que commencer. Bien que certains rapports affirment que les exploits ont commencé quelques jours avant la divulgation publique, une présentation donnée à la conférence Black Hat en 2016 suggère que ce problème était connu depuis un certain temps. C'est un problème connu depuis un certain temps. Pire encore, il est terriblement facile à exploiter, et tous les script kiddies et les acteurs de la menace de la planète sont à la recherche d'un bon filon avec cette vulnérabilité.

Quelle est donc la meilleure voie à suivre pour se défendre contre une menace glissante et sinistre, sans parler des vulnérabilités qui ont été oubliées dans le processus de développement du logiciel ? Jetons un coup d'œil. 

Les attaques de type "zero-day" contre de grandes cibles sont rares (et coûteuses)

Il existe un énorme marché pour les exploits sur le dark web, et les zero-days ont tendance à se vendre à un prix assez élevé, avec un exemple dans cet article listé pour 2,5 millions de dollars au moment de la rédaction de cet article. Il s'agirait d'un exploit d'Apple iOS, et il n'est pas surprenant que le prix demandé par le chercheur en sécurité atteigne des sommets ; après tout, il pourrait s'agir d'une passerelle permettant de compromettre des millions d'appareils, de récolter des milliards de données sensibles, et de le faire aussi longtemps que possible avant qu'il ne soit découvert et corrigé.

Mais qui dispose d'une telle somme d'argent ? En général, ce sont les syndicats de la cybercriminalité qui apportent l'argent si le projet est jugé digne d'intérêt, en particulier pour les attaques par ransomware, toujours très populaires. Toutefois, 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 le renseignement sur les menaces et, dans des scénarios plus positifs, les entreprises elles-mêmes peuvent être des acheteurs de leurs propres exploits potentiels de type "zero-day" afin d'atténuer les désastres. 

En 2021, des records ont été battus en matière de découvertes d'exploits "zero-day", et ce sont les grandes organisations, les administrations et les infrastructures qui risquent le plus d'être sondées à la recherche de faiblesses. Il est impossible d'être totalement à l'abri d'une attaque de type "zero-day", mais vous pouvez "jouer le jeu" en proposant un programme de primes aux bugs généreux et bien structuré. Plutôt que d'attendre que quelqu'un offre les clés du château de votre logiciel sur une place de marché du dark web, mettez de votre côté des passionnés de sécurité légitimes et offrez-leur des récompenses décentes pour la divulgation éthique et les correctifs potentiels.

Et s'il s'agit d'une menace de type "zero-day", on peut supposer que vous devrez débourser plus qu'une carte-cadeau Amazon (et que cela vaudra la peine de le faire).

Votre outillage peut constituer une responsabilité pour votre personnel de sécurité

La lourdeur des outils de sécurité est un problème de longue date, le RSSI moyen gérant entre 55 et 75 outils dans son arsenal de sécurité. En plus d'être le couteau suisse (métaphorique) le plus déroutant au monde, 53 % des entreprises ne sont même pas sûres qu'ils fonctionnent efficacement, selon une étude de l'Institut Ponemon. Une autre étude a révélé que seulement 17 % des RSSI pensaient que leur pile de sécurité était "complètement efficace".

Dans un domaine connu pour son épuisement professionnel, son manque de personnel qualifié en sécurité pour répondre à la demande et son besoin d'agilité, obliger les professionnels de la sécurité à travailler avec une surcharge d'informations sous la forme de données, de rapports et de surveillance d'énormes ensembles d'outils est pesant. C'est exactement le type de scénario qui peut leur faire manquer une alerte critique, ce qui pourrait bien avoir été le cas lorsqu'il s'est agi d'évaluer correctement les faiblesses de Log4j. 

La sécurité préventive doit inclure la modélisation des menaces par les développeurs.

Les vulnérabilités au niveau du code sont souvent introduites par les développeurs, qui ont besoin de conseils précis et de parcours d'apprentissage réguliers pour acquérir des compétences en matière de codage sécurisé. Cependant, les développeurs sécurisés de niveau supérieur ont eu la possibilité 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 leur logiciel soient les développeurs qui l'ont créé. Ils ont une connaissance approfondie de la manière dont les utilisateurs interagissent avec le logiciel, de l'utilisation des fonctionnalités et, s'ils sont suffisamment sensibilisés à la sécurité, des scénarios potentiels dans lesquels le logiciel pourrait se casser ou être exploité.

Si nous revenons à l'exploit Log4Shell, nous assistons malheureusement à un scénario dans lequel une vulnérabilité catastrophique a échappé à la détection par des experts et des ensembles d'outils complexes, alors qu'elle aurait pu ne pas se produire du tout si la bibliothèque avait été configurée pour assainir l'entrée utilisateur. La décision de ne pas le faire semble avoir été une caractéristique obscure pour plus de commodité, mais a rendu l'exploitation douloureusement facile (pensez au niveau de l'injection SQL, certainement pas un truc de génie). Si la modélisation des menaces avait été effectuée par un groupe de développeurs enthousiastes et soucieux de la sécurité, il est très probable que ce scénario aurait été théorisé et envisagé.

Un bon programme de sécurité a une composante émotionnelle, l'intervention humaine et la nuance étant au cœur de la résolution des 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 de l'architecture des logiciels et des applications. Il ne s'agit pas d'une tâche à laquelle les développeurs doivent s'atteler du jour au lendemain, mais l'idéal est de leur offrir une voie claire pour les amener à un niveau où ils pourront soulager l'équipe de sécurité pour cette tâche importante (et c'est un excellent moyen d'établir des relations entre les deux équipes). 

Les jours zéro mènent aux jours n

L'étape suivante de la gestion d'un zero-day consiste à diffuser des correctifs aussi rapidement que possible, en espérant que chaque utilisateur du logiciel vulnérable les applique dès que possible, et certainement avant qu'un attaquant n'y parvienne en premier. Log4Shell pourrait éclipser Heartbleed par son endurance et sa puissance, alors qu'il est intégré dans des millions d'appareils et qu'il crée des dépendances complexes au sein d'un logiciel.

En réalité, il n'existe aucun moyen d'arrêter complètement ce type d'attaque insidieuse. Cependant, en s'engageant à utiliser tous les moyens possibles pour créer des logiciels de qualité et sécurisés, et en abordant le développement avec le même état d'esprit que pour les infrastructures critiques, nous pouvons tous avoir une chance de nous en sortir.