Fabien Malbranque (CNAF) : « nous avons migré notre SIEM dans le Cloud pour deux raisons »

Pouvez-vous nous présenter la CNAF (Caisse Nationale d’Allocations Familiales) ?

La Caisse Nationale d’Allocations Familiales (CNAF) est la « branche famille » de la sécurité sociale. Elle a beaucoup évolué depuis 1947.

Elle distribue environ vingt-cinq types d’allocations pour un montant global de 104 milliards d’euros par an au service de 13 millions d’allocataires et 32 millions d’individus (il peut y avoir plusieurs bénéficiaires pour une seule personne recevant une allocation). La principale est l’APL (Aide personnalisée au logement). Notre modèle de calculs d’allocations évolue avec la société, avec une place croissante des individus par rapport aux familles.

La CNAF est à la tête d’un réseau de 101 CAF représentant au total 36 000 salariés sur tout le territoire.

Notre site web Caf.fr reçoit un milliard de visites par an avec de gros pics de fréquentation. Notre relation avec les allocataires est très numérique.

Quel est le rôle de l’IT centrale ?

Au niveau national, nous définissons la politique générale, notamment la PSSI (politique de sécurité du système d’information), et nous émettons des instructions à l’égard du réseau des CAF. Chaque année, nous contrôlons la bonne mise en œuvre de cette PSSI dans une trentaine de CAF.

Nous avons SOC et CERT au niveau national qui détectent les incidents et réagissent, y compris pour les outils locaux. Nous contrôlons notamment les entrées/sorties entre le réseau interne et Internet. La DSI nationale gère en effet le réseau et ce que nous nommons la « dorsale informatique » (le socle dont la bureautique). Et c’est aussi au niveau national que nous traitons le plan de secours, notamment en cas de catastrophe naturelle.

Quelle est l’architecture globale de votre système d’information ?

Nous avons une partie dans le Cloud. C’est notamment le cas avec la bureautique Microsoft Office 365, sur Azure, et un moteur de calculs utilisant les technologies Oracle, sur OCI. Pour notre on premise, nous utilisons une paire de datacenters. Il existe également quelques salles locales dans les CAF.

Nous avons également des initiatives sur des IaaS, SecNumCloud avec Outscale, non-SecNumCloud avec OVH. Nos outils de gestion de la cybersécurité, comme Splunk, sont ainsi installés sur Outscale. Le projet de moteurs d’IA est, à l’inverse, sur OVH.

Pourquoi avez-vous choisi de déployer Splunk dans le cloud ?

Au départ, nous avions déjà un SIEM dans notre datacenter. Et ce SIEM était Splunk.

Notre projet consistait à remettre le SIEM au coeur de la problématique de cybersécurité mais, pour cela, il fallait développer les capacités de stockage et de traitement des données de logs.

Le cloud apporte une grande flexibilité et élasticité pour absorber les pics de sollicitation du système. Faire évoluer un datacenter, avec la problématique des formalités de la commande publique, c’est un délai minimal de six mois.

Mais nous avons migré notre SIEM dans le Cloud pour deux raisons, pas uniquement l’habituelle flexibilité.

La deuxième raison, c’est qu’en séparant le SIEM du datacenter, nous évitons une corruption conjointe des deux. Si le datacenter est bloqué, on n’a plus d’accès à ce qui permet d’expliquer ce qui se passe si le SIEM y est présent. A l’inverse, si le SIEM est dans une autre infrastructure séparée, il y a une chance raisonnable de garder actif et accessible le SIEM afin de comprendre ce qui se passe même si le datacenter est corrompu.

Notre SIEM couvre toute notre architecture, y compris les clouds, avec des niveaux d’information variables. Je ne dispose pas forcément de l’intégralité des logs sur chaque service en ligne !

Concrètement, qu’a apporté la migration dans le Cloud du SIEM ?

Avant la refonte, nous générions 1 To/jour de logs avec une rétention de six mois en moyenne.

Après la refonte, nous générons 3 To/jour, toujours avec six mois de rétention. Pour éviter une explosion des volumes stockés, si les pics de fréquentation sont particulièrement élevés, on peut réduire la durée de rétention. Les logs sont conservés avec une logique FIFO : les plus anciens sont supprimés en premier.

Pourquoi avoir choisi Splunk ?

Le choix avait déjà été fait à mon arrivée en mars 2024. La solution était en place et nos équipes maîtrisaient Splunk.

