Transcription

• Speaker #0

  Bonjour mamie, bonjour et bienvenue dans la cybersécurité expliquée à ma grand-mère, le podcast pour expliquer la cybersécurité à des gens qui n'y prennent rien. Pour certains, la phrase de Socrate Connais-toi toi-même est l'un des plus grands trésors de l'humanité. Et c'est très certainement aussi l'un des principes les plus importants en matière de cybersécurité. Elle est une invitation à se connaître soi-même, à explorer son être intérieur, à découvrir ses forces et ses faiblesses, ses valeurs, ses croyances et ses limites. En matière de cybersécurité, cette invitation prend tout son sens, car il est crucial de comprendre ses vulnérabilités pour protéger efficacement ses données et ses systèmes. Cependant, la tâche de se connaître soi-même peut être difficile, car il est parfois difficile de prendre du recul et de faire preuve d'objectivité sur ses propres compétences et faiblesses. De plus, les attaques informatiques sont de plus en plus sophistiquées et complexes, ce qui rend la tâche encore plus difficile. Même s'il semble assez logique que connaître ses forces et ses faiblesses est forcément nécessaire en matière de cybersécurité, vous ne soupçonnez peut-être pas à quel point cela peut devenir un but inatteignable. Mais commençons par le commencement. Pourquoi et surtout comment se connaître soi-même ? Que votre système d'information se compose d'un simple ordinateur ou d'un centre de calcul rempli de centaines de machines, nous sommes tous soumis à la même contrainte. Pour contrôler son système d'information, il faut le connaître. Mais quelles sont les informations importantes à prendre en compte ? Avoir une cartographie exhaustive de son système d'information est crucial pour la cybersécurité. car cela permet de mieux comprendre l'environnement technologique dans lequel les données de l'entreprise sont stockées, gérées et traitées. Généralement, ces informations se trouvent dans la CMDB, CMDB pour Configuration Management Database. C'est une base de données qui contient des informations sur tous les éléments de configuration d'un système d'information, y compris les serveurs, les applications, les équipements de réseau, les bases de données, les utilisateurs et les autorisations. Pour la sécurité, une CMDB doit pouvoir identifier les éléments suivants. Les éléments techniques, c'est-à-dire la version du système d'exploitation, mais aussi les fournisseurs qui interviennent sur cet élément technique. Il y a aussi d'éventuelles informations sur la version du framework utilisé..NET par exemple est un langage très populaire qui utilise un framework qui nécessite parfois des mises à jour. Enfin bref, on doit y trouver facilement toutes les informations techniques utiles pour la bonne gestion du cycle de vie du composant. Autant dire qu'il est très judicieux d'être le plus exhaustif possible. On doit y trouver aussi des indications de criticité. Ce sont les composants qui peuvent contenir des informations sur les éléments critiques du système d'information, tels que les serveurs de bases de données, les serveurs d'applications, les équipements de sécurité, les pare-feux, les systèmes de surveillance, etc. Mais il faut faire la distinction entre les différents critères de criticité. Souvenez-vous qu'il y a principalement trois critères à prendre en compte, la disponibilité, l'intégrité et la confidentialité. Certains composants de votre système d'information peuvent être critiques d'un point de vue de la disponibilité, alors qu'ils ne sont pas du point de vue de la confidentialité. Ainsi, il est fort probable d'avoir différentes définitions de la criticité dans la CMDB. Certains critères seront plus techniques que business. On trouve par exemple la classification des données pour identifier les systèmes contenant des données confidentielles. La CMDB doit contenir des informations sur les relations entre les éléments du système, notamment les dépendances entre les différents composants. Cela permet de mieux comprendre les flux de données et d'identifier les risques potentiels. La cartographie des flux est essentielle à bien des égards. part pour comprendre les impacts éventuels en cas de compromission de votre système d'information. On va voir un exemple très concret dans quelques instants. Mais c'est très utile aussi en cas de modification à mener. Et c'est très certainement le cas d'une migration. C'est un peu comme si dans votre maison, vous n'ayez aucune connaissance de l'endroit où passent les câbles électriques, les tuyaux de gaz ou d'eau. Sans cette information, il y a fort à parier que le moindre trou à faire dans un mur pose problème. Et bien là, il en va de même pour votre système d'information. Si vous n'avez pas une vue claire et exhaustive de la cartographie des flux, il va être très difficile de faire une modification sans risque. On doit aussi y trouver les autorisations d'accès. La CMDB doit contenir des informations sur les autorisations d'accès pour chaque élément du système, y compris les utilisateurs et les groupes d'utilisateurs. Cela permet de contrôler les accès et de limiter les droits d'accès pour réduire les risques d'attaque. On doit y trouver aussi les changements de configuration. La CMDB doit contenir des informations sur les changements de configuration, notamment les modifications apportées aux éléments du système et les raisons de ces modifications. Cela permet de suivre l'évolution du système et d'identifier les erreurs éventuelles ou les modifications malveillantes. Et pour finir, les rapports et les analyses. La CMDB doit être capable de générer des rapports pour permettre rapidement d'extraire des informations dans le cas d'une analyse. Cela permet par exemple d'identifier facilement des composants prochainement obsolètes. Cette cartographie permet de répondre à plusieurs objectifs en matière de cybersécurité. Identifier les vulnérabilités dans un premier temps. Une cartographie exhaustive permet de recenser tous les éléments du système d'information. Elle permet également d'identifier les points d'entrée potentiels pour les attaquants et les vulnérabilités du système. Les vulnérabilités sont souvent liées à une version spécifique d'un composant logiciel. Avoir cette information permet donc rapidement d'identifier les composants potentiellement vulnérables. Cela permet aussi de prioriser les mesures de sécurité. En identifiant les éléments les plus critiques du système, une cartographie permet de prioriser les mesures de sécurité à mettre en place pour protéger ces éléments. Par exemple, si une base de données contient des informations très sensibles, Des mesures de sécurité supplémentaires peuvent être mises en place pour la protéger. Cela permet aussi de gérer les autorisations d'accès. Une cartographie exhaustive permet de mieux comprendre les autorisations d'accès de chaque utilisateur ou groupe d'utilisateurs. Il est donc plus facile de contrôler les accès et de limiter les droits d'accès des utilisateurs pour réduire les risques d'attaque. Cela permet aussi de faciliter la réponse aux incidents. En ayant une vue d'ensemble complète du système d'information, il est plus facile de réagir rapidement en cas d'incident de sécurité. car il est possible de localiser rapidement la source du problème et de déterminer les mesures à prendre. En somme, une cartographie exhaustive de son système d'information est essentielle pour comprendre les risques et les vulnérabilités de son infrastructure technologique, afin de mieux la protéger contre les attaques potentielles. En résumé, c'est important de savoir où sont les choses.

