Pourquoi l’Urssaf a réinternalisé son SOC

Un premier essai non concluant

La genèse de ce SOC remonte à 2012, avec le déploiement d’un SIEM d’ancienne génération et 3 personnes pour opérer ce SOC. Avec une maturité alors limitée sur la question, le projet se solde par un échec et va être finalement abandonné : « il fallait tout voir, tout le temps, partout et nous n'étions pas prêts pour ça », résume Keran Campeon, le responsable actuel du SOC de l’Urssaf.

En 2017, un centre opérationnel de sécurité est finalement créé. Une équipe de 5 personnes est mise en place pour construire ce SOC. Celle-ci peut s’appuyer sur une pile ELK déjà en production pour mettre en place une collecte des logs. Des intégrations sont développées pour les sources non supportées, les premiers tableaux de bord mis en place. De quoi faire de la supervision. La solution ElastAlert permet de mettre en place les premières alertes.

En 2019, cette approche est remise à plat. Une étude de NDR est lancée pendant un an, mais ne donne pas suite : « le NDR nous amène une vue télémétrique purement réseau, mais l’EDR était encore en cours de déploiement. Nous n’avions pas de vision sur les endpoints et nous n’avions pas de SIEM. Nous étions en train de multiplier les consoles de supervision et des analystes qui devaient se connecter partout pour essayer de voir quelque chose ».

En parallèle, les services exposés sur Internet subissaient régulièrement des incidents. Qu’il s’agisse d’attaques par force brute ou de credential stuffing, il devenait urgent de mettre en place une surveillance en 24-7 sur ce périmètre, ce dont l’équipe en place n’était pas en capacité de faire.

Outre un mécanisme d’astreinte, la surveillance de ces applications est assurée par un prestataire externe dans une approche SOC hybride. Celui-ci prend en charge et analyse les alertes et escalade les alertes. Les scénarios de détection sont ceux de l’OWASP, plus quelques scénarios de détection de fraudes. De l’ordre de 2 000 événements par seconde sont ainsi traités. Une force d’intervention rapide externe est mise en place pour intervenir en cas d’incident majeur. Un dispositif qui n’a pas eu à être activé à ce jour.

Un service managé sur un périmètre très limité

Le service managé entre en production en mars 2022, mais en parallèle, une veille est lancée sur la mise en place d’une SIEM en interne. En effet, le périmètre confié au prestataire est très restreint, 2 applications seulement sur les 800 que compte l’Urssaf…

Une dizaine de solutions sont étudiées sur le papier et trois sont finalement sélectionnés pour mener des PoC. C’est lors de cette évaluation que Sekoia s’invite dans la compétition et remporte le marché : « ce qui nous a plu, c'est vraiment le niveau d'échange qu'on a pu avoir avec eux. Ils ont pris très au sérieux nos idées d'évolution et en ont déjà même inscrit dans leur roadmap dès la phase de POC ».

En outre, le volet souveraineté plaide en faveur de l’éditeur français. L’Urssaf cherche une solution SaaS et l’hébergement en France de la plateforme est un argument de plus pour Sekoia.io. En outre, le langage de détection Sigma mis en œuvre sur sa plateforme séduit les techniciens : « Sekoia a une approche basée sur des standards, une approche normative. Le langage de détection de Sekoia, Sigma, est très facile d’usage. On définit des fonctions qui matchent, des règles de détection et le processus de corrélation de ces différentes fonctions de matching. Il y a très peu de limites ».

Un périmètre restreint de déploiement est défini et la solution est mise en production. L’objectif était qu’à la fin d’une année d'expérimentation, l'outil ait été adopté par les équipes et soit bien intégré au process de production du SOC. Mission accomplie puisque le nombre d’actifs sous surveillance est passé de 10 000 à 20 000, puis 30 000, et que le déploiement a pu être généralisé.

