4 façons dont la Cnam utilise son WAF
Cotraitante de Mon Espace Santé, la Cnam y a déployé un WAF. Retour, avec son CTO Alexandre Fenyo, sur quelques usages du produit.
Que peut-on faire avec un WAF (pare-feu applicatif) ? Alexandre Fenyo a supervisé la mise en place d'un tel outil sur Mon Espace Santé. Il est revenu sur ce projet lors des Assises de la sécurité 2023.
L'intéressé est depuis peu CTO de Mon Espace Santé (et du Dossier médical partagé). C'est sous la casquette de RSSI qu'il a mené le « projet WAF ».
La Cnam (Caisse nationale d'assurance maladie) et la direction de la Sécurité sociale sont cotraitantes de Mon Espace Santé. Le service est disponible depuis le 13 février 2022. Son objectif : compléter le DMP en permettant de stocker plus que des documents de santé (par exemple, taille, poids, tension artérielle...) et de définir des choix personnels.
« On fait de la sécurisation des API depuis bien longtemps », affirme Alexandre Fenyo. Et de rappeler l'existence, depuis 2008, de la norme InterOPS (Interopérabilité entre organismes de protection sociale). « Cette norme utilisait les techniques de l'époque : SOAP/XML, fédération d'identités SAML v2... Aujourd'hui, on fait du REST/JSON avec des jetons JWT, de l'OAuth 2 pour la fédération et de l'OIDC pour identifier les différents rôles au sein de ces fédérations. »
Atos a remporté le marché public qui a mené à la mise en place du WAF (DenyAll, devenu Ubika). Le SI concerné est exposé (ouvert sur Internet, pour les usagers). L'architecture retenue est « classique » avec un cluster d'IPS et un cluster de WAF (premier élément à voir le contenu des flux ; il réalise une rupture protocolaire puis rechiffre les flux, qu'il envoie vers le SI). S'y adjoint un SOC.
Lire aussi : Du RAG aux agents, les choix GenAI de Doctolib
Voici quatre angles sous lesquels l'outil a été implémenté.
Un décompte global des attaques
« On s'est aperçu, au bout de quelques semaines, que le DG ne comprenait pas ce qu'on faisait », explique Alexandre Fenyo. Le dirigeant s'était notamment étonné du décalage entre l'état annoncé de la menace (2/5) et le fait d'avoir attendu pour bloquer une adresse IP à l'origine de 650 000 requêtes en l'espace de 8 heures.
Comment allait-on faire pour ne pas attendre autant avant de décider de ne pas répondre à de telles IP, même si des requêtes légitimes font partie du flux ? « [Admettons qu'on ait] quelqu'un d'un peu joueur qui utilise le proxy de son entreprise - parfaitement légitime - et lance un pentest sur Mon Espace Santé. On ne peut pas bannir définitivement l'adresse IP », résume Alexandre Fenyo.
En quelques semaines, l'équipe a mis en place un mécanisme permettant de réaliser des calculs « temps réel » de seuils, non pas sur des nombres d'attaques, mais sur des taux d'attaques. C'est-à-dire le nombre d'attaques sur une durée donnée.
Pour avoir un décompte globalisé quel que soit le composant WAF attaqué, la Cnam a exploité un mécanisme de synchronisation des valeurs d'incrément au des différents boîtiers du WAF. Cela lui a permis de réagir plus tôt. « On répond erreur 404, sans en dire plus. [...] L'attaquant [...] ne saura pas que même ses requêtes légitimes sont bloquées. »
Une jonction avec un bug bounty
Alexandre Fenyo est formel : « On s'est aperçu qu'avec un bug bounty, on a des exigences de délais qui sont l'inverse de ce qui se passe habituellement quand on fait de la gestion des risques en interne. »
En interne, on aura tendance à gérer les risques par la priorité (corriger d'abord les vulnérabilités à impact important). Avec un bug bounty, on est prêt à verser une grosse somme... et le chercheur est prêt à attendre quelque temps avant qu'on lui verse la prime. « On a envie de le faire attendre, confie Alexandre Fenyo. Il est là pour détecter les vulnérabilités, mais aussi pour valider la remédiation ».
Le meilleur moyen de couvrir rapidement un risque n'est pas forcément d'attendre le cycle développement-qualification-déploiement. Même si on est dans des sprints agiles, ce rythme ne suffit pas à motiver les chercheurs, constate le RSSI.
« On s'est aperçu que [le WAF] permettait de faire des prises de décision pour identifier l'occurrence de l'exploitation d'une vulnérabilité et bloquer, poursuit-il. On s'est aussi aperçu que le mécanisme de configuration des workflows par un logiciel graphique permettait de nous assurer que la façon dont le blocage est fait représentera bien ce que les développeurs implémenteront ». Il est donc possible de faire évoluer le WAF sans attendre le cycle en question, tout en ayant une vision sans avoir à apprendre un langage particulier.
Cette évolution prend la forme de patchs délivrés à travers la plate-forme de bug bounty. En l'occurrence, YesWeHack. Lorsqu'un hunter trouve une vulnérabilité, il fait un rapport. L'entreprise peut alors demander un correctif au service support d'Ubika.
Vérifier respect des contrats d'interface
Cet usage trouve son origine dans les remarques d'un chercheur YesWeHack. « Lorsqu'il faisait une requête web service REST avec du JSON malformé, la moitié des utilisateurs étaient bloqués sur le front pendant 20 secondes (la moitié, parce qu'on est sur deux sites). » Une requête faisait tomber un pod sur un cluster OpenShift d'un site en raison d'une exception Java... que les développeurs n'avaient donc pas « trappée ».
« [Atos] nous a dit : le WAF est capable de faire des choses intelligentes au niveau des API. Il a conscience de ce qu'est du GraphQL, du REST, du SOAP... Pourquoi ne pas lui donner les contrats d'interface, et si le contrat n'est pas respecté, le WAF bloquera ? »
Piloter avec des outils tiers
Certaines attaques se propagent par les champs des appels API. Exemple avec Log4j, qui peut exploiter un petit texte ne respectant pas le format attendu dans un paramètre JSON.
En plus d'appliquer les règles habituelles à l'intérieur de tous les paramètres API, la Cnam a cherché à ajouter de la protection via des outils tiers. En particulier, un, alimenté à l'IA, qui permet de détecter les mésusages (utilisation normale d'un système, mais en essayant de détourner sa finalité).
« On a vu qu'on pouvait, via le service de présentation d'API, remonter en direct, dans notre base d'informations, des actions (bloquer tel type de flux selon tel critère », explique Alexandre Fenyo. Cela a consisté à créer un endpoint sur lequel les utilisateurs s'authentifient grâce à des tokens JWT. Les instances du WAF partagent la base qui stocke les informations.
Lire aussi : La stratégie "green coding" d'AXA passe par les API
Illustration principale © ArtemisDiana - Adobe Stock
Sur le même thème
Voir tous les articles Cybersécurité