Michelin face à la problématique de gestion de la surface d’attaque exposée

L’indispensable gestion du risque

Pour Pierre Raufast, avant même d’évoquer les mesures cyber à adopter pour gérer cette surface d’attaque, la première démarche à prendre est de travailler sur les risques, référencer les événements les plus redoutés. Les risques sont classés entre ceux qui sont volontaires ou involontaires et les actions ciblées ou opportunistes, sachant qu’une simple mauvaise configuration d’une IaaS est une action involontaire qui peut avoir des conséquences catastrophiques… « Dans cette matrice, les événements redoutés principaux sont tout d’abord une mauvaise configuration des assets. Il y a quelques années, on parlait beaucoup des buckets S3 d’AWS. Il n’y avait pas vraiment de malveillance, il s’agissait d’une mauvaise configuration. Et malheureusement, sur Internet, l’erreur se paye cash. Il n’y a pas de firewall pour la masquer ».

« On ne dispose plus du luxe de pouvoir retarder un patching, parce qu’on est exposé et que tous les attaquants utilisent des scanners. »

L’autre grand chantier à ouvrir porte sur la gestion des vulnérabilités : « on ne dispose plus du luxe de pouvoir retarder un patching, parce qu’on est exposé et que tous les attaquants utilisent des scanners ». Que ce soit dans le cadre d’attaques ciblées ou d’une simple recherche d’opportunités, les sites d’une grande entreprise telle que Michelin sont scannés en permanence.

En outre, les nouvelles pratiques de développement peuvent apporter leur lot de risques. Les DevOps publient désormais eux-mêmes leurs développements en production et nul n’est à l’abri d’une erreur : « ces erreurs ne sont pas forcément volontaires, mais souvent le fruit d’une méconnaissance de la sécurité ». Ainsi, un jeton ou un mot de passe intégré dans le code publié sur GitHub est un véritable cadeau fait aux cybercriminels. L’expert ajoute : « cela représente une famille de risques qu’il faut bien caractériser en fonction de chaque entreprise. Ces risques doivent ensuite être déclinés en actions concrètes ».

Avec AWS ou Azure, il n’a jamais été aussi simple de publier une application au nom d’une entreprise : une simple carte bancaire suffit. Cela pose un sérieux défi en matière de gestion de la surface d’attaque. La cartographie du système d’information et les inventaires mis en place ces dernières années ne peuvent être exhaustifs.

De facto, gérer les vulnérabilités devient une véritable gageure : « comme des attaquants, nous scannons nos propres actifs », explique Maxime Escourbiac. « Nous énumérons nos domaines, les services exposés, nous regardons s’il y a des projets GitHub qui apparaissent au nom de Michelin, etc. »

« Les inventaires sont très utiles pour l’asset management, mais pour la sécurité, il ne faut jamais s’y fier. Ceux-ci sont toujours faux, jamais complets et il suffit d’un asset non référencé pour faire entrer le ver. »

Pierre Raufast, enfonce le clou : « les inventaires sont très utiles pour l’asset management, mais pour la sécurité, il ne faut jamais s’y fier. Ceux-ci sont toujours faux, jamais complets et il suffit d’un asset non référencé pour faire entrer le ver. D’autre part, dans certains cas, dresser un inventaire est impossible ».

L’expert prend l’exemple de la faille log4j : aucun fichier Excel et aucune CMDB ne pouvait donner une liste des applications embarquant la librairie fautive. « Obtenir une telle information demande une recherche dynamique », explique Pierre Raufast. « Il faut être très souple et très réactif, car on peut nous demander ce type d’information dans un délai de 1 à 2 heures. Cela implique de développer des modules de scan qui n’existent pas, pour détecter si nous mettons en œuvre telle ou telle technologie en interne. Au final, c’est très complexe et formellement, personne n’arrive à sécuriser à 100 % sa surface d’attaque. Et cela fait poser un niveau d’exigence accru sur tous les autres métiers de l’IT ».

Le casse-tête de la gestion des vulnérabilités

Cette difficulté à maîtriser totalement la surface d’attaque pose très directement la question du patching de ces ressources et plus largement, de la gestion des vulnérabilités. Pour un groupe tel que Michelin, ce sont des milliers de serveurs qui sont en production dans le monde, un nombre à mettre en regard des centaines de vulnérabilités qui apparaissent chaque jour.

« La difficulté est de savoir si nous, Michelin, nous mettons en œuvre les produits concernés et si on est vulnérable », résume Maxime Escourbiac. « Nous scannons nos ressources aussi dans le but de connaître la stack technique utilisée, car le référentiel ne suffit pas. Nous ne le faisons pas seuls. Nous disposons de nos propres scanners, mais nous faisons aussi appel à des prestataires extérieurs pour compléter cette analyse. Personne ne détient la vérité absolue, alors en combinant ces analyses, on peut avoir une image. Celle-ci n’est pas fidèle à 100 %, mais c’est la plus complète possible ».