En 2024, une extension du périmètre applicatif surveillé est lancée, puisque seules 2 applications sont surveillées par le prestataire externe. Une étude est lancée en parallèle sur la capacité de l’équipe SOC à réinternaliser cette surveillance : « nous avons finalement fait ce choix de réinternaliser, parce qu'on a les capacités humaines, les compétences, l'outillage, et le niveau de service. Avec les playbooks de Sekoia, sur une alerte, la solution envoie une requête à notre plateforme d'envoi de SMS jusqu'à la prise en charge de l'alerte ».

La décision est prise en septembre 2024. En novembre, le projet de réinternalisation du périmètre confié jusque-là au SOC managé est lancé et rapidement mené à bien : « depuis, nous avons continué à déployer, et nous sommes allés très vite. Cet été, nous avons décidé de massifier le déploiement au niveau applicatif. Nous avons intégré toute la partie navigation des usagers, ce qui nous a demandé un mois environ ». Pour le responsable, il s’agit plus de router de nouveaux flux que de devoir résoudre de réels problèmes techniques.

Mistral vient épauler l’IA de Sekoia.io

L’heure est désormais à la modernisation de ce SOC et d'aller vers ce que l’on appelle aujourd’hui les analystes augmentés : « avec Sekoia, quelle que soit la source de détection, nous avons la capacité de gérer nos alertes : pour chaque alerte, nous avons accès à beaucoup de choses, les tâches dédiées à un analyste, la liste d’actions rapides à mener, les événements qui ont déclenché cette alerte. On dispose aussi de l’historique des alertes considérées comme similaires. On peut rapidement aller voir comment l’alerte a déjà été traitée, etc. »

L’équipe SOC dispose en outre du contexte de chaque alerte, avec les actifs touchés, le niveau de sévérité, etc. : « nous avons ajouté un serveur Mistral avec un playbook qui déclenche une analyse des événements par le LLM. Nous avons en commentaire une première analyse de l'intégralité des alertes. C'est confortable pour les analystes car si ça ne les empêche pas de continuer à aller voir, ils disposent d'un récapitulatif immédiat de ce à quoi ils ont affaire ». Keran Campeon estime que cette approche est particulièrement utile sur l'analyse des commandes systèmes qui comprennent de nombreux arguments.

En outre, l’apport de la Threat Intelligence est direct puisque l’analyste a accès au renseignement sur la menace depuis son interface, à partir de laquelle il peut basculer sur l’application de CTI qui va lui donner beaucoup plus de données sur les artefacts, les attaquants, etc.

Enfin, l’équipe a mis en place l’approche « detection-as-code », c'est-à-dire gérer les règles de détection sur Git : « pour un MSSP, la question ne se pose pas, mais pour nous, en tant qu’utilisateurs de la solution, nous nous sommes posés la question de l’intérêt de l’approche. Nous avons récupéré toutes les règles de détection de Sekoia, et nous les hébergeons sur un Git. Lorsque nous devons apporter des évolutions, nous le faisons sur Git. Ensuite, les règles sont poussées vers la plateforme préproduction, puis la production ».

Pour Keran Campeon, l’intérêt majeur de la démarche réside dans la gestion des filtres. Quand une nouvelle application est déployée, celle-ci génère énormément d’alertes et l’identifiant de l’application doit être placé sur un grand nombre de règles pour filtrer celles-ci : « le faire en cliquant dans une interface sur chaque règle peut être très pénible. Un simple copier/coller sur Git est beaucoup plus facile », ajoute le responsable.

Autre exemple de la relation entre l’équipe SOC et Sekoia, le service TDR (Threat Detection & Research) de ce dernier. Les analystes peuvent envoyer des artefacts pour que l’équipe Sekoia les analyse : « nous avions un doute sur une investigation et ils sont venus en support sur un malware que nous avions potentiellement récupéré. Ils nous ont confirmé que notre analyse était bonne. Il n’y a pas eu d’impact chez nous, mais c’est rassurant ».

Enfin, l’Urssaf a été bêta-testeur du nouveau service de chasse aux menaces et de revue de conformité de l'éditeur, une nouvelle preuve de la grande proximité entre Sekoia et son client.