Les API de Mon Espace Santé sous haute surveillance
En janvier 2022, la CNAM et la Direction de la Sécurité Sociale lançaient Mon Espace Santé, une déclinaison grand public du DMP, le Dossier Médical Partagé. Un service Web nécessairement sous haute surveillance, tant les données sont critiques.
Complément du DMP alimenté par les praticiens, le site et l’application mobile Mon Espace Santé permettent à tout assuré de consulter ses données médicales et d’ajouter des données complémentaires de taille, de poids, de pression artérielle, ainsi que ses directives de fin de vie. La sécurité du site et de l’application mobile est donc cruciale tant en termes de protection des données personnelles que des données de santé.
RSSI en charge de la sécurité de Mon Espace Santé et du Dossier Médical Partagé à la CNAM, Alexandre Fenyo souligne que la sécurité des API n’est pas un domaine totalement nouveau pour la CNAM : « dès 2006, la direction de la Sécurité sociale, la DGME, et le ministère du Budget et des Comptes publics ont créé un groupe de travail qui a produit, en 2008, la norme Interops d’interopérabilité des organismes de protection sociale pour les échanges d’applications à applications ».
Les technologies en vogue à l’époque pour les Web Services étaient SOAP, XML, XML-DSig pour la signature, de la fédération d’identité avec SAML V2, etc. Dix-huit ans plus tard, les technologies ont beaucoup évolué : la CNAM met en œuvre des règles Json, des jetons JWT, OAuth 2 pour la fédération, et de l’OpenID Connect pour identifier les différents rôles au sein de ces fédérations.
Une architecture de sécurité « classique » pour un service exposé au public
Pour préparer le lancement du service Mon Espace Santé, un appel d’offres public est lancé pour protéger le service. Le RSSI a décrit le besoin et listé toutes les réglementations et bonnes pratiques qui s’imposent à ce service comme la certification des hébergeurs de données de santé, la conformité avec le référentiel général de sécurité.
En tant qu’opérateur de service essentiel (OSE), le service se doit d’être en conformité avec le référentiel NIS et bientôt NIS 2. Eviden (ex-Atos) a remporté l’appel d’offres, notamment en proposant le WAF édité par Ubika.
« Nous avons commencé classiquement en mettant en place un cluster d’IPS, un cluster de WAF qui est le premier élément qui voit le contenu des flux, avec une rupture protocolaire et un chiffrement du flux à la sortie ». Les WAF alimentent un SIEM exploité par les experts du SOC qui analysent les événements et prennent des décisions de blocage ou pas, s’il s’agit de faux positifs.
Présentation de haut niveau de l'architecture de sécurité mise en place.
Si l’infrastructure de sécurité en place semble remplir sa fonction, la direction générale de la CNAM va soulever un problème à la lecture des dashboards qui lui sont remontés : « le directeur général ne comprenait pas ce que nous faisions », raconte le RSSI. « Il nous a envoyé un message indiquant que le dashboard précisait que l’état de la menace était de 2 sur 5 et que 650 000 requêtes issues d’une même adresse IP avaient été bloquées par le WAF en 8 heures. Sa question était de savoir pourquoi avoir attendu 650 000 requêtes pour bloquer cette adresse… ». Une question légitime qui va pousser l’équipe sécurité à se remettre en cause et essayer de bloquer le plus en amont possible l’attaquant, le bloquer au niveau de l’IPS et ne pas surcharger les WAF.
Eviden, intégrateur/hébergeur et mainteneur en conditions de sécurité de la plateforme, va alors pousser l’équipe à utiliser les fonctionnalités avancées d’Ubika. En quelques semaines, un mécanisme est mis en place afin de réaliser un calcul en temps réel d’un seuil non pas sur un nombre d’attaques total, mais sur un taux d’attaques, c’est-à-dire le nombre d’attaques sur une durée donnée. « Cette approche nous permet de décider un blocage temporaire d’une adresse IP, même si on a un faux positif. Si un attaquant utilise le proxy légitime de son entreprise pour lancer un outil de PenTest sur Mon Espace Santé, nous ne voulons pas bannir définitivement l’adresse IP de ce proxy, ce qui serait très pénalisant pour les autres utilisateurs ».
L’idée est de bloquer temporairement l’adresse IP de l’attaquant pour ne pas lui laisser l’occasion de trouver une vulnérabilité. Un compteur cohérent a été mis en place en s’appuyant sur une base de données et une synchronisation des valeurs des compteurs entre tous les boîtiers Ubika en place dans le cluster.
En effet, quel que soit le WAF attaqué, le RSSI voulait disposer d’un décompte global exact du nombre d’attaques. Ce mécanisme, basé sur un dépassement de seuil de taux d’attaque distribué et cohérent, permet d’envoyer une erreur 404 à l’attaquant dès le seuil des 5 000 attaques franchi.
Un Bug Bounty fait le focus sur les attaques applicatives
Autre sujet de préoccupation pour l’équipe de sécurité, les tentatives d’attaques applicatives. C’est un Bug Bounty mené avec Yes We Hack qui va lever le lièvre. Une vulnérabilité repérée par un chercheur lors du Bug Bounty portait sur la vérification des contrats d’interface.
Le pirate éthique a pu démontrer qu’en faisant une requête REST, si le JSON était mal formé, la moitié des utilisateurs se retrouvaient bloqués sur le front pendant 20 secondes. « La requête faisait tomber un pod de notre cluster OpenShift. La cause de ce crash provenait d’une exception Java générée par un problème de parsing sur la requête. Le développeur aurait dû “trapper” cette exception et ainsi empêcher ce plantage ».
« Eviden nous a proposé une solution complète intégrant un WAF CSPM, une offre qui nous semblait aller dans la bonne voie car offrant toutes les garanties de conformité réglementaire. »
Alexandre FenyoRSSI Mon Espace Santé et Dossier Médical Partagé, CNAM
Là encore, c’est en s’appuyant sur les capacités du WAF que l’équipe va trouver une parade rapide à cette attaque : « en donnant les contrats d’interface au WAF, le WAF peut bloquer la requête si le contrat d’interface n’est pas respecté et ainsi protéger l’application, même si toutes les exceptions Java ne sont pas traitées par les développeurs ». L’approche a été mise en place sur l’ensemble des flux API avec les usagers, les partenaires et en interne avec le DMP.
Alexandre Fenyo explique pourquoi il a mis en place cette vérification plutôt que de demander aux développeurs de vérifier le code : « à la différence du PenTest, quand on fait un Bug Bounty auprès d’une communauté de chercheurs en sécurité, ceux-ci doivent être motivés et attendent une récompense. Ils ne doivent pas attendre 6 mois pour obtenir leur récompense. Si on détecte en interne une vulnérabilité dont l’impact est important, on va la corriger très vite. Si l’impact est plus faible, on peut se donner du temps pour trouver une solution. Lors d’un Bug Bounty, on va verser une forte somme au chercheur s’il trouve une faille majeure et celui-ci est prêt à attendre quelques jours, quelques semaines pour toucher sa prime. Or le principe d’un Bug Bounty mené avec YesWeHack, c’est que le chercheur n’est pas seulement là pour trouver des vulnérabilités, mais aussi pour valider la remédiation. Sur les petites vulnérabilités, le chercheur ne veut pas attendre des mois pour récupérer un petit montant. Les délais sont totalement inversés par rapport au PenTest classique ».
« Mais si c’est bien d’être conforme, encore faut-il être efficace techniquement. »
Alexandre FenyoRSSI Mon Espace Santé et Dossier Médical Partagé, CNAM
Pour le RSSI, le meilleur moyen de couvrir rapidement un risque était de ne pas entrer dans le cycle des développeurs, même si ceux-ci sont en organisation agile. Avec des sprints de 3 semaines et des déploiements tous les 3 sprints, le rythme n’est pas suffisant pour motiver les chercheurs participant aux Bug Bounty. « Avec les workflows d’Ubika, nous pouvons ainsi faire évoluer très rapidement le WAF sans entrer dans le cycle de développement du logiciel et avoir une vision réelle de ce qui sera fait, sans devoir apprendre un langage particulier. Ce fut essentiel dans le cadre de la gestion de Bug Bounty et de la motivation des chercheurs », explique Alexandre Fenyo.
L’architecture de sécurité a récemment évolué avec l’arrivée de l’IA pour contrer un autre type de risque, celui du « mésusage » des API : « nous avons des collaborateurs qui travaillent sur l’IA et nous avons réalisé le POC d’un outil qui, via l’IA, peut détecter des anomalies dans des requêtes paraissant tout à fait légitimes. Elles respectent les contrats d’interface ; les contenus respectent les règles de formats attendus. L’algorithme peut détecter les comportements anormaux comme ce que l’on appelle les “mésusages” qui visent à détourner la finalité du système ».
Alors que cet algorithme devait initialement alimenter le SIEM, là encore Ubika va suggérer à l’équipe sécurité de remonter en direct ces alertes via les API de la solution. Ainsi, il est possible d’effectuer un blocage dynamique des flux indiqués par cet outil tiers et donc repousser ces attaques le plus en amont.
Propos recueillis lors d’un atelier organisé durant l’édition 2023 des Assises de la Sécurité.
