Conseil en sécurité
pour entreprises

Défi

Visibilité limitée sur les menaces automatisées malgré la présence de CAPTCHA

Défi

Migration d’un WAF existant sous-performant vers la plateforme Akamai sans perturber les services de paiement en production et les services orientés client.

Service

Migration WAF, intégration Akamai, développement de règles personnalisées, analyse du trafic, gestion du changement

Un groupe européen de services financiers utilisait une solution WAF existante depuis plusieurs années, mais la plateforme devenait de plus en plus insuffisante. La gestion des règles était complexe, les taux de faux positifs étaient suffisamment élevés pour que l’équipe opérationnelle commence à désactiver des protections sur des endpoints clés afin d’éviter un impact sur les clients, et la réactivité du support du fournisseur s’était détériorée. L’équipe de sécurité avait perdu confiance dans l’outil, et un audit interne a signalé la couverture limitée du WAF comme un risque de conformité avant leur prochaine évaluation PCI-DSS.

Le client a sélectionné Akamai comme plateforme de remplacement mais ne disposait d’aucune expérience interne avec la suite de produits de sécurité d’Akamai. Il avait besoin d’une équipe capable de gérer la migration complète — pas seulement la bascule DNS, mais aussi la traduction des règles, le profilage du trafic et le travail d’ajustement qui déterminent si une migration WAF réussit ou échoue en production.

Nous avons commencé par un audit détaillé de la configuration existante du WAF : quelles règles étaient actives, lesquelles avaient été désactivées et pourquoi, quelles règles personnalisées avaient été créées et où se situaient les problèmes connus de faux positifs. Cela nous a donné une vision claire de ce qui protégeait réellement les applications par rapport à ce qui existait uniquement sur le papier. Nous avons ensuite comparé cela aux ensembles de règles Kona Site Defender d’Akamai, en identifiant où les règles gérées d’Akamai offraient une couverture équivalente ou supérieure par défaut, et où des règles personnalisées devaient être développées à partir de zéro.

La migration a couvert 34 propriétés web réparties sur trois unités commerciales, chacune avec des architectures applicatives et des profils de trafic différents. Pour chaque propriété, nous avons configuré les politiques WAF d’Akamai en mode alerte uniquement dans un premier temps, en les exécutant en parallèle avec le WAF existant pendant au moins deux semaines. Pendant cette période, nous avons analysé chaque règle déclenchée par rapport au trafic réel afin d’ajuster les seuils, de mettre sur liste blanche les comportements légitimes des applications et de valider que le nouvel ensemble de règles ne bloquerait pas de vrais clients. Ce n’est qu’après validation complète que nous avons activé le blocage et retiré l’ancien WAF.

La partie la plus complexe du projet a été la gestion des endpoints d’API de paiement. Ceux-ci transportaient un trafic de transaction soumis à des exigences strictes de latence et à des contrôles PCI-DSS. Nous avons travaillé en étroite collaboration avec les équipes d’infrastructure et de conformité du client pour concevoir un plan de bascule incluant des tableaux de bord de surveillance en temps réel, des déclencheurs de rollback prédéfinis et une cellule de crise dédiée pendant la fenêtre de migration. Les endpoints de paiement ont été migrés avec succès sans aucun impact pour les clients.

Défi

Attaques soutenues de credential stuffing entraînant des blocages de comptes, des plaintes clients et un risque potentiel de prise de contrôle de comptes.

Service

Atténuation des bots, optimisation du WAF, analyse des empreintes, réponse aux incidents

Une entreprise de gaming faisait face à une campagne persistante de credential stuffing — des attaques automatisées utilisant des combinaisons de noms d’utilisateur et de mots de passe volés provenant de violations de données tierces afin de tenter des connexions massives. Ces attaques provoquaient des milliers de blocages de comptes légitimes en raison des seuils d’échecs de connexion, entraînant une augmentation des appels au support et créant un risque réel de prise de contrôle de comptes pour les clients réutilisant leurs mots de passe.

L’entreprise disposait d’un WAF, mais ses règles de limitation de débit étaient trop rudimentaires : elles bloquaient une partie du trafic automatisé mais affectaient également les utilisateurs légitimes, tandis que des attaquants plus sophistiqués contournaient les limites en faisant tourner les adresses IP et en distribuant les requêtes pour rester sous les seuils.

Nous avons adopté une approche en couches. Tout d’abord, nous avons déployé une analyse avancée des empreintes au niveau du point de connexion afin d’identifier les sessions automatisées en nous basant sur des signaux comportementaux et des caractéristiques d’appareil plutôt que uniquement sur la réputation IP. Ensuite, nous avons restructuré les règles de limitation du WAF en utilisant des clés composites — combinant IP, empreinte de session et modèles de user-agent — afin que les attaques distribuées ne puissent pas contourner la détection simplement en changeant d’adresse source. Enfin, nous avons intégré des défis CAPTCHA déclenchés dynamiquement en fonction du niveau de risque, plutôt qu’appliqués systématiquement, afin de maintenir une faible friction pour les utilisateurs légitimes.

Enfin, nous avons travaillé avec l’équipe fraude du client pour construire une couche de corrélation entre les tentatives de connexion bloquées et des bases de données connues de identifiants compromis, permettant une notification proactive aux clients dont les identifiants avaient été exposés.