Veuillez prendre en compte les attaques zero-day. Il est temps de planifier une ligne 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 chez vous, vous comprendrez ce sentiment initial que quelque chose ne va pas, suivi de la prise de conscience que vous avez effectivement été volé et blessé. Cela s'accompagne généralement de plaintes persistantes, qui ne s'apaisent qu'après la mise en place de mesures de sécurité dignes de Fort Knox.

Imaginez que votre domicile soit cambriolé parce que les voleurs ont fabriqué une clé. Ils se déplacent discrètement, vont et viennent à leur guise, mais veillent à ne pas être découverts. 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é pillés. C'est la réalité équivalente, avec une entreprise impliquée, si elle propose des cyberattaques Zero-Day. En 2020, une étude du Ponemon Institute a révélé que 80 % des violations de la vie privée réussies étaient le résultat d'exploits Zero-Day, et la plupart des entreprises sont malheureusement mal équipées pour améliorer significativement ces statistiques.

Par définition, les attaques zero-day ne laissent pas le temps aux développeurs de détecter et de corriger les failles de sécurité existantes qui pourraient être exploitées, car l'auteur de la menace a déjà pénétré le système. Les dommages sont causés, ce qui entraîne des conséquences considérables, tant pour le logiciel que pour 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 l'Internet. Environ un milliard d'appareils seraient affectés par cette faille de sécurité Java catastrophique. Cela s'annonce comme la pire attaque 0-day de tous les temps, et nous n'en sommes qu'au début. Malgré certains rapports indiquant que les exploits ont commencé quelques jours avant la publication, une présentation lors de la Black Hat Conference en 2016 suggère que ce problème est connu depuis un certain temps. Cela est préoccupant. Pire encore, cette faille est extrêmement facile à exploiter, et tous les pirates informatiques et acteurs malveillants de la planète s'y intéressent.

Quelle est donc la meilleure façon de se protéger contre une menace insidieuse et obscure, sans parler des failles de sécurité qui ont été négligées dans le processus de développement logiciel ? Examinons cela de plus près.

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

Le Dark Web abrite un vaste marché pour les exploits, et les zero-days coûtent généralement une somme considérable. À titre d'exemple , au moment de la rédaction de cet article, ils étaient cotés à 2,5 millions de dollars. Il s'agit d'un exploit d'Apple iOS, et il n'est pas surprenant que le prix demandé par le chercheur en sécurité soit exorbitant. Après tout, cela pourrait permettre de compromettre des millions d'appareils, de collecter des milliards d'enregistrements de données sensibles et de le faire aussi longtemps que possible avant d'être découvert et corrigé.

Cependant, qui dispose d'une telle somme d'argent ? En règle générale, les syndicats organisés de cybercriminels renoncent à l'argent lorsqu'ils le jugent nécessaire, en particulier dans le cas des attaques par ransomware, très répandues. Les gouvernements et les autorités de défense du monde entier comptent toutefois parmi les clients des exploits, qu'ils peuvent utiliser pour obtenir des informations sur les menaces. Dans les cas positifs, les entreprises pourraient elles-mêmes être les exploits zero-day potentiels permettant d'éviter des catastrophes.

En 2021, des records ont été battus en matière de découverte en direct d'exploits zero-day, et ce sont les grandes organisations, les autorités gouvernementales et les infrastructures, qui sont les plus exposées, qui sont testées pour détecter leurs vulnérabilités. Il n'existe aucun moyen de se protéger complètement contre les attaques zero-day, mais vous pouvez « jouer le jeu » dans une certaine mesure en proposant un programme de prime aux bogues généreux et bien structuré. Au lieu d'attendre que quelqu'un vous offre la clé de votre château logiciel sur un marché du Dark Web, invitez des passionnés de sécurité légitimes sur votre page et offrez-leur des récompenses pertinentes pour leurs révélations éthiques et leurs corrections éventuelles.

