Les attaques zero-day sont en augmentation. Il est temps de renforcer votre stratégie de défense.

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


Si vous avez déjà été victime d'un cambriolage, vous connaissez ce sentiment d'abattement initial, cette intuition que quelque chose ne va pas, suivie de la réalisation brutale que vous avez été volé et violé dans votre intimité. Cela laisse généralement un malaise durable, sans parler du besoin immédiat de renforcer sa sécurité au point de transformer son domicile en Fort Knox.

Imaginez maintenant que votre domicile soit cambriolé parce que les voleurs ont fabriqué un double de vos clés. Ils rôdent, vont et viennent à leur guise, en prenant soin de ne pas se faire remarquer. Puis, un jour, vous réalisez, bien trop tard, que les bijoux cachés dans le congélateur ont disparu, que votre coffre-fort a été vidé et que vos effets personnels ont été fouillés. C'est la réalité à laquelle une organisation est confrontée lorsqu'elle est victime d'une cyberattaque « zero-day ». 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 ». Malheureusement, la plupart des entreprises restent mal équipées pour améliorer significativement cette statistique.

Par définition, les attaques « zero-day » ne laissent aucun répit aux développeurs pour identifier et corriger les vulnérabilités exploitables, car les attaquants ont toujours une longueur d'avance. Une fois les dégâts causés, c'est la course contre la montre pour réparer le logiciel et limiter l'impact sur la réputation de l'entreprise. Les attaquants conservent un avantage permanent ; il est donc crucial de réduire cet écart autant que possible.

Le cadeau de Noël dont personne ne voulait — Log4Shell — secoue actuellement Internet, avec plus d'un milliard d'appareils potentiellement affectés par cette vulnérabilité Java catastrophique. Tout porte à croire qu'il s'agit de la pire attaque « zero-day » jamais enregistrée, et nous ne sommes qu'au début. Malgré certains rapports indiquant que les exploits ont commencé quelques jours avant la divulgation publique, une présentation donnée lors de la conférence Black Hat en 2016 suggère que ce problème était connu depuis un certain temps. Aïe. Pire encore, l'exploitation est d'une simplicité déconcertante, et chaque apprenti pirate ou cybercriminel de la planète cherche à tirer profit de cette vulnérabilité.

Alors, quelle est la meilleure stratégie pour se défendre contre une menace aussi insaisissable et sinistre, sans oublier les vulnérabilités qui passent entre les mailles du filet lors du développement logiciel ? Faisons le point.

Les attaques « zero-day » contre les grandes cibles sont rares (et coûteuses)

Il existe un marché immense pour les exploits sur le dark web, et les « zero-days » se vendent à prix d'or. Un exemple cité dans cet article mentionnait un prix de 2,5 millions de dollars au moment de la rédaction. S'agissant d'un exploit visant Apple iOS, il n'est pas surprenant que le chercheur en sécurité demande une somme astronomique ; après tout, cela pourrait être la porte d'entrée pour compromettre des millions d'appareils, récolter des milliards de données sensibles et agir aussi longtemps que possible avant toute découverte et correction.

Mais qui dispose d'un tel budget ? En général, les syndicats du crime organisé déboursent ces sommes si l'investissement en vaut la peine, notamment pour les attaques par ransomware, toujours très populaires. Cependant, les gouvernements et les ministères de la Défense comptent parmi les clients pour des exploits utilisables à des fins de renseignement. Dans des scénarios plus positifs, les entreprises elles-mêmes peuvent racheter leurs propres vulnérabilités « zero-day » potentielles afin de prévenir tout désastre.

L'année 2021 a battu des records en matière de découvertes d'exploits « zero-day » actifs, et ce sont les grandes organisations, les administrations publiques et les infrastructures critiques qui sont les plus exposées. Il est impossible de se protéger totalement contre une attaque « zero-day », mais vous pouvez « jouer le jeu » en proposant un programme de bug bounty généreux et bien structuré. Plutôt que d'attendre que quelqu'un mette en vente les clés de votre château logiciel sur le dark web, ralliez à votre cause des experts en sécurité légitimes et offrez-leur des récompenses décentes pour une divulgation éthique et des correctifs potentiels.

