Les attaques de type « jour zéro » sont en augmentation. Il est temps de planifier une stratégie défensive.

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


Si vous avez déjà été victime d'un cambriolage, vous comprenez ce sentiment initial que quelque chose ne va pas, suivi de la prise de conscience que vous avez bel et bien été volé et violé. 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 domicile soit cambriolé, car les voleurs se sont procuré une clé. Ils s'introduisent, vont et viennent à leur guise, mais prennent 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 a été vidé et que vos effets personnels ont été saccagés. C'est 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 il s'ensuit 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 souhaitait, Log4Shell, est actuellement en train de perturber Internet, avec plus d'un milliard d'appareils qui seraient affectés par cette vulnérabilité critique de Java. Cela s'annonce comme la pire attaque de type « zero-day » jamais enregistrée, et ce n'est que le début. Bien que certains rapports indiquent que les exploits aient 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. De plus, il est extrêmement facile à exploiter, et tous les scénaristes et acteurs de menaces de la planète sont à la recherche de gains grâce à cette vulnérabilité.

Quelle est donc la meilleure voie à suivre pour se prémunir contre une menace insidieuse et insaisissable, sans mentionner les vulnérabilités qui n'ont pas été détectées lors du processus de développement logiciel ? Examinons cela de plus près.

Les attaques « jour zéro » contre des cibles importantes sont peu fréquentes (et coûteuses).

Il existe un marché considérable pour les exploits sur le Dark Web, et les jours zéro ont tendance à être coûteux, pour ne citer qu'un exemple dans cet article évalué à 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.

Cependant, qui dispose de telles ressources financières ? En général, les syndicats de cybercriminels organisés trouvent les fonds nécessaires s'ils le jugent utile, en particulier pour les attaques de ransomware qui sont de plus en plus courantes. 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.

L'année 2021 a vu des records battus en matière de découverte d'exploits zero-day en temps réel, et ce sont les grandes organisations, les services gouvernementaux et les infrastructures qui sont les plus susceptibles d'être sondés afin de détecter d'éventuelles faiblesses. Il n'existe aucun moyen d'être totalement à l'abri d'une attaque zero-day, mais vous pouvez « jouer le jeu » en proposant un programme de bug bounty généreux et bien structuré. Au lieu 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 adéquates 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 exceptionnelle, on peut supposer que vous aurez besoin de plus qu'une carte-cadeau Amazon (et cela en vaudra la peine).

Votre équipement pourrait constituer un obstacle pour votre personnel de sécurité.

La complexité des outils de sécurité constitue un problème de longue date, le RSSI moyen gérant entre 55 et 75 outils dans son 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 du 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 réputé 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é, il est fastidieux d'exiger des professionnels de la sécurité qu'ils travaillent avec une surcharge d'informations sous forme de données, de rapports et de surveillance d'énormes ensembles d'outils. C'est précisément ce type de scénario qui peut les amener à 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 piraté ou exploité.

En rapport avec l'exploit Log4Shell, nous observons 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 n'aurait peut-être pas eu lieu 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'a 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 programme de sécurité efficace 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 conduit à 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, cela pourrait éclipser Heartbleed en termes de persistance et de puissance, compte tenu de son intégration dans des millions d'appareils et de la création de dépendances complexes au sein d'une conception logicielle.

En réalité, il n'existe aucun moyen d'empêcher 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.