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 comprennent rien. Bonjour et bienvenue dans la cybersécurité expliquée à ma grand-mère, le podcast pour expliquer la cybersécurité à ceux qui n'y comprennent rien. Ma grand-mère est de retour de ses vacances, elle est en pleine forme et encore plus enthousiaste que jamais. Elle vous fait de gros bisous et a déjà toute une série de sujets qu'elle est impatiente d'aborder avec vous. Vous vous souvenez peut-être du chef-d'oeuvre du cinéma allemand, les ailes du désir du réalisateur Wim Wonders. Dans ce film fascinant, deux anges incarnés par Bruno Gantz et Otto Sander ont le pouvoir de lire dans les pensées des humains. Ce film plonge le spectateur dans la cacophonie incessante de la réflexion des hommes qui les entourent. Il devient alors pour le public impossible de démêler ces pensées entrecroisées. On parvient de temps en temps à saisir des fragments de réflexion, mais en grande partie, elle demeure enchevêtrée et totalement incompréhensible. Les deux anges portent une attention bienveillante à chaque individu, et cherchent à influencer leur destin quand cela est possible. Au-delà du thème philosophique et de la contemplation que le film invite à explorer, il existe un parallèle un peu inattendu avec le domaine de la cybersécurité. Imaginez un ange gardien qui aurait la capacité d'écouter chaque composant d'une infrastructure informatique, comme s'il pouvait entendre les pensées les plus intimes et les plus profondes. Alors bien sûr, cette analogie est métaphorique, car jusqu'à preuve du contraire, un parfum n'a que peu de pensées intimes. Eh bien, cet ange gardien existe. Il s'agit du Security Operations Center, ou SOC pour les intimes. Dans l'épisode d'aujourd'hui, je vais vous proposer d'explorer en détail le rôle et le fonctionnement d'un SOC. Le premier élément fondamental à comprendre ici est le CIEM, acronyme de Security Information and Event Management en anglais, soit Gestion des Informations et des Événements de Sécurité en français. Il s'agit d'une solution intégrée pour fournir en temps réel, ou presque selon les produits, Une analyse des alertes de sécurité générées par différents matériels et logiciels au sein d'une infrastructure. Chaque composant, qu'il s'agisse de serveurs, de pare-feu ou de proxy, génère des journaux d'activité, aussi appelés logs, certains logs étant directement liés à des questions de sécurité. Ces logs sont des messages structurés qui documentent divers événements, comme l'authentification réussie d'un utilisateur sur une machine par exemple. La plupart des systèmes est extrêmement bavard et n'arrête pas d'enregistrer des informations dans ces journaux. Que ce soit une authentification réussie, un mot de passe incorrect ou même une erreur système, presque tout est consigné. Cependant, ce flot d'informations pose un problème de taille, la consommation excessive d'espace disque. Ce problème s'accentue avec la durée de rétention des données et d'éventuels problèmes d'inondation. Il arrive parfois que certains systèmes s'emballent et génèrent des tonnes de logs et submergent le SIEM. Ça arrive très fréquemment quand une application est mal configurée et qu'à la place de passer par le proxy par exemple, Elles tentent de passer directement sur Internet. Il est fort probable que les pare-feux génèrent de nombreux logs dans cette situation. Par ailleurs, plus vous conservez d'informations pendant une longue période, plus l'espace de stockage nécessaire augmente. En conséquence, il est souvent nécessaire de limiter le type d'événements enregistrés et leur durée de conservation. Or, il arrive très fréquemment que les données écartées sont celles qui se révèlent cruciales à l'avenir. Le monde de la cybersécurité est ainsi fait. à moins de disposer d'une dollarienne pour voyager dans le temps,

• Speaker #1

  généralement le log dont vous avez besoin est celui du manque. Oh, Doc, vous vous êtes déguisé en cosmologue. C'est pas le moment, c'est pas le moment, on n'a pas le temps. Ça y est, je suis prêt. Mesdames, messieurs, je me présente, Emmett Brown. Je me trouve sur le parking de la promenade des deux pains. Nous sommes le 26 octobre 1985 et il est 1h18 du matin. Expérience temporelle numéro 1.