« Il faut amener un contexte aux équipes de patching, car on ne peut pas hurler aux loups tous les jours et demander à patcher en urgence, sinon les équipes ne pourront pas suivre ».

Pierre Raufast souligne les limites des programmes de patching des serveurs sur un mois à trois mois. « Il faut vraiment être en veille et si l’on dispose de ressources avec une vulnérabilité dont le CVSS (Common Vulnerability Scoring System) est de 9,8, que ces ressources sont exposées et qu’il y a déjà des exploits, alors il faut la patcher en priorité ».

Mais il faut aussi tenir compte du contexte, ajoute Maxime Escourbiac : « une vulnérabilité sur Apache peut être ultra-critique, mais sur un module d’une application un peu exotique, elle peut l’être beaucoup moins. Il faut amener un contexte aux équipes de patching, car on ne peut pas hurler aux loups tous les jours et demander à patcher en urgence, sinon les équipes ne pourront pas suivre ».

Le rôle du CERT est de donner l’alerte sur ces vulnérabilités critiques qui peuvent avoir un impact important dans le contexte spécifique de l’entreprise.

Du bon usage des scanners de vulnérabilité

Maxime Escourbiac explique que tout outil de scan génère beaucoup de données et impose une grosse phase de tri : « quand on scanne 10 000 assets, on va obtenir un nombre énorme de vulnérabilités et de mauvaises configurations. Or, il faut trier ce qui est important de ce qui ne l’est pas. Il faut aussi chercher des signaux faibles ».

Ce sont des dizaines de milliers de points qu’il faut vérifier un à un pour éliminer les faux positifs, évaluer leur impact et quels systèmes ils touchent : « on ne réagira pas de la même manière entre le site commercial d’une petite agence et le service qui gère tous nos comptes clients. On priorise notre réaction en fonction du contexte et c’est notre principal challenge ».

Outre le nombre d’assets, le nombre de types de menaces évolue et les scanners eux-mêmes peuvent être détectés comme des robots ou des scanners mal intentionnés : « nos IP peuvent être bannies. Or, en faisant cela, on va se cacher la vérité ; on ne trouve rien, car notre IP est bannie, mais cela ne veut pas dire qu’il n’y a pas de vulnérabilité ou de mauvaise configuration. On n’a simplement pas pu les voir ».

L’expert a développé l’outil Open Source Redscan qui permet de gérer ses propres scanners. « L’outil a été créé à la base pour identifier notre périmètre. Il ne s’agissait pas d’un scanner de vulnérabilité en tant que tel, mais d’un outil pour avoir, en tapant “michelin.com”, une idée du nombre de services et de domaines concernés », explique Maxime Escourbiac.

Ce logiciel met en œuvre des outils Open Source pour réaliser l’énumération des sous-domaines, détecter les services, etc. « Si on lance l’outil à l’instant t, on ne dispose pas d’une exhaustivité des résultats, mais, au bout de quelques minutes on dispose de bribes que l’on peut commencer à analyser », explique-t-il.

En cas de vulnérabilité inédite, un petit module spécialisé peut être développé pour détecter cette vulnérabilité et vérifier si celle-ci est présente dans le système d’information de Michelin. Elle peut aussi être mise en œuvre pour chercher les numéros de version en production d’une solution à l’occasion de la publication d’une vulnérabilité.

« Il faut toujours contextualiser un POC. »

« L’avantage est de pouvoir maîtriser ce que l’on fait », assène Pierre Raufast : « si l’on prend l’exemple de vulnérabilités critiques pour lesquelles les éditeurs de scanner fournissent rapidement une signature, lorsqu’on analyse la signature, celle-ci détecte le démonstrateur (POC) sorti sur Internet, mais uniquement celui-ci. Si l’on change un seul octet dans le hash du POC, il ne sera plus détecté… c’est un vrai problème. Pour des raisons marketing, les éditeurs veulent être les premiers à sortir des signatures, mais c’est souvent en trompe-l’œil. Notre but avec Redscan est de trouver un modèle générique qui puisse détecter la vulnérabilité. Ou au moins que le POC fonctionne ».

Maxime Escourbiac ajoute : « il faut toujours contextualiser un POC. Il faut dans un premier temps vérifier qu’il ne s’agit pas d’un malware caché. Il y a déjà eu des cas où celui qui fournissait un POC faisait bien plus que scanner des ressources, mais pouvait exploiter les vulnérabilités découvertes… D’autre part, il faut bien comprendre le POC pour trouver des parades. Ce n’est pas parce que le POC ne marche pas que l’on n’est pas vulnérable dans un contexte particulier. C’est la raison pour laquelle nous essayons de maîtriser nos outils de scan pour, derrière, être plus performants ».

Considérer la cinétique d’attaque dans son ensemble

