Les attaques de type « jour zéro » sont en hausse. Il est temps de planifier un avantage défensif.

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


S'il est déjà arrivé que des voleurs s'introduisent dans votre maison, vous comprendrez ce sentiment initial que quelque chose ne va pas, suivi de la prise de conscience que vous avez bel et bien été volée et violée. Cela entraîne généralement un inconfort durable, sans parler de la nécessité de passer à des mesures de sécurité comparables à celles de Fort Knox.

Imaginez maintenant que votre maison est cambriolée, parce que les voleurs se sont fait une clé. Ils se faufilent, vont et viennent à leur guise, mais font attention à 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 a été vidé et que vos effets personnels ont été saccagés. Il s'agit de la même réalité à laquelle une organisation est confrontée si elle est victime d'une cyberattaque de type « jour zéro ». En 2020, une étude du Ponemon Institute a révélé que 80 % des violations de données réussies étaient le résultat d'exploits zero-day et, malheureusement, la plupart des entreprises ne sont toujours pas équipées pour améliorer de manière significative cette statistique.

Les attaques « jour zéro », par définition, ne laissent pas le temps aux développeurs de détecter et de corriger les vulnérabilités existantes susceptibles d'être exploitées, car c'est l'auteur de la menace qui est intervenu le premier. Le mal est fait et c'est alors une course effrénée pour réparer à la fois le logiciel et l'atteinte à la réputation de l'entreprise. Les attaquants ont toujours un avantage, et il est crucial de réduire cet avantage autant que possible.

Le cadeau de Noël dont personne ne voulait, Log4Shell, fait actuellement exploser Internet, avec plus d'un milliard d'appareils qui seraient affectés par cette vulnérabilité catastrophique de Java. Cela s'annonce comme la pire attaque en 0 jour jamais enregistrée, et nous ne faisons que commencer. Malgré certains rapports indiquant que les exploits avaient commencé quelques jours avant leur divulgation publique, une présentation donnée à la Black Hat Conference en 2016 suggère que ce problème est connu depuis un certain temps. Aïe. Pire encore, elle est extrêmement facile à exploiter, et tous les scénaristes et acteurs de menaces de la planète sont à la recherche de paydirt grâce à cette vulnérabilité.

Quelle est donc la meilleure voie à suivre pour se défendre contre une menace sinistre et glissante, sans parler des vulnérabilités qui n'ont pas été détectées lors du processus de développement logiciel ? Allons y jeter un coup d'œil.

Les attaques « jour zéro » contre de grandes cibles sont rares (et coûteuses)

Il existe un énorme marché pour les exploits sur le Dark Web, et les jours zéro ont tendance à coûter cher, pour ne citer qu'un exemple dans cet article coté pour 2,5 millions de dollars au moment de la rédaction. Signalé comme un exploit d'Apple iOS, il n'est pas surprenant que le prix demandé par le chercheur en sécurité soit exorbitant. 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 le plus longtemps possible avant qu'elles ne soient découvertes et corrigées.

Mais qui a autant d'argent, de toute façon ? En général, les syndicats de cybercriminels organisés trouvent l'argent s'ils le jugent utile, en particulier pour les attaques de rançongiciels toujours plus populaires. Cependant, les gouvernements mondiaux et les départements de la défense font partie de la clientèle pour les exploits qu'ils peuvent utiliser à des fins de renseignement sur les menaces, et dans des scénarios plus positifs, les entreprises elles-mêmes peuvent acheter leurs propres exploits Zero Day potentiels afin de pouvoir atténuer les catastrophes.

2021 a vu des records battus pour la découverte d'exploits zero-day en temps réel, et ce sont les grandes organisations, les services gouvernementaux et les infrastructures qui risquent le plus d'être sondés pour détecter d'éventuelles faiblesses. Il n'y a aucun moyen d'être totalement à l'abri d'une attaque zero-day, mais vous pouvez « jouer le jeu » un peu en proposant un programme de bug bounty généreux et bien structuré. Plutôt que d'attendre que quelqu'un vous offre les clés de votre château de logiciels sur un marché du dark web, faites appel à des professionnels de la sécurité légitimes et offrez-leur des récompenses décentes en cas de divulgation éthique et de correctifs potentiels.

Et s'il s'avère qu'il s'agit d'une menace de jour zéro époustouflante, on peut supposer que vous aurez besoin de plus qu'une carte-cadeau Amazon (et cela en vaudra la peine).

Votre outillage pourrait constituer un handicap pour votre personnel de sécurité

La lourdeur des outils de sécurité pose problème depuis longtemps, le CISO moyen gérant entre 55 et 75 outils dans leur arsenal de sécurité. Outre le fait qu'il s'agit du couteau suisse le plus confus (métaphorique) au monde, 53 % des entreprises ne sont même pas convaincues de travailler efficacement, selon une étude par le Ponemon Institute. Une autre étude a révélé que seulement 17 % des RSSI pensaient que leur solution de sécurité était « totalement efficace ».

Dans un domaine connu pour son épuisement professionnel, son manque de personnel qualifié en matière de 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 forme de données, de rapports et de surveillance d'énormes ensembles d'outils s'avère fastidieux. C'est exactement le type de scénario qui peut leur faire manquer une alerte critique, ce qui a peut-être été le cas lorsqu'il s'est agi d'évaluer correctement les faiblesses de Log4j.

La sécurité préventive doit inclure une modélisation des menaces pilotée 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 développer des compétences de codage sécurisées. Cependant, les développeurs sécurisés de niveau supérieur ont eu l'opportunité 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 possèdent des connaissances approfondies sur la manière dont les utilisateurs interagissent avec celui-ci, sur l'endroit où les fonctionnalités sont utilisées et, lorsqu'ils sont suffisamment conscients de la sécurité, sur les scénarios potentiels dans lesquels il pourrait être cassé ou exploité.

Si nous ramenons cela à 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, mais elle ne se serait peut-être pas produite du tout si la bibliothèque avait été configurée pour assainir les entrées des utilisateurs. La décision de ne pas le faire semble avoir été une fonctionnalité obscure pour plus de commodité, mais l'ont rendu extrêmement facile à exploiter (pensez au niveau de l'injection SQL, ce n'est certainement pas génial). Si la modélisation des menaces avait été réalisée par un groupe de développeurs passionnés et férus de sécurité, il est fort probable que ce scénario aurait été théorisé et envisagé.

Un bon programme de sécurité comporte 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. Les développeurs ne devraient pas être confrontés à cette tâche du jour au lendemain, mais l'idéal est de trouver une voie claire pour les améliorer à un niveau qui leur permette de soulager la pression sur l'équipe de sécurité pour cette tâche importante (et c'est un excellent moyen d'établir des relations entre les deux équipes).

Un jour zéro mène à n jours

La prochaine étape pour faire face à un jour zéro consiste à publier les correctifs le plus rapidement possible, en espérant que chaque utilisateur du logiciel vulnérable les appliquera le plus rapidement possible, et certainement avant qu'un attaquant n'arrive le premier. Avec Log4Shell, ça pourrait éclipser Heartbleed dans son endurance et sa puissance face à son intégration dans des millions d'appareils et à la création de dépendances complexes au sein d'une conception logicielle.

En réalité, il n'existe aucun moyen d'arrêter complètement ce type d'attaque insidieuse. Cependant, si nous nous engageons à utiliser tous les moyens pour créer des logiciels sécurisés et de qualité, et à aborder le développement avec le même état d'esprit que s'il s'agissait d'une infrastructure critique, nous pouvons tous avoir une chance de réussir.