L’interview cybersécurité : tout savoir sur le SOC (Security Operations Center) avec Processus Thief
Après la revue de presse sécurité Revolve Job Zero, nous vous proposons un nouveau format régulier sur la sécurité Cloud. Dans cette série d’interviews, nous allons à la rencontre de spécialistes sécurité qui travaillent sur le Cloud pour faire un état des lieux des tendances et des pratiques : boîte à outils sécurité dans le Cloud, évolutions de fond, transformation du métier de la sécurité…
Nous recevons aujourd’hui Christopher, aka Processus Thief, analyste SOC, speaker LeHack et créateur de tutos sécurité sur Youtube, pour discuter des missions des analystes SOC, des outils utilisés et de l’évolution des cybermenaces.
Pour plus d’informations, retrouvez Christopher sur son site.
En quoi consiste le métier d’analyste SOC ?
Une journée type commence par l’analyse des alertes de sécurité. En France, le CERT-FR publie chaque jour des avis de sécurité, et notre mission est de vérifier cette liste et d’analyser chaque vulnérabilité à travers son score CVSS.
Ce score prend en compte la criticité (impact sur la disponibilité et l’intégrité des données), sa facilité d’exploitation (authentifié ou non, à distance ou connecté sur le poste victime), son type (exécution de commandes, accès à des fichiers sensibles), etc.
Tous ces critères donnent un score de criticité sur une échelle de 10. Nous avons défini un seuil à partir duquel traiter les alertes : on ne traite que les alertes avec un score supérieur à 7,5, afin que le nombre d’alertes à traiter chaque jour reste raisonnable. Pour chaque vulnérabilité, on estime si elles peuvent impacter le SI, et comment. On demande ensuite aux équipes concernées de patcher et de mettre en place les mécanismes de protection nécessaires. Dans le cas où il s’agit d’un logiciel dont on n’a pas connaissance, par exemple un logiciel de comptabilité, on va se renseigner auprès des équipes systèmes pour savoir s’il est utilisé dans l’entreprise.
Notre seconde mission consiste à surveiller notre SI depuis l’extérieur, avec des tests d’exposition automatisés. Nous utilisons Shodan.io : l’outil scanne régulièrement internet, et nous informe de l’exposition d’un asset à un instant donné. Par exemple, une adresse IP publique avec un port ouvert.
Notre société est opérateur d’infrastructure, on fournit une liaison internet à nos clients, des entreprises, et un hébergement de leurs serveurs en infogérance, etc. Nous sommes également certifiés HDS. Une partie du travail du SOC est donc de vérifier régulièrement sur les IP publiques ce qui est exposé. Dans le cas où un client, qui gère lui-même son firewall, expose un serveur vulnérable, on le prévient. Ces tests sont automatisés, notre travail est de gérer les alertes qui sont générées. Parfois, elles sont minimes, d’autres fois c’est un GLPI ouvert publiquement comportant une vulnérabilité avec un score élevé.
Quels sont vos outils ?
L’outil principal est l’EDR (détection et réponse à événement). Il installe un agent sur chaque endpoint, et cet agent récupère des données de télémétrie : les processus en cours d’exécution, les résolutions de noms de domaine, les commandes tapées sur le poste, etc. Tout est récupéré dans une console, pour ensuite faire de la détection, un peu à la manière d’un antivirus, mais en plus sophistiqué.
Quelles sont les règles de détection ?
Tout d’abord la détection statique, basée sur les règles YARA. Pour comprendre leur fonctionnement, prenons l’exemple des anciens antivirus, qui calculaient la somme de contrôle, le hash, d’un binaire malveillant comme mimikatz. Ce binaire était ensuite ajouté à la base antivirus, et lors de l’exécution d’un logiciel, l’antivirus calculait sa somme de contrôle, puis vérifiait la correspondance dans sa base. C’est bien, mais pas suffisant : si on récupère le code source de mimikatz et qu’on ajoute une fonction, on obtient une somme de contrôle différente.
Aujourd’hui, la détection par hash ne tient plus la route, et on fait de la détection sur des morceaux d’octets. Il s’agit d’extraire des données du binaire, par exemple la suite d’octets de la fonction qui récupère les identifiants en mémoire. Quand on lance un logiciel sur le poste, on regarde alors si on y retrouve cette suite d’octets, cette portion de code. On le fait avec de nombreux binaires malveillants : c’est ça la détection statique.
Ensuite, la détection dynamique, ou comportementale. Il s’agit des règles SIGMA. Le moteur de détection va observer l’arborescence d’exécution. Par exemple, un utilisateur ouvre une session, et lance un bloc note. Cet enchaînement est légitime, mais si le notepad déclenche un cmd.exe, on est peut-être face à un attaquant qui fait de l’injection de code, et qui a créé un processus enfant pour exécuter des commandes systèmes. On essaie donc d’identifier une arborescence d’exécution, ou une suite d’actions, qui soit suspecte. Il existe d’autres moteurs de détection, mais YARA et SIGMA sont les plus importants.
Certains moteurs de détection sont spécifiques à l’EDR, selon qu’on ait CrowdStrike, Sentinel One ou autre. Certains éditeurs ajoutent maintenant des moteurs à base d’IA, pour que le modèle identifie des comportements de logiciel malveillant. Cela fonctionne plus ou moins bien.
Comment traitez-vous les alertes ?
Quand il reçoit une alerte, l’analyste SOC doit utiliser son expertise, sa connaissance du système et des outils pour déterminer s’il fait face à un faux positif ou à quelque chose de potentiellement malveillant.
En d’autres termes, procéder à une levée de doute. Et donc, dans notre exemple précédent, déterminer si le cmd.exe lancé par le notepad est légitime. Dans un SOC interne, on contacte directement l’utilisateur; dans un SOC managé, on notifie les administrateurs. Dans tous les cas, on essaie de déterminer si c’est une action légitime de l’utilisateur, et si elle est récurrente. En effet, afin d’avoir le moins de “bruit” possible au niveau du SOC, on va exclure de la détection ce comportement sur ce poste, et cet utilisateur (s’il y a récurrence). Établir une liste blanche permet de diminuer le nombre de tickets à traiter, afin d’être plus disponibles, et pertinents, pour les vraies alertes de sécurité.
Si la compromission est avérée, on passe en réponse à incident. Dans les grandes entreprises, il y a le plus souvent une équipe CERT dédiée. Dans ce cas, on va donc rassembler des éléments de contexte sur l’utilisateur. Par exemple, s’il s’agit d’une société qui fait du développement logiciel, il est normal d’utiliser Visual Studio. On prend donc le plus d’informations possible auprès des administrateurs, par exemple le nombre de contrôleurs de domaine, le nombre de serveurs, le type de connexion (locale, à distance, sur un serveur RDS ou sur un poste dédié), les VPN, etc. On récupère la liste des journaux, pour savoir qui s’est connecté, quand, où. Bref, on essaie de comprendre comment le client travaille, et identifier les potentiels points d’entrée de l’attaquant.
Avec ces informations, on repart du “point de détonation”, le poste de l’utilisateur en question dans l’exemple. La bonne pratique consiste à désactiver le compte de l’utilisateur impacté, et d’en recréer un nouveau, pour éviter que l’attaquant puisse revenir, et on commence les investigations. Qui s’est connecté sur le poste, à quelle heure, depuis où, quelle adresse IP, et petit à petit on remonte vers l’origine de la connexion de l’attaquant. Ensuite, on peut patcher le point d’entrée.
Car dans beaucoup de cas, ce scénario est celui d’un ransomware qui verrouille les fichiers, et qui aboutit sur un arrêt de production. Il ne sert à rien de restaurer les sauvegardes si le point d’entrée n’a pas été patché : l’attaquant reviendra et recommencera. Ensuite, les admins peuvent remettre en production.
Que se passe-t-il ensuite ?
Nous produisons un livrable, le rapport d’incident, qui recense toutes nos investigations : le point d’entrée, le passage sur le réseau d’un serveur à l’autre, le déclenchement du ransomware, ce qui a été impacté par le ransomware, ce à quoi l’attaquant a eu accès, etc.
Le rapport d’incident inclut aussi des préconisations, comme comment éviter que l’attaquant récupère des identifiants en mémoire sur la machine. On peut par exemple ajouter les utilisateurs à haut privilège à un groupe Protected Users dans l’AD, de façon à ce qu’ils doivent utiliser un protocole d’authentification plus sécurisé (Kerberos plutôt que NTLM). Le SOC recommande ainsi un ensemble de pratiques pour “hardener”, ou durcir la sécurité de l’AD.
L’analyse de l’incident permet aussi de récolter des indicateurs de compromission (IOC), comme l’origine géographique de l’attaque, le script utilisé, ou l’IP. On peut certes changer rapidement d’IP, mais il est probable que l’attaquant ne changera pas forcément d’IP immédiatement. Donc tous ces IOC sont ajoutés au moteur de l’EDR, et propagés à l’ensemble de nos clients, afin que la prochaine tentative soit détectée avant que l’attaquant aille au bout de la séquence.
On premise ou sur le Cloud ? Quels sont les changements pour le SOC ?
Nous conseillons à nos clients d’héberger leurs serveurs Exchange chez Microsoft. Maintenir à jour un serveur Exchange, le patcher sans interruption de service, c’est compliqué. Pour le client, avoir certains services dans le Cloud apporte de la fluidité, il peut gérer ses utilisateurs depuis n’importe où.
Le Cloud facilite aussi la gestion des licences Office, c’est beaucoup plus simple à maintenir dans le temps. Du côté du SOC, cela implique par contre un peu plus de travail, récupérer les informations avec l’EDR au niveau du endpoint n’est plus suffisant, on corrèle donc les logs de connexion, les alertes EDR et les informations en provenance d’Azure dans un SIEM. Travailler avec le Cloud nous demande donc d’établir un peu plus de corrélations et d’interactions entre nos outils et le Cloud.
Quels sont vos principaux outils ?
Notre outil principal est l’EDR, qui nous apporte toute la télémétrie sur les utilisateurs et leurs actions. Toutes ces alertes sont stockées dans un puit de logs, dans un format brut, sans retouches, pour éviter toute perte d’information. On y collecte aussi les logs Azure, les logs des firewall, des sondes de détection et de prévention d’intrusion.
Notre SIEM va s’interfacer sur le puit de logs pour récupérer les données brutes, extraire les informations dont il a besoin, faire de la corrélation, et créer de nouvelles alertes avec ses règles de détection. Ces alertes sont ensuite routées dans un outil de gestion de tickets. Chaque analyste peut s’affecter un ticket, cela nous donne aussi un suivi des alertes, afin d’identifier les patterns récurrents et faire de l’amélioration continue.
On peut éventuellement avoir un dernier outil pour gérer les compromissions avérées, un logiciel de réponse à incident. Cela permet d’avoir un suivi des actions, qui fait quoi, avoir des compte rendus des investigations et des interventions des collaborateurs du SOC.
Quelle est la part d’automatisation dans votre travail ?
Nous automatisons tout l’interfaçage entre nos outils, de l’EDR au puit de logs par exemple. Le plus souvent, nous écrivons des scripts en Python pour appeler l’API de l’EDR ou du SIEM, ou pour automatiser l’envoi des alertes.
Quelle a été l’évolution de la menace cyber ces trois dernières années ?
On constate une très forte augmentation du volume. Depuis septembre 2023, on recense au moins une attaque par semaine. Une partie de cette hausse du volume est dûe au fait que nous avons plus de clients, mais l’augmentation des attaques est récurrente.
En termes de typologie d’attaquants, c’est très hétérogène. On peut avoir un attaquant qui teste quelques commandes d’énumération, qui est bloqué par l’EDR et ne revient jamais. Ou bien quelqu’un qui réussit à entrer, à voler des ID, récupérer des informations et se faire très discret avant d’exfiltrer les données. Généralement, ça se termine par le “grand feu d’artifice”, le ransomware. On a aussi des attaquants un peu hors du commun : l’attaquant est entré, a vu l’EDR, a fait une recherche dans les documents via des mots clé comme “mot de passe”, a trouvé des identifiants (Ameli, impots.gouv, etc.) et n’est jamais revenu. Il n’a pas rendu le service indisponible, il a juste fouillé et il est parti.
Quels sont les critères de choix d’un EDR ?
Nous avons choisi un EDR français, HarfangLab, labellisé par l’ANSSI. Notre principal critère de choix a été de disposer de règles de détection en source ouverte : on peut modifier une règle si on le souhaite.
Autre critère, le taux de détection. A vrai dire, rien ne sert d’avoir un très haut taux de détection si derrière on a beaucoup de faux positifs qui génèrent une surcharge de travail pour les analystes. De fait, nous analysons chaque semaine les nouvelles règles fournies par l’éditeur. Si une règle ne nous semble pas pertinente, ou si elle risque de déclencher trop de faux positifs, on ne la met pas en production. Ce sont vraiment nos deux critères principaux : avoir accès au fonctionnement de l’EDR, et pouvoir garder la main sur ce qui est mis en production.
Quel conseil donnerais-tu à un jeune diplômé ?
Tester par soi-même. Quand on a un doute sur une techno, rien ne vaut l’expérimentation. Par exemple, quand nous avons mis en place le SIEM, nous ne voulions pas installer un 3ème agent sur les postes client. Le collecteur de logs natif Windows était une alternative, mais on ne savait pas comment ça fonctionnait. J’ai monté un lab chez moi, avec un serveur, un contrôleur de domaine, un serveur Linux avec le SIEM. J’ai testé, je me suis planté plusieurs fois, et à la fin ça a fonctionné. Les formations, c’est très bien, ça donne de bonnes bases, mais il faut ensuite les mettre en pratique. Avoir un état d’esprit autodidacte, c’est le cœur du métier.
Enfin, j’ajouterai qu’il est nécessaire d’être patient, de prendre le temps de comprendre ce qu’on fait, et de prendre du recul. En d’autres termes, comprendre pourquoi on fait les choses.
Se former et passer des certifications, c’est aussi un bon moyen de progresser ?
J’adore l’offensif et le pentest, et développer son expertise en offensif m’aide beaucoup dans l’analyse des alertes, on voit tout de suite quel type d’outil a pu être utilisé par l’attaquant. Dans un lab, j’avais utilisé rubeus.exe pour voler des tickets kerberos, le jour où on a vu cet outil dans une alerte, j’ai tout de suite su que c’était malveillant.
Tu peux nous parler du challenge Red Team Operator que tu as passé récemment ?
J’ai trouvé cette certification super dure ! Mais j’ai beaucoup appris, et notamment à utiliser Cobalt strike. C’était le seul outil auquel nous avions accès pendant la certification, et j’ai découvert que ça fonctionnait très bien.
Je suis maintenant sur une autre certification, et j’utilise encore Cobalt strike : c’est rapide, flexible, modulable. On en revient à ce qu’on disait plus haut, l’importance de tester pour progresser.
En bonus, le tutoriel de Processus expliquant le fonctionnement de la technique de compromission initiale « Remote Template Injection », consistant à obtenir une tentative d’authentification NTLM via le chargement d’un modèle de document Office :
Commentaires :
A lire également sur le sujet :