• Speaker #1

  Oui mon pendu ! On m'a dépendu mon pendu ! Il est dépendu là ! Vraiment c'est incroyable ! Qu'est-ce que je te dis ? Il s'est pas dépendu, c'est tout seul ! Excusez-moi madame. Il faut qu'on me le retrouve ! Il faut qu'on me le retrouve ! Je ne sors pas de là, il faut qu'on me le retrouve ! Monsieur le commissaire a perdu quelque chose. J'ai perdu mon pendu, il faut qu'on me le retrouve, vous entendez ? Il faut qu'on me le retrouve ! Je puis assurer à monsieur le commissaire que je n'ai rangé aucun pendu dans sa chambre. Il se fout toujours de moi celui-là ? Non, monsieur le commissaire. D'ailleurs, je ne fais jamais le ménage, passez 10h du soir.

• Speaker #0

  L'un des plus bels exemples qui montre l'intérêt de maîtriser son inventaire dans les détails est la gestion de la vulnérabilité Lock4Shell. L'attaque Lock4Shell a été une vulnérabilité de sécurité critique qui a touché le framework de logging open source Apache Lock4J. Ce framework est largement utilisé dans les environnements Java. Cette vulnérabilité a été découverte en novembre 2021 et a été considéré comme l'une des plus grandes failles de sécurité de la dernière décennie. En termes de nombre d'attaques, il est difficile de quantifier le nombre exact d'attaques qui ont été menées à l'aide de Lockford Shell. Cependant, des milliers d'organisations à travers le monde ont été touchées par cette vulnérabilité, ce qui en fait l'une des plus grandes attaques informatiques de l'histoire. Les chercheurs en cybersécurité ont signalé que les attaques étaient en cours dès le premier jour de la divulgation de la vulnérabilité. Et il est probable que de nombreux autres ont eu lieu depuis. De nombreuses entreprises, organisations gouvernementales et institutions financières ont été touchées par l'attaque Lock4Shell, dont Microsoft, Apple, Amazon, l'Agence Européenne de la Sécurité des Réseaux et de l'Information, l'ENISA, Dutch Bank et de nombreuses autres entreprises et organisations. Mais comment une faille de sécurité peut-elle avoir un impact si important ? Il y a plusieurs raisons à cela. Par cette faille provient d'un composant logiciel appelé Lock4J. C'est une librairie très largement utilisée dans la communauté Java pour loguer des informations. Java est un langage très populaire. Il a été conçu dans les années 90 par deux Américains, Jeff Köstling et Patrick Nothorn, employés tous les deux chez Sun Microsystems. Ce langage était novateur à bien des égards. D'une part, Java est un langage de haut niveau orienté objet. Bon, peut-être que pour la plupart d'entre vous, ça n'évoque pas grand-chose. On classe les langages de programmation en différentes catégories. Plus le langage est proche de la machine, c'est-à-dire que vous allez demander directement au processeur d'exécuter des instructions, et plus on va qualifier ces langages de bas niveau. A contrario, quand un langage permet de manipuler des concepts plus évolués, et plus on va se détacher de la machine. Il existe plein de paradigmes différents, comme par exemple l'impératif. Dans ce cas, le langage contient un ensemble d'instructions de contrôle de flux d'exécution, qui permet de contrôler l'ordre dans lequel les exécutions se font. C'est l'exemple du C, du Pascal, du Fortran ou du Cobol. Le C, le Pascal, le Fortran et le Cobol sont des exemples de langage de programmation qui implémentent le paradigme impératif. C'est un peu comme une recette de cuisine, faire telle et telle action, et en fonction du résultat, faire telle action à la place d'une autre. Le paradigme orienté objet est destiné à faciliter le découpage d'un grand programme en plusieurs modules isolés les uns des autres. Il introduit la notion d'objet et d'héritage. Par exemple, vous pouvez définir l'objet automobile dont deux autres objets comme camionnette et cabriolet peuvent hériter. Elles en héritent car ce sont des sortes d'automobiles. Elles pourront donc naturellement réutiliser des fonctions et des attributs que toutes les automobiles ont. Comme par exemple avoir 4 roues et la fonction démarrer. Un objet contient implicitement les variables et les fonctions de ses ancêtres. Et cet héritage aide à réutiliser le code, puisqu'a priori la fonction démarrer est la même quel que soit le véhicule. Il y a beaucoup d'autres concepts qui existent dans les langages de programmation objet, ce qui fait de cette catégorie l'une des plus populaires en programmation. Et Java n'a pas échappé à la règle. Mais en plus de mettre à disposition un langage puissant, Java permet aussi de s'abstraire d'autres contraintes plus techniques. L'un des problèmes que l'on peut rencontrer avec les langages de bas niveau comme le C par exemple, est que par définition ces langages sont très proches de la machine et donc de ses différences. Il existe de multiples différences entre les machines, leur architecture interne par exemple, ou le système d'exploitation qui les fait tourner. Un même programme peut avoir des comportements différents sur deux machines différentes. Les concepteurs de Java ont trouvé la parade pour ce problème en faisant exécuter le code non pas directement sur la machine, mais dans une couche intermédiaire qu'on appelle la Java Virtual Machine. C'est-à-dire que le code va être compilé dans un langage intermédiaire qu'on appelle le ByteCode. Et celui-ci ne va pas s'exécuter directement sur la machine, mais au travers de la Virtual Machine. Et là, ça change tout. Quelle que soit l'architecture cible, votre code s'exécutera de la même manière, et vous pouvez même vous payer le luxe de compiler votre code, et de l'exécuter sur des machines d'architecture totalement différentes. Ce qui dans la majorité des cas est un très gros avantage, sauf en matière de cybersécurité car cela facilite la tâche d'un éventuel assaillant. Tout simplement parce qu'il n'y a pas besoin de se préoccuper de l'architecture cible. Java est devenu très populaire et bon nombre de personnes ont contribué à son succès en mettant à disposition des composants logiciels dont l'un des plus connus est Log4J. Cette librairie est très populaire car elle permet de répondre à simplement un problème que tous les informaticiens ont, enregistrer des informations relatives à l'exécution d'un logiciel. En d'autres termes, loguer des données. Les logs sont des fichiers qui consignent des informations sur l'exécution du programme. Certaines des informations sont purement informationnelles, comme la version du programme qui est en cours d'exécution. D'autres sont liées à l'exécution du programme en tant que telle. Renseigner l'activité d'un utilisateur, par exemple. Mais on peut aussi l'utiliser pour renseigner des erreurs critiques dans le système. Il est bien évident que ce genre d'information est très utile pour la maintenance et la mise au point du programme. D'ailleurs, il arrive assez souvent que les logs soient réglés au maximum pendant la phase de mise au point du programme, le but étant d'avoir un maximum d'infos en cas de bug. Alors qu'en production, les logs seront restreints au minimum pour n'enregistrer que les erreurs fatales du système par exemple. Ça semble être une activité assez simple en fait. Pour simplifier, c'est prendre des informations du programme et les inscrire de manière structurée dans un fichier externe. Rien de bien magique. Mais c'était sans compter quelques subtiles fonctionnalités disponibles dans Log4J. Car dans certains cas, ce composant ne va pas simplement écrire des données dans un fichier, mais va aussi interpréter les informations qui lui sont envoyées. Et dans certains cas, Log4J va déclencher des actions concrètes. Et l'une de ces actions possibles est de prendre contact avec une machine pour télécharger du code et l'exécuter. Ce genre de choses est très facile à réaliser en Java pour plusieurs raisons. La première est que Java met nativement à disposition un moyen de consultation des annuaires externes, ce qu'on appelle le GNDi. Le GNDi est une API Java qui permet aux applications Java d'accéder à des services de nom, des répertoires pour localiser des objets Java de manière efficace. En d'autres termes, le GNDi est un moyen pour les applications Java de trouver des ressources telles que des bases de données, des serveurs de messagerie, des serveurs d'annuaire et d'autres objets exécutables. Cela permet aux développeurs Java de créer des applications qui peuvent être déployées de manière flexible et qui peuvent accéder à des ressources à distance sans avoir à coder des détails de l'infrastructure sous-jacente. Si vous n'avez pas bien compris, retenez simplement que c'est un moyen très simple d'aller chercher du code à l'extérieur et de l'exécuter en local. La seconde raison qui facilite cette attaque, c'est que comme nous sommes dans un écosystème Java, le code va s'exécuter de manière universelle, c'est-à-dire qu'il pourra s'exécuter sur n'importe quelle plateforme. Et c'est exactement ce comportement qui est exploité dans Log4Shell. Le principe de l'attaque est étonnamment simple. L'attaquant va mettre en place un serveur contenant du bytecode malicieux. Seconde étape, et de faire en sorte que la victime enregistre via Log4G la requête qui demandera à Log4G d'appeler le serveur malicieux, de récupérer le code et de l'exécuter. Et là, dès que vous avez un élément de votre chaîne opérationnelle qui est codé en Java, serveur web, base de données ou même un service de monitoring, vous êtes potentiellement vulnérable. Autant dire que la surface d'attaque est gigantesque. C'est pas vrai ça. Allez, un général !