• Speaker #0

  Il y a donc un choix assez subtil à faire entre les événements essentiels et ceux qui le sont moins. Généralement, les éléments purement de sécurité sont pris en compte sans trop de restrictions. Le CIEM va recueillir et agréger ces données en provenance des différentes sources de l'infrastructure, comme les serveurs, les pare-feux, les systèmes de détection et de prévention d'intrusion, et d'autres sources de données liées à la sécurité. Généralement, ces événements sont recueillis et injectés dans le système quasi en temps réel. Une bonne méthode consiste aussi à mettre un intermédiaire entre les machines de l'infrastructure et le SIEM. Cet intermédiaire aura pour but de collecter, de normaliser et de centraliser les logs pour les mettre à disposition du SIEM par la suite. Cette technique a plusieurs avantages. D'abord, d'un point de vue architecture, cela permet de garder une indépendance entre les machines et le SIEM. C'est-à-dire que dans ce cas, il sera plus facile de changer le SIEM sans avoir à refaire toute la partie collecte d'informations. Deuxième avantage, Cela permet de garder une copie des logs indépendantes, mais aussi de temporiser l'impact en cas d'inondation. Si ce problème venait à apparaître, c'est le système de collecte de logs qui sera impacté, et non le CIEM directement. Là encore, ça permet d'augmenter la résilience du système d'information. Mais à l'instar des anges du film, comment le CIEM est-il capable d'analyser toutes ces informations ? Comment fait-il pour faire la différence entre une information futile et une situation bien plus inquiétante ? Eh bien, l'un des leviers qui est mis en œuvre est que le CIEM est capable de collecter et d'ingérer beaucoup d'informations en un temps record, mais aussi d'appliquer des règles sur ces données. Prenons un exemple concret. Comment faire la différence entre une attaque de type brute force, c'est-à-dire un processus qui essaie de s'authentifier à de multiples reprises avec des logins et ou des mots de passe différents, et un utilisateur un peu distrait qui a oublié son mot de passe et qui essaie avec plus ou moins de succès différentes possibilités ? La première chose que va faire le SIEM, c'est de normaliser les données. Car je vous rappelle... Les données utilisées sont en provenance de multiples systèmes tous différents, et par conséquent avec des formats de logs différents. Même si les logs contiennent souvent les mêmes informations, date et heure de l'événement, et sa nature par exemple, le CIEM doit les normaliser pour pouvoir les exploiter. A noter au passage l'importance que tous les équipements sous contrôle du CIEM utilisent la même heure. C'est la raison pour laquelle il est très important que tous les équipements soient tous synchronisés. Cela permet aussi de faciliter la recherche des informations dans le système. Moi, tout ce qui est date, je m'embourbe.

• Speaker #2

  Moi, c'est l'inverse. Je ne sais pas super bien compter, mais les dates, c'est mon rayon.

• Speaker #0

  Ah ouais ?

• Speaker #2

  Putain, je ne sais pas comment vous faites. Par exemple, vous prenez aujourd'hui, vous comptez 7 jours. Ça vous emmène dans une semaine. Eh bien, on sera exactement le même jour qu'aujourd'hui.

