Le groupe Vinci appuie son SOC sur un Microsoft Sentinel un peu particulier

Cyber Shields, le plan de transformation Cyber du groupe

Afin d’accroître le niveau de sécurité du groupe, un plan de transformation a été établi par le CISO Group sur la période de 2022 à 2024. Ce plan, baptisé Cyber Shields, couvre 4 grandes thématiques. Un premier volet porte sur la politique de sécurité, la gouvernance, les campagnes de sensibilisation à mener auprès des utilisateurs. Le second porte sur la mise à disposition d’un socle technologique commun qui couvre la protection de la messagerie électronique, la sécurité du poste de travail, la conformité de l’Active Directory, la gestion des vulnérabilités et celle des identités et des accès. « Sur la partie protection du poste de travail, le groupe a choisi un EDR que chaque pôle instancie en fonction d’un guide d’installation du groupe pour obtenir un certain niveau de standardisation », ajoute le responsable.

Enfin, le troisième volet du plan porte sur les services, avec une approche « Cyber as a Service » qui vise à mutualiser certains investissements. C’était déjà le cas du CERT créé 2019 et qui délivre des informations de sécurité à l’ensemble des pôles d’activité du groupe. Ce dispositif a été complété il y a un an par un SOC externalisé auprès d’I-Tracing : « nous avons construit le service Vinci SOC avec pour enjeu de l’adapter à notre organisation. Nous avons souhaité élaborer une stratégie de détection au niveau groupe et qui soit applicable et réplicable sur l’ensemble des pôles d’activité ».

En outre, le processus de réponse à incident doit être adapté. Impossible d’imposer les mêmes contraintes sur une entité de 15 000 collaborateurs et sur un petit aéroport à l’étranger qui ne compte qu’une centaine de personnes sur place… Pour ces derniers, l’opérateur de SOC doit délivrer une aide à la réponse à incident et service H24.

Une architecture de SIEM multiniveau

Du fait de l’organisation du groupe Vinci, le SOC devait s’appuyer sur une technologie capable de monter à l’échelle sur 2 niveaux : d’une part, fonctionner en multi-instances pour s’adapter à l’organisation par pôles d’activité du groupe Vinci, mais aussi pouvoir s’étendre et intégrer facilement de nouveaux environnements en cas de croissance externe et élargir facilement le périmètre de couverture du SOC. Enfin le SOC devait être alimenté par la base de Threat Intelligence du CERT Vinci, mais aussi d’un fournisseur externe, Sekoia.io.

Le choix du partenaire I-Tracing est acté en 2021 et les fondations du SOC sont bâties tout au long de l’année 2022. L’ensemble des briques fonctionnelles et techniques sont alors définies, ainsi que le processus d’onboarding qui est soigneusement documenté. Une cinquantaine de scénarios d’onboarding différents sont imaginés, avec des entités qui vont de 50 jusqu’à 15 000 personnes et des environnements techniques très différents.

« Pour répondre à l’enjeu de s’adapter à notre organisation. Nous avons souhaité élaborer au niveau groupe une stratégie de détection qui soit applicable et réplicable sur l’ensemble des pôles d’activité. »

L’intégration technique est menée en 2022 et les premières entités rejoignent le projet. Fin 2022, elles n’étaient encore que 5, mais en 2023 ce sont 40 entités de plus qui doivent rallier le SOC. « Outre l’ajout de nouvelles entités, nous allons étendre le service sur la profondeur de détection, augmenter les capacités de détection et surtout donner la pleine capacité au SOC d’être en mesure de réagir en cas d’incident. En 2024, nous devrons accompagner les petites entités et mener la réponse à incident à leur place », explique Yann Sladek. 

120 000 utilisateurs couverts au terme du déploiement

En 2022, le core model du SOC est présenté aux différentes entités. La partie détection est déployée de manière progressive auprès de 120 000 utilisateurs finaux ; ce volet doit être achevé en 2024. Des guides de configuration ont été rédigés pour chaque technologie mise en œuvre. L’équipe projet a également beaucoup travaillé sur la standardisation des plans de remédiation.

Des préconisations ont été fournies aux entités qui, jusque-là, ne réagissaient pas toutes de la même manière à un incident. L’architecture de collecte a été standardisée et tous les éléments attendus pour lancer une remédiation ont été structurés afin que le travail de remédiation soit le même pour toutes les entités.

