Le choix de Pernod-Ricard pour moderniser son SIEM

Un SIEM en fin de vie

« Lorsque je suis arrivé chez Pernod Ricard, il y a un peu plus d’un an, ma première mission a été de remplacer le SIEM et, plus globalement, revoir le SOC qui avait plus de six ans […]. »

À l’époque, le SIEM était hébergé sur une infrastructure IaaS dans le tenant Microsoft Azure du groupe. Si le contrat était largement dimensionné au départ, au fil des années, le nombre d’EPS (événements par seconde) maximum était atteint : « soit il fallait sortir notre carnet de chèques, soit limiter le nombre de logs suivis. Cette limitation était problématique pour nous, car nous n’avions plus qu’une vision parcellaire de notre sécurité. En outre, notre SIEM ne permettait pas de collecter des logs via des API. Or aujourd’hui, énormément d’applications sont en mode SaaS ».

L’outil était loin d’être le « single pane of glass » que doit être le SIEM pour le SOC et l’équipe de sécurité devait jongler chaque matin avec une dizaine de consoles pour avoir une idée des événements de la nuit.

En outre, les règles de détection mises en place lors du lancement du SOC n’étaient plus adaptées. Les noms des groupes Active Directory dans les règles avaient parfois changé, de même que les adresses IP. Sur les plus de 80 règles de détection mises en place à l’origine, seulement une vingtaine étaient encore réellement opérationnelles.

Une liste de critères de sélection plutôt conséquente

Un RFP (Request For Proposal) est alors lancé auprès des éditeurs afin de remplacer ce logiciel. Le nouveau SIEM devait pouvoir s’interconnecter à toutes les sources de logs du groupe, et être compatible avec l’EDR en place. De plus, pour assurer une continuité de service lors de la bascule, les deux SIEM devaient être amenés à fonctionner en parallèle pendant toute cette phase à haut risque.

Enfin, la solution devait être compatible avec le service de Kudelski dont le SIEM n’est que l’un des services proposés via son portail. Le prestataire a proposé à son client une shortlist de produits compatibles et l’équipe de Manuel Henry a établi une matrice d’évaluation sur ses propres critères afin d’opter pour la solution la plus adaptée à son infrastructure. Nombre de sources de logs, technologies ouvertes, compatibilité avec le SOAR en place et visibilité sur le budget ont conduit le groupe à faire le choix de la solution de Hunters Security.

Manuel Henry explique le choix de cette solution encore peu connue en Europe : « il s’agit d’une solution basée sur Snowflake qui offre la capacité d’injecter massivement des logs. Nous voulions reprendre la main sur nos logs, pouvoir injecter l’ensemble de nos logs sans limite et retrouver la capacité de surveiller l’intégralité de notre périmètre. Hunters n’a aucune limitation : on peut injecter autant de téraoctets que l’on souhaite chaque jour. La seule condition est qu’il faut que ce soit des logs de sécurité. Ainsi, nous pouvons injecter la totalité de la télémétrie de notre EDR ».

Le responsable avait également des exigences claires en matière de détection, notamment ne plus devoir créer des règles de détection par agrégation/corrélation. Or, Hunters implémente une méthode de détection par scoring, une approche jugée particulièrement souple tant en phase de Build que de Run, avec une capacité d’ajustement très fin du comportement du SIEM.

« C’est une nouvelle manière de travailler. Auparavant, à chaque alerte du SIEM, il fallait investiguer pour qualifier l’incident. Aujourd’hui, on s’attaque en priorité aux Story qui ont le plus gros score, puis on descend dans la liste petit à petit. »

La détection est basée sur des modules, des Detectors, qui collent à la matrice ATT&CK de MITRE. À chaque type d’attaque correspond un Detector associé. L’éditeur en propose plus de 300 par défaut et, en fonction de l’existant, l’entreprise active les Detectors correspondant à ses besoins. Pernod-Ricard en a activé 180 qui ont pu être personnalisés pour coller au plus près de son environnement. En outre, le renseignement sur les menaces est directement intégré au produit et Kudelski fournit plusieurs flux qui viennent alimenter le SIEM Pernod-Ricard.

Pour la phase de Build, l’équipe projet est partie du framework de gestion de risque et, pour chaque ligne du registre des risques, l’équipement de sécurité correspondant a été identifié. De même, avec MITRE ATT&CK, la technologie associée à chaque technique d’attaque est clairement indiquée. Le framework ETSI GS ISI, européen, et qui décrit les scénarios d’attaque, n’est pas oublié.