• Speaker #1

  Ah non,

• Speaker #0

  Emilien, c'est ma phrase, c'est moi qui l'ai dit tout le temps. Si vous souhaitez avoir des détails sur cette attaque, je vous conseille l'écoute de l'épisode 346 de l'excellent podcast No Limit CQ, dans lequel il détaille très précisément cette vulnérabilité. Le lien sera dans la description de cet épisode. Mais en quoi avoir une information pertinente à propos de son système d'information peut nous aider dans ce genre de situation ? Il faut le reconnaître, Lock4Chain est de loin l'une des failles les plus extrêmes depuis ces dix dernières années. Et soyons honnêtes, ce n'est pas parce que vous avez une CMDB à jour que vous pouvez vous prémunir de ce genre de faille de sécurité. En revanche, elle peut grandement vous aider dans la réponse à cet incident. Fondamentalement, cette vulnérabilité est liée à l'utilisation de certaines versions de Lock4J. et donc à l'utilisation de programmes écrits en Java. Et là, il va falloir diviser votre recherche en deux parties distinctes. Les composants utilisant directement ou indirectement du Java délivrés soit par des fournisseurs externes à votre organisation ou soit par des développements en interne. Vous comprenez certainement l'intérêt et l'avantage d'avoir une cartographie assez fine de votre système d'information. D'une part, vous pouvez obtenir une liste assez exhaustive des fournisseurs concernés pour prendre contact avec eux. D'autre part, vous avez aussi la possibilité d'identifier en interne les composants vulnérables. Vous pouvez par exemple prendre contact avec les développeurs et leur demander de confirmer ou d'infirmer la vulnérabilité. N'oublions pas que ce sont des sous-ensembles de version de la librairie, y concernés par cette phase. L'une des difficultés dans le contexte de Lock4Shell a été la soudaineté de l'impact et surtout la surface d'attaque, c'est-à-dire le nombre de composants susceptibles d'être compromis. Au-delà d'identifier les composants en tant que tels, ce qui a été en soi une tâche assez complexe, il a fallu aussi prioriser les actions de réponse aux incidents. Car l'impact était tel qu'il n'était pas imaginable de tout corriger en même temps. C'est là aussi qu'une cartographie bien pensée peut grandement vous aider dans cette tâche. En effet, une cartographie précise permet d'identifier les dépendances entre les différents composants de votre système d'information. Moi j'aime pas ces histoires de Sud-Est, Nord-Ouest et tous ces machins là. Quoi ? Qu'est-ce qu'il y a qui va pas encore ? Et c'est à quoi se planter ça ? De toute façon on dit le Nord. Selon comment on est tourné, ça change tout. Cette connaissance est cruciale pour identifier les chaînes d'attaque potentielles et aussi prioriser les actions de réponse en fonction de leur criticité. N'oublions pas que dans le contexte de Lock4Shell, en quelques jours, un très grand nombre de systèmes d'information se sont retrouvés vulnérables, dont certains majeurs comme AWS, Azure ou iCloud. Prenons par exemple un serveur web qui tourne sur Internet avec du PHP. A priori, rien ne laisse penser que ce serveur peut être vulnérable à une attaque Lock4Shell. Car rien dans la description que je viens de vous donner ne fait référence à Java. Mais si maintenant j'indique qu'il existe une dépendance entre ce serveur web et un serveur Elasticsearch, qui est une technologie basée sur Java, il y a fort à parier que cette chaîne soit fortement exposée. Si votre cartographie ne définit pas cette dépendance, c'est-à-dire le lien entre le serveur web et Elasticsearch, vous allez conclure de manière erronée que vous n'êtes pas vulnérable, et pourtant vous l'êtes très certainement. Mais les cartographies peuvent aussi vous aider à comprendre une compromission. Si vous avez des doutes sur l'un de vos composants, vous allez très certainement partir à la chasse aux IOC, Indicator of Compromission. Ce sont des traces qui montrent une compromission de votre système d'information. Dans le cas de Lock4Chain, ce sont des appels vers une machine malicieuse. Si cet appel n'est pas légitime, alors il est fort probable que cette machine ait été compromise. Mais comment définir si un appel est légitime ou pas ? Et bien là encore, c'est votre cartographie de flux qui pourra vous aider. Car si le flux fiscitieux n'est pas cartographié mais qu'il existe bel et bien, c'est que manifestement il n'est pas légitime, et qu'il a été rendu possible à cause d'une erreur de configuration sur l'un des composants, comme par exemple un pare-feu. C'est une erreur connue dans le jargon comme étant un trou dans la raquette. Avoir une cartographie exhaustive de son système d'information est essentielle en matière de cybersécurité. Cela permet de comprendre l'ensemble des composants de son système d'information, de les évaluer et de les protéger efficacement contre les menaces de sécurité. Cependant, il est difficile d'atteindre cet objectif, car un système d'information est en constante évolution, que ce soit de manière contrôlée ou non. De plus, il est illusoire de penser qu'une CMDB peut être exhaustive. Une CMDB est une base de données qui contient des informations sur tous les composants de l'infrastructure informatique d'une organisation, y compris les équipements, les logiciels, les licences, les contrats de services. Pour être exhaustif, une CMDB doit être constamment mise à jour, ce qui peut être difficile, coûteux et fastidieux. En outre, les changements dans l'infrastructure informatique peuvent être rapides et imprévus, ce qui rend difficile la mise à jour en temps réel de la CMDB. Par exemple, de nouveaux composants peuvent être ajoutés ou supprimés sans notification préalable, ou des modifications peuvent être apportées à la configuration du système ou du réseau. Mais il est toujours important de faire de son mieux pour maintenir une cartographie aussi exhaustive que possible de son système d'information. Cela peut être réalisé en utilisant une approche progressive. qui consiste à identifier les éléments les plus critiques du système et à mettre à jour régulièrement la CMDB pour les inclure au fur et à mesure. Bien qu'il soit difficile d'atteindre une cartographie exhaustive de son système d'information, il est important de faire de son mieux pour maintenir une vue à jour des composants critiques. Cela permet de mieux comprendre son système et de mieux se protéger contre les menaces de cybersécurité. Encore une fois, la cybersécurité ne réside pas dans l'outil et dans l'ingéniosité des humains qui l'implémentent. Même si parfois la tâche s'apparente plus à nettoyer les écuries d'Ogeas, il faut parfois comprendre les limites de son organisation pour mieux se connaître. À l'instar de la vie réelle où se connaître soi-même peut prendre toute une vie, comprendre son système d'information dans ses moindres recoins, est aussi une tâche perpétuelle. Merci d'avoir écouté cet épisode de la cybersécurité expliquée à ma grand-mère. N'hésitez pas à liker cet épisode et si vous êtes sur Spotify, vous pouvez aussi laisser un commentaire en me proposant des sujets ou des thèmes à aborder dans les prochains épisodes. Vous trouverez en description les références que je cite dans cet épisode. Et surtout n'oubliez pas, certaines personnes pensent que la cybersécurité est un enjeu de vie ou de mort. C'est bien plus sérieux que ça.

• Speaker #2

  Je vais vous faire un petit peu de la vidéo.