Et s'il s'agit d'une menace « zero-day » particulièrement alarmante, attendez-vous à devoir offrir bien plus qu'une simple carte-cadeau Amazon (et cela en vaudra largement la peine).

Vos outils pourraient devenir un handicap pour vos équipes de sécurité

Les outils de sécurité encombrants sont un problème de longue date, le CISO moyen gérant entre 55 et 75 outils dans son arsenal. En plus de ressembler au couteau suisse le plus confus au monde, 53 % des entreprises ne sont même pas convaincues de leur efficacité, selon une étude du Ponemon Institute. Une autre étude a révélé que seulement 17 % des CISO considéraient leur pile de sécurité comme « totalement efficace ».

Dans un domaine connu pour son taux d'épuisement professionnel, la pénurie de talents qualifiés et le besoin d'agilité, forcer les professionnels de la sécurité à gérer une surcharge d'informations — données, rapports et surveillance d'outils pléthoriques — est un fardeau. C'est précisément ce type de scénario qui peut les amener à manquer une alerte critique, ce qui a probablement été le cas lors de l'évaluation des 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 renforcer leurs compétences en codage sécurisé. Cependant, les développeurs les plus avancés ont eu l'opportunité d'apprendre et de pratiquer la modélisation des menaces dans le cadre de leur processus de création logicielle.
‍
Il n'est pas surprenant que les personnes connaissant le mieux leur logiciel soient celles qui l'ont conçu. Elles possèdent une connaissance approfondie de la manière dont les utilisateurs interagissent avec le produit, de l'utilisation des fonctionnalités et, avec une sensibilisation adéquate à la sécurité, des scénarios potentiels où le système pourrait faillir ou être exploité.

Si l'on revient à l'exploit Log4Shell, nous sommes malheureusement face à un scénario où une vulnérabilité catastrophique a échappé à la détection des experts et des outils complexes. Pourtant, elle ne se serait peut-être jamais produite si la bibliothèque avait été configurée pour assainir les entrées utilisateur. La décision de ne pas le faire semble avoir été une fonctionnalité obscure ajoutée pour plus de commodité, mais elle a rendu l'exploitation d'une simplicité déconcertante (pensez au niveau d'une injection SQL, rien de génial). Si une modélisation des menaces avait été effectuée par un groupe de développeurs passionnés et avertis en matière de sécurité, il est fort probable que ce scénario aurait été anticipé et pris en compte.

Un excellent programme de sécurité comporte une dimension émotionnelle, plaçant l'intervention humaine et la nuance au cœur de la résolution de problèmes créés par l'homme. La modélisation des menaces exige de l'empathie et de l'expérience pour être efficace, tout comme le codage sécurisé et la configuration au niveau architectural des logiciels et des applications. Ce n'est pas quelque chose dans lequel les développeurs doivent être plongés du jour au lendemain, mais un parcours clair pour les faire monter en compétences — afin qu'ils puissent soulager l'équipe de sécurité sur cette tâche cruciale — est idéal (et c'est un excellent moyen de renforcer la collaboration entre les deux équipes).

Les « zero-days » mènent aux « n-days »

L'étape suivante face à une faille zero-day consiste à déployer des correctifs aussi rapidement que possible, en espérant que chaque utilisateur du logiciel vulnérable les installe sans tarder, et surtout avant qu'un attaquant ne frappe. Avec Log4Shell, les conséquences pourraient surpasser celles de Heartbleed en raison de sa persistance et de sa puissance, étant donné qu'il est intégré dans des millions d'appareils et qu'il crée des dépendances complexes au sein des architectures logicielles.

En réalité, il est impossible de stopper totalement ce type d'attaque insidieuse. Cependant, en nous engageant à utiliser tous les moyens à notre disposition pour créer des logiciels sécurisés et de qualité, et en abordant le développement avec la même rigueur que pour les infrastructures critiques, nous pouvons tous avoir une chance de nous défendre.