• Speaker #0

  Ah ouais ! Il y aussi un problème important qui concerne la complétude de l'information. Le CIEM travaille uniquement sur ce qu'il entend. Mais comment s'assurer qu'il entende tout ? C'est-à-dire chaque machine. Le problème semble a priori simple. Car il suffit simplement que les logs de toutes les machines concernées soient bien dans le système. Mais ceci implique que vous avez un inventaire exhaustif dans votre parc. Et ça, nous l'avons vu dans l'épisode Connais-toi toi-même c'est loin d'être aussi simple. L'autre aspect vient de l'évolution des machines concernées. Vous pouvez parfaitement avoir aujourd'hui des logs en provenance d'une machine. Mais que se passe-t-il en cas de mise à jour ? Est-ce que les logs continueront à remonter comme dans le passé ? Rien n'est moins sûr en fait. Et ça, c'est un grand danger. car vous pourriez avoir l'illusion que vous surveillez l'entièreté de votre système d'information, alors qu'en fait, il vous parle mais vous n'entendez rien. Tout simplement parce que le format des logs a peut-être été altéré par les mises à jour et que le SIEM n'est plus capable de les traiter correctement. Le SIEM va ensuite utiliser un ensemble de règles, d'algorithmes et de modèles heuristiques pour évaluer les données. Dans notre exemple, un certain nombre d'échecs de connexion en un court laps de temps, sur un même compte, peut être considéré comme une activité suspecte. C'est là où la notion de temps est très importante. Car c'est ce qui permet de faire la différence entre une attaque de type road force, qui va essayer plusieurs centaines de mots de passe en quelques minutes, et un simple échec de connexion. Mais le SIEM va aussi corréler des données en provenance de sources différentes pour obtenir une image plus complète de l'activité du réseau. Par exemple, si un utilisateur se connecte à partir d'un emplacement géographique inhabituel et cherche à scanner le réseau, c'est généralement pas très bon signe. Vous l'avez compris, le SIEM, c'est utiliser des données structurées sur lesquelles On va faire des analyses et faire passer des algorithmes plus ou moins connus. Là encore, c'est mieux que ces algorithmes ne soient pas trop connus, car si ils le sont, ce serait plus facile de les contourner. Il y a aussi nécessité de mettre à jour et de faire évoluer ces règles, car de nouvelles techniques d'attaque peuvent apparaître. Mais on va revenir sur ce point d'ici quelques minutes. Mais le SIEM peut être aussi utilisé pour faire des recherches spécifiques dans le passé, afin d'identifier une compromission de votre système d'information. C'est l'utilité des indicateurs de compromission ou IOC en anglais. Quand une attaque a lieu, il est souvent utile de collecter des informations liées à cette attaque, comme les adresses IP utilisées par les assaillants, mais aussi les exploits utilisés ou même la charge détonante, le payload pour les intimes. Toutes ces informations sont très utiles pour voir s'il n'y a pas de traces de compromission dans le passé, mais aussi pour communiquer auprès d'autres acteurs sur les attaques que vous avez subies. Vous trouverez par exemple des IOC dans les bulletins de sécurité de l'ANSI. Dans la nouvelle réglementation DORA, il faudra pouvoir communiquer auprès d'autres acteurs pour que tout le monde puisse se prémunir contre cette attaque Le CIEM a donc la capacité d'ingérer des données afin de détecter un comportement anormal. Certains ont même un algorithme d'apprentissage qui permet d'adapter les seuils de détection en fonction de différents contextes. Le but de tout cela est de détecter le plus sûrement possible une compromission de votre système d'information, c'est-à-dire une vraie anomalie. Et c'est bien là où est la difficulté. Car détecter des choses normales, c'est très simple. Mais détecter une anomalie en général et un comportement malicieux en particulier, Là, c'est nettement plus compliqué. Si vous activez toutes les règles disponibles dans votre SIEM sans prendre garde au contexte ni au paramétrage, il y a fort à parier que vous soyez très vite noyé sous les alertes, et qu'au voulu pied, à cause de ça, la seule alerte qui est vraiment significative. A contrario, si vous activez ces règles mais avec trop de restrictions, vous risquez de ne rien voir et de conclure de manière erronée que rien ne se passe dans votre système. C'est encore un bel exemple de l'adage la sécurité ne vient pas du système de défense mais du savoir-faire de ceux qui l'ont mis en place. Mais si vous avez fait votre travail correctement, vous devriez avoir les alertes nécessaires et suffisantes. En cas d'alerte, c'est souvent un opérateur humain, un membre de l'équipe SOC, qui va prendre en main et va analyser l'alerte dans le but de confirmer ou de l'infirmer. Dans le cas où l'alerte est infirmée, il y a souvent une rétro-analyse de l'alerte afin d'optimiser le taux de faux positifs. En fait, dans l'absolu, vous ne devriez jamais avoir deux fois la même fausse alerte. Si en revanche l'alerte est confirmée, alors là, c'est le point de bas de combat, avant le lancement d'une analyse plus approfondie de la situation.