La mission de veille du CERT est bien entendu essentielle pour détecter d’éventuelles fuites de données ou de credentials sur Internet, mais aussi suivre les domaines Internet créés au nom de l’entreprise pour déjouer toute tentative d’usurpation de la marque. Néanmoins, cette veille doit être relayée par des actions rapides. « Toute la chaîne défensive d’un CERT doit être alignée sur une échelle de temps qui s’est considérablement réduite ces dernières années », explique Pierre Raufast. 

« Toute la chaîne défensive d’un CERT doit être alignée sur une échelle de temps qui s’est considérablement réduite ces dernières années. »

« Si une mise en vente de credentials de l’entreprise est détectée ou qu’un nom de domaine usurpé vient d’être créé et qu’il faut trois semaines pour répondre, cela n’aura servi à rien… De même, quand une vulnérabilité critique survient, on peut patcher rapidement, mais peu d’entreprises s’assurent qu’il n’y a pas eu de compromission en place avant de patcher ». Et dans les faits, il est quasiment impossible de se livrer à un forensic post-patching lorsqu’un patch vient d’être déployé sur plusieurs centaines de machines…

Néanmoins, si une vulnérabilité constitue une porte d’entrée au SI pour l’attaquant, ce n’est qu’une phase d’une cinétique d’attaque, la kill chain, beaucoup plus globale. « Quand l’attaquant a placé un Shell, il va faire de l’élévation de privilèges, de la persistance, éventuellement des mouvements latéraux », explique Pierre Raufast. Dès lors, « on va pouvoir l’observer dans les autres étapes de la kill chain, au travers des outils de détection, du SOC, etc. ; ce que l’on appelait avant la défense en profondeur, avec une détection à chaque étape de la kill chain, qui reste un impératif de la cybersécurité ». Si une certaine porosité vis-à-vis des 0-day est inéluctable, de même que le délai avant patching, la défense en profondeur doit assurer le relais.

Sur ce plan, Maxime Escourbiac souligne les limites des solutions de type antivirus et EDR qui se basent soit sur des signatures, soit sur des mécanismes connus : « les attaquants qui utilisent un 0-day peuvent avoir le niveau de sophistication nécessaire pour monter des attaques plus complexes qui contourneront ces éléments de sécurité. Le plus important est de voir l’ensemble et comment un incident unique, avec la compromission d’un seul serveur, ne se transforme pas en incendie généralisé avec une compromission de l’Active Directory ».

Les défenseurs disposent néanmoins de méthodes pour contrer ce risque, notamment en détectant l’attaquant lorsqu’il procède à son élévation de privilèges ou à un pivot. 

Le fléau du vol de tokens et d’identifiants

Pour Pierre Raufast, le risque le plus létal reste le vol de tokens et les IAB : « il s’agit de risques très pernicieux. Le dépôt d’un malware ou d’un shell fait du bruit ; on est capable de les détecter. Mais quand un attaquant vole les credentials ou les tokens d’un collaborateur, il se connecte de façon légitime et c’est très difficile à détecter ».

« Quand un attaquant vole les credentials ou les tokens d’un collaborateur, il se connecte de façon légitime et c’est très difficile à détecter. »

Celui-ci sera repéré s’il récupère des emails, s’il exfiltre des données, mais le risque est bien là et la menace est d’autant plus grande qu’une telle action peut tout à fait passer sous les radars des SOC.

Toutes les interfaces d’administration d’Azure, AWS ou Alibaba sont accessibles sur Internet et un vol de token peut conduire à une compromission totale en quelques clics. « Un accès par token sur console AWS et l’entreprise est compromise en une demi-heure. C’est la menace que nous avons identifiée comme la plus grave », ajoute Maxime Escourbiac.

De facto, Michelin consacre des ressources à la lutte contre cette menace et s’appuie sur des partenaires pour réduire ce risque : « chacun a sa spécialité, ses propres crawlers sur le darkweb et se montre meilleur sur tel ou tel type de sites, ou types de vulnérabilités. Nous diversifions nos sources d’information, cela a un coût. Nous savons que nous ne pouvons pas atteindre une couverture à 100 %, mais c’est toujours mieux que de ne rien faire ».

En outre, Pierre Raufast souligne la solidarité entre les CERT français, que ce soit via l’association InterCERT, du Clusif et quelques autres associations. « Les CERT s’échangent des données et lorsqu’on détecte des choses sur le Darkweb, on informe la société en question, les institutions, etc. Beaucoup de gens jouent le jeu : on signale des éléments à nos collègues de l’InterCERT et vice-versa. Cela constitue une sorte d’intelligence collective. Dans la cybersécurité, les gens collaborent entre eux, même si les entreprises sont concurrentes ». Pour l’expert, il est aujourd’hui impossible de faire de la cybersécurité seul. Les entreprises sont obligées de collaborer. 

Témoignage issu du Summit Cybersécurité BrightTalk/LeMagIT de juin 2024. Il est disponible ici dans son intégralité.