Et si une menace de type « zero-day » venait à se présenter, vous pouvez être certain que vous devrez émettre plus d'une carte-cadeau Amazon (et cela en vaudra la peine).

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

Les outils de sécurité permanents constituent depuis longtemps un défi, le responsable de la sécurité des systèmes d'information (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 déroutant (au sens figuré) au monde, 53 % des entreprises ne sont même pas convaincues de son efficacité, selon une étude du Ponemon Institute. Une autre étude a révélé que seuls 17 % des RSSI estimaient que leur pile de sécurité était « totalement efficace ».

Dans un domaine réputé pour son épuisement professionnel, le manque de spécialistes en sécurité pour répondre à la demande et le besoin d'agilité, il est difficile de contraindre les experts en sécurité à travailler avec un flux d'informations sous forme de données, de rapports et d'outils de surveillance volumineux. C'est précisément le type de scénario qui peut les amener à négliger une alerte critique, ce qui a été le cas lorsqu'il s'agissait d'examiner correctement les faiblesses de Log4j.

La sécurité préventive devrait inclure une modélisation des menaces axée sur les développeurs.

Les développeurs ont souvent recours à des failles de sécurité au niveau du code et ont besoin d'instructions précises et d'un parcours d'apprentissage régulier pour acquérir des connaissances en matière de programmation sécurisée. Les développeurs de sécurité de niveau supérieur ont la possibilité d'apprendre et de s'exercer dans le cadre de leur processus de développement logiciel.
‍
Il n'est pas surprenant que les personnes qui connaissent le mieux leur logiciel soient les développeurs qui l'ont créé et développé. Ils possèdent une connaissance approfondie de la manière dont les utilisateurs interagissent avec le logiciel, des domaines dans lesquels les fonctionnalités sont utilisées et, s'ils sont suffisamment sensibilisés à la sécurité, des scénarios potentiels dans lesquels le logiciel pourrait être compromis ou exploité.

En revenant à l'exploit Log4Shell, nous observons un scénario dans lequel une faille de sécurité catastrophique n'a pas été détectée par les experts et les outils complexes. Cependant, elle n'aurait peut-être pas eu lieu si la bibliothèque avait été configurée pour agréger les entrées utilisateur. Cette décision semble avoir été motivée par des raisons pratiques, mais elle a rendu l'exploitation extrêmement facile (pensez au niveau d'injection SQL, ce qui n'est certainement pas très ingénieux). Si la modélisation des menaces avait été réalisée par un groupe de développeurs passionnés et soucieux de la sécurité, ce scénario aurait très probablement été théorisé et mis en pratique.

Un programme de sécurité efficace comporte une composante émotionnelle, dans laquelle l'intervention humaine et les nuances sont au cœur de la résolution des problèmes causés par les personnes. 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 des logiciels et des applications au niveau de l'architecture. Les développeurs ne doivent pas travailler de nuit, mais il est préférable qu'ils indiquent clairement qu'ils peuvent confier cette tâche importante à l'équipe de sécurité (ce qui permet également de créer une excellente relation entre les deux équipes).

Les jours nuls conduisent à des jours N.

La phase suivante du processus avec un Zero-Day consiste à fournir des correctifs aussi rapidement que possible, dans l'espoir que chaque utilisateur du logiciel vulnérable les installe aussi rapidement que possible, et dans tous les cas, avant le fournisseur. Log4Shell pourrait éclipser Heartbleed en termes de persistance et de puissance, étant donné qu'il est intégré à des millions d'appareils et qu'il crée des dépendances complexes au sein d'une version logicielle.

D'un point de vue réaliste, il n'existe aucun moyen d'empêcher complètement ce type d'attaques furtives. Cependant, si nous nous engageons à exploiter toutes les possibilités pour développer des logiciels de haute qualité et sécurisés, et si nous abordons le développement avec la même approche que celle utilisée pour les infrastructures critiques, nous pouvons tous avoir une chance réelle.