• Speaker #3

  C'est un soldat français qui vient chercher à manger pour ses hommes, en forêt.

• Speaker #4

  Mademoiselle ?

• Speaker #3

  Madame.

• Speaker #4

  Ah pardon, madame.

• Speaker #3

  Alors comme ça, vous vous battez dans la forêt de Majkul.

• Speaker #4

  On se bat, on se bat. C'est plutôt qu'on est comme une espèce de poste avancé, quoi. Dans le cas que... Vous comprenez une supposition que les Allemands reculent ? Crac ! On est là.

• Speaker #3

  Pour les empêcher de reculer.

• Speaker #4

  Non, pour... La tenaille, quoi.

• Speaker #3

  La tenaille, oui. Je vous demande ça parce que... Aux dernières nouvelles, les Allemands sont déjà à 30 km au sud de Machkul.

• Speaker #4

  Tiens. Oh, dis-donc. Il fonce,

• Speaker #3

  hein ? Il fonce, oui.

• Speaker #0

  Évidemment, toutes ces informations, les vrais positifs, les faux positifs, etc., sont des indicateurs de performance de votre SOC d'un point de vue technique. Mais n'oublions pas que derrière la console, il y a des humains, les analystes SOC, qui doivent avoir la formation, les connaissances en cybersécurité, mais aussi les connaissances du contexte. Car là encore, cette connaissance du contexte, c'est-à-dire du système d'information qui est sous surveillance, est cruciale dans l'analyse. En plus de cela, il faut prendre en compte que bien souvent ils travaillent H24 et 365 jours par an, ce qui nécessite en plus de coordonner les équipes qui travaillent de jour et celles qui travaillent de nuit. Mais une question légitime se pose à cet instant. Si vous avez mis en place un SIEM, que ce SIEM a été configuré correctement et que les analystes de l'équipe sont tous formés, comment s'assurer que tout cela fonctionne correctement en cas d'attaque ? Et surtout, à partir de quel moment une alerte pertinente va être générée par le SIEM ? Souvenez-vous que dans le film, le brouhaha est constant, que certaines voix sont plus faibles que d'autres. Est-ce que les oreilles du soc sont-elles assez sensibles pour détecter un chuchotement ? Ou faut-il un concert de heavy metal pour que les premières alertes apparaissent ? Eh bien, c'est un vaste sujet en fait. Mais sachez qu'il existe des solutions comme Black Noise, je mettrai le lien en commentaire bien évidemment, qui permet de tester un soc et de répondre à cette question ô combien stratégique. Mais ça, c'est une autre histoire. Pour revenir et pour finir avec le film de Wim Wenders, dans une interview, le réalisateur avait expliqué avoir reproduit à environ 300 mètres du no man's land entre les deux murs de Berlin. C'était une bande de terre qui était limitée de part et d'autre par les deux murs de séparation côté est et ouest. Cette zone était un peu une DMZ. Comme il n'y avait aucune présence humaine, des colonies de lapins s'y étaient installées et pullulées en grand nombre. Pour reproduire ceci, Wim Wenders a introduit des lapins dans son décor afin de reproduire le plus fidèlement possible la situation. Ce fut sa plus grande erreur, car les lapins en liberté passaient leur temps à copuler, à tel point qu'il était quasi impossible de tourner une scène sans voir des lapins en pleine action en arrière-plan. J'en conclue donc qu'il ne faut jamais mettre de lapins dans sa DMZ. Encore merci d'avoir écouté cet épisode. N'hésitez pas à le liker et à le partager avec d'autres. Si vous êtes sur Spotify, vous pouvez aussi donner votre avis et proposer des sujets qui vous semblent pertinents. Mais surtout, n'oubliez pas, pour certains, la cybersécurité est un enjeu de vie de mort. C'est bien plus sérieux que ça.