À partir de tous ces frameworks du renseignement sur les menaces et des opérations de Red Team et Purple Team déjà menées, l’équipe projet a constitué une liste des technologies prioritaires à embarquer dans le SIEM : celle-ci comprend l’EDR, le réseau pour détecter les attaques Nord/Sud et Est/Ouest, les briques liées aux identités, le XDR, la messagerie, Microsoft Teams, le proxy, le WAF, le Reverse Proxy. La surveillance de l’outil d’accès distant déployé dans les usines du groupe figure aussi dans le périmètre de surveillance.

Un déploiement plus compliqué que prévu

Le déploiement a démarré par la connexion des sources de logs au SIEM. Réutiliser le système de collecte de logs existant n’a finalement pas été possible : le serveur Windows Event Collector en place était limité à 500 événements par seconde, alors que Pernod Ricard avait besoin de monter jusqu’à 5 000… L’architecture de collecte a dû être revue en conséquence. Par contre, en une journée seulement, tous les logs collectés par API ont été configurés. 

La personnalisation des Detectors a été réalisée en 1 mois, avec une contextualisation des règles pour diminuer les faux positifs. Une équipe a été dédiée au projet, car le timing était très tendu : tout devait être opérationnel avant les JO et la vague d’attaques qui était attendue lors de l’événement.

L’impossibilité de réutiliser l’infrastructure de collecte en place et une réorganisation du département technique de la DSI vont compliquer la tâche de l’équipe projet, mais celle-ci a pu mener le projet à bien dans les temps : « nous avons décidé de basculer en Run lorsque 80 % des sources de données étaient connectées. Les 20 % restantes étant les plus compliquées à connecter, nous ne voulions pas attendre des mois et des mois pour arriver au bout. Comme dans tout passage du Build au Run, nous nous sommes pris une énorme vague d’incidents et l’équipe projet s’est attelée à réduire ce volume ».

Une nouvelle manière de gérer les incidents de sécurité

Le responsable estime que le SIEM de Hunters apporte à la fois les moyens de mieux détecter les incidents de sécurité, mais aussi de diminuer les faux positifs grâce à sa technologie de scoring. Toute la détection repose sur la notion de lead, une alerte remontée sur le SIEM à laquelle le logiciel ajoute des métadonnées.

À chaque lead est associé un score et tous les leads ayant une métadonnée en commun sont liés entre eux et forment un graphe baptisé Story : « l’avantage de la méthode est que l’on affecte un poids, le score, sur chaque lead. Par exemple, si une métadonnée correspond à un nom d’utilisateur Admin, on va mettre un poids élevé ».

La Story cumule le score de l’ensemble des leads qui la composent. Ce score qualifie la criticité de l’incident : « c’est une nouvelle manière de travailler », explique Manuel Henry. Plus précisément, « auparavant, à chaque alerte du SIEM, il fallait investiguer pour qualifier l’incident. Aujourd’hui, on s’attaque en priorité aux Story qui ont le plus gros score et on descend dans la liste petit à petit, puis on recommence le lendemain. Cela suppose que certaines Story en bas de la liste ne seront jamais traitées, mais c’est normal. Il faut l’accepter ; c’est une nouvelle approche ».

Comme son nom l’indique, la solution privilégie le Threat Hunting, ou chasse aux menaces. La visualisation des incidents de sécurité à partir des Story est particulièrement éloquente. En outre, l’analyste dispose par défaut de 12 mois de logs stockés à chaud.

Le responsable souligne la jeunesse de la solution : « il y a des manques dans les documents d’intégration, il n’y a pas de communauté d’utilisateurs et les petits bugs sont encore nombreux, mais ils sont résolus rapidement ». Néanmoins, Manuel Henry estime que ce SIEM de nouvelle génération a permis au groupe de progresser en matière de qualité de détection, et réduit le nombre de produits à mettre en œuvre.

Les prochaines étapes du projet portent sur la mise en place de boucles d’amélioration continue, la reconstruction des playbooks et des règles de contextualisation. Manuel Henry souhaite encore compléter le périmètre de détection et interconnecter Hunters avec l’ITSM et l’outil de KPI interne. Viendront ensuite l’automatisation via le SOAR et enfin la mise en place d’un SOC métiers, pour donner la capacité aux métiers d’avoir une vue sur les alertes concernant leurs systèmes.

Propos recueillis lors des Assises de la sécurité 2024