Notre trajectoire stratégique est liée à la réorganisation. Nous avons donc choisi nos priorités. Changer Splunk n’en était pas une : la solution est critiquée pour son coût, pas pour ses capacités. Nous avons négocié avec l’éditeur dans le cadre d’un achat de licences via une centrale d’achat public, dans le contexte du moment (donc avant l’élection de Donald Trump).

Il était donc intéressant de conserver le même produit en le basculant dans le cloud. Nous avons, vis-à-vis de l’éditeur, une installation type on-premise mais dans un cloud que nous gérons.

L’hébergement est donc réalisé par Outscale et le maintien en conditions opérationnelles par Orange Cyberdéfense.

Y-a-t-il des difficultés ou des points d’attention quand on installe un SIEM dans le Cloud ?

La vraie difficulté est la performance d’accès à des centaines de To de données ! Quand on lance une requête, il nous faut un affichage du résultat avec un délai raisonnable.

Splunk proposait sa solution en partenariat avec AWS mais le DSI a posé un veto à cette solution. Il nous a donc fallu un « Go » technique de l’éditeur pour valider nos choix. Outscale correspondait aux exigences de Splunk pour ses contrats de support et ses garanties, notamment avec un taux de disponibilité granati supérieur à 99,99 %, ce qui est nécessaire pour réaliser la corrélation des logs et la gestion des alertes.

Pour l’instant, le SecNumCloud n’est pas obligatoire pour des logs mais c’était aussi un gage de sérieux. Nous avons évidemment comparé les différentes offres d’hébergement disponibles avec des métriques financières. Nous avons défini des modèles et des scénarios que nous avons soumis à chaque hébergeur (Outscale, Orange, OVH…). Nous avons fait le choix de la meilleure solution.

L’éditeur a effectué un contrôle technique sur un certain nombre de critères tels que la rapidité d’accès à la donnée, la redondance du stockage, la facilité à mettre en œuvre la résilience avec des volumes conséquents…

Nous avons opté pour une approche en « Infra as Code » avec Terraform en orchestrateur. De ce fait, nous bénéficions d’une grande facilité de réversibilité : le code nous appartient.

Quel a été le planning du projet ?

Les première études ont été débutées en mars 2024, à mon arrivée. La commande effective a eu lieu le 29 décembre 2024.

A partir de mi-Avril, nous sommes passés à un schéma en Y : les nouveaux logs ont été orientés vers le cloud. Dès que la profondeur de logs sera suffisante, nous pourrons déconnecter l’ancienne infrastructure. L’infrastructure cloud remplacera donc totalement l’ancienne à la fin 2025.

Quels sont vos autres projets significatifs en matière de cybersécurité ?

Nous consolidons notre position en matière de cybersécurité avec l’application des 24 règles d’hygiène de 2012 de l’ANSSI ! Nous luttons contre les dérives, les obsolescences…

Bien évidemment, nous procédons à des scans de vulnérabilité.

Nous devons également mettre à jour formellement notre politique de sécurité du système d’information pour y inclure des dispositions relatives au Cloud (IaaS, PaaS et SaaS).

Je voudrais également citer l’amélioration de la gestion des identités afin de faire face aux vols d’identifiants et mode de passe d’allocataires.

Enfin, quels sont vos défis pour 2025 ?

Consolider, toujours !

Nous devons achever notre migration Cloud du SIEM et la constitution de nos équipes avec des collaborateurs provenant d’autres services. Les experts techniques doivent également savoir discuter avec les experts en gouvernance.

Les migrations d’anciennes infrastructures sont toujours un sujet.

En interne, nous avons à migrer quelques postes Windows 10 vers Windows 11 avec mise en place de MFA. Il faudrait également mettre en place un MFA pour les allocataires.

Et nous avons à mieux sécuriser les PC en mode kiosque libre-service, dans les CAF, destinés à permettre à des allocataires non-équipés de leur propre matériel de se connecter à nos services. Par exemple de difficulté, nous ne pouvons pas interdire, sur ces machines en libre service, l’usage des clés USB qui permettent aux allocataires d’apporter leurs documents au format électronique. D’un point de vue cybersécurité, l’acceptation de l’usage de clés USB non maîtrisées demande un traitement particulier.

Quand on est RSSI, on doit toujours être un moteur de performance, jamais celui qui dit non. Le RSSI doit donc toujours accompagner, pas bloquer.