Un dernier élément très important pour l’équipe projet était de structurer au maximum la phase de onboarding des entités dans le SOC et d’anticiper au maximum l’ensemble des besoins. « Le processus de onboarding reste relativement rapide, notamment sur les petites entités. Notre principal challenge, ce sont les 65 concessions que nous gérons dans le monde et sur lesquelles on ne peut se permettre de mener des projets de 3 mois. Nous avons cherché à simplifier au maximum les actions à mener par les équipes. Onboarder un aéroport nous demande entre 2 à 5 jours d’intégration dans le SOC », illustre Yann Sladek.

En termes d’outillage, l’équipe projet a fait le choix de Microsoft Sentinel pour la partie SIEM et sur Cortex XDR de Palo Alto Networks pour la protection des hôtes. « Nous avons ajouté la brique Cortex XSOAR qui assure la centralisation des alertes et les interfaces entre les différents outils. Nous assurons ainsi l’intégration des bases de renseignement sur les menaces de notre CERT et les données venues de Sekoia.io », explique le responsable.

Les alertes générées par Cortex XDR convergent vers Cortex XSOAR qui alimente le SIEM Microsoft Sentinel, de même que les logs issus des ressources on-premise par pays et par datacenters ainsi que celles des environnements SaaS Zscaler, Palo Alto Prisma Access.

« Nous avons déployé Microsoft Sentinel sur une architecture assez spécifique », souligne Yann Sladek. « Nous avons déployé une instance Sentinel et Log Analytics dans les tenants Azure de chaque pôle. Ils y déversent l’ensemble de leurs logs et en gèrent totalement les droits d’accès ».

Vinci peut potentiellement instancier autant de Sentinel que nécessaire sur les tenants Azure sans remettre en cause cette architecture. « Ce qui est intéressant avec ce modèle, c’est que l’instance groupe ne stocke aucune donnée », ajoute-t-il. « Sa prérogative est d’avoir la stratégie de détection qui est chargée dans l’ensemble des instances locales. Les données sont conservées en local et chaque pôle d’activité reste maître de sa donnée. Par contre, la détection reste de notre ressort et nous venons la propager sur toutes les instances du groupe ».

Un programme qui doit être bouclé fin 2024

Le projet a démarré le 26 octobre 2022 et, un an plus tard, 60 % de la roadmap a été réalisé. Les 100 % seront atteints en fin d’année 2024 : « le projet a aujourd’hui une très bonne visibilité dans le groupe. Nous avons pu en démontrer la valeur, détecter différents incidents et confirmer l’apport du service dans le quotidien des équipes. La gouvernance est bien établie entre les équipes SOC d’I-Tracing et les équipes opérationnelles ».

Yann Sladek explique que la stratégie de détection partagée est amenée à évoluer en fonction des besoins. Si une entité manifeste un besoin et que l’équipe SOC développe une nouvelle règle de détection, celle-ci devient applicable à l’ensemble de l’organisation. 

Si, du point de vue du service délivré, il estime que les objectifs en matière de visibilité et de suivi du traitement des incidents sont atteints, le volet remédiation est l’un des axes de progrès pour l’avenir : « lorsqu’on s’adresse aux équipes centralisées, cela se passe très bien, mais nous devons encore accompagner techniquement certaines équipes locales très décentralisées qui n’ont pas toujours la connaissance du produit. Le fait de détecter les menaces très tôt accélère l’enjeu de la délégation de la réponse à incident. C’était prévu pour 2024, mais nous avons déjà commencé à donner des pouvoirs au SOC afin de réaliser certaines actions de remédiation dès la détection ».

Quant au choix de Microsoft Sentinel en tant que SIEM, une solution encore très jeune puisque sa disponibilité remonte à 2019, Yann Sladek se félicite de ce choix : « la solution est encore assez récente et a connu des évolutions assez importantes d’un point de vue technologique, évolutions auxquelles nous avons dû nous adapter. Un point négatif cependant, c’est que les solutions cloud sont facturées à la consommation. Il faut donc nécessairement mettre en place un suivi financier. Néanmoins, le travail que nous avons réalisé dans la rédaction des guides de configuration a permis de définir ce dont nous avons réellement besoin. Cela permet de filtrer en amont des données qui viendraient alourdir la facture inutilement ».

Toujours sur le volet financier du projet, sachant que les coûts de mise en place du SOC sont très élevés lors de la mise en place et du démarrage, une subvention a été versée aux premiers entrants afin que ceux-ci ne soient pas pénalisés par rapport à ceux qui vont arriver par la suite. 

Propos recueillis lors de l’édition 2023 des Assises de la Sécurité.