Laura Santeusanio
Directeur Régional Europe du Sud
Une dirigeante internationale comptant plus de 20 ans d'expérience dans le pilotage de la croissance, l'expansion commerciale et la transformation à travers l'Europe. Directrice générale chevronnée, experte dans le développement d'activités, la constitution d'équipes de haute performance et l'exécution stratégique au service de résultats mesurables.
Points clés à retenir:
Aucune intrusion technique: Une fuite récente et très médiatisée au sein d'une fintech ne découlait d'aucun piratage informatique. Les cyberattaquants ont utilisé un compte e-mail gouvernemental compromis pour demander des données clients, et l'entreprise les leur a transmises en croyant la requête légitime.
Une faille procédurale prolongée: Selon les informations disponibles, ce schéma s'est répété pendant des mois avant d'être détecté. Non pas parce qu'un e-mail a échappé à un filtre, mais parce que le processus de vérification lui-même était incapable de repérer une demande falsifiée portant tous les attributs d'une origine authentique.
Les limites de l'authentification technique: Les protocoles de sécurité e-mail (SPF, DKIM, DMARC) confirment uniquement qu'un message provient d'un domaine authentique. Ils ne garantissent en rien que l'expéditeur était habilité à formuler cette demande, ni que la requête elle-même était légale.
Des éléments encore incertains: Plusieurs des détails les plus spectaculaires qui circulent encore — le volume exact de données concerné, le montant de la rançon ou la durée d'exposition du compte gouvernemental — proviennent des affirmations des attaquants et n'ont été confirmés par aucune autorité officielle.
La véritable solution: La réponse ne réside pas dans un meilleur filtre anti-spam, mais dans une procédure de vérification obligatoire et documentée pour ce type précis de demandes — une procédure formalisée sur le papier et rigoureusement appliquée sur le terrain, même sous la pression.
Ce qui s'est réellement passé
La reconstitution issue des enquêtes journalistiques est limpide, et c'est précisément ce qui la rend troublante. Un cyberattaquant a pris le contrôle d'un compte e-mail appartenant à une administration publique authentique. Depuis ce compte, il a adressé à la fintech des demandes d'informations clients présentées comme des réquisitions des forces de l'ordre. Émanant d'un domaine gouvernemental légitime, ces messages ont passé sans encombre les vérifications techniques luttant habituellement contre l'usurpation d'identité, avant d'être orientés vers le circuit classique de traitement des demandes officielles et judiciaires.
L'entreprise a estimé ces demandes légitimes et a transmis les données. Elle a par la suite qualifié l'incident d'escroquerie par usurpation d'identité externe plutôt que d'intrusion au sein de ses propres systèmes, une interprétation qui résiste à l'analyse : aucune preuve d'intrusion réseau n'a été rendue publique, et la société a confirmé que les fonds des clients comme ses systèmes internes n'avaient jamais été compromis. En revanche, il s'agit bien d'une fuite de données personnelles au sens du RGPD, peu importe qu'un serveur ait été touché ou non. Une divulgation non autorisée à un tiers non habilité constitue une fuite de données, point final.
Un expéditeur vérifié ne garantit pas une demande légitime
Le constat inconfortable sous-jacent à cet incident révèle une faille que la plupart des organisations n'ont pas encore intégrée: l'authentification et l'autorisation sont deux enjeux distincts, alors que la majorité des procédures de communication de données ne contrôlent que le premier.
Les protocoles SPF, DKIM et DMARC n'ont qu'un seul rôle: répondre à la question « Ce message provient-il bien du domaine affiché? ». S'ils s'en acquittent parfaitement, ils ne disent absolument rien sur le fait que l'expéditeur soit habilité à formuler cette demande précise, que le fondement juridique invoqué soit applicable, ou que le volume et la nature des données réclamées correspondent à une enquête légitime. Un compte compromis au sein d'un domaine gouvernemental franchit ces trois filtres sans difficulté: le domaine est authentique, mais la personne aux commandes, cette fois-ci, ne l'est pas.
Les requêtes émanant des autorités publiques bénéficient d'un capital de confiance institutionnel qui aggrave cette vulnérabilité au lieu de la réduire. Une demande à l'apparence officielle tend à être traitée plus rapidement et contestée moins souvent, un biais sur lequel les attaquants comptent systématiquement.
Le point qui devrait inquiéter les équipes de conformité plus que la fuite elle-même
L'interception d'un e-mail frauduleux isolé est un incident regrettable. Ce qui s'est produit ici est d'une autre nature: le même schéma s'est répété, sans être détecté, sur une période prolongée. Il ne s'agit pas d'un simple e-mail passible d'avoir échappé à un filtre, mais d'un processus de vérification dépourvu de tout mécanisme capable de détecter une demande falsifiée bien authentifiée, même après plusieurs itérations réussies.
La plupart des organisations disposent de politiques prévoyant un traitement rigoureux des demandes gouvernementales. Très peu peuvent démontrer que cette politique intègre une étape obligatoire et précise, comme la confirmation de la requête via un canal de contact établi de manière indépendante, et non à partir des coordonnées fournies dans la demande elle-même, avant toute communication de données. Faute d'être formalisée et strictement appliquée, cette notion de « traitement rigoureux » se transforme silencieusement en une gestion ordinaire, jusqu'à ce que l'erreur ne se répète.
Ce qui est confirmé et ce qui relève encore de simples affirmations
Traiter un incident en cours avec responsabilité exige de distinguer clairement les faits établis des éléments non vérifiés. À ce jour:
Raisonnablement établi: Un attaquant a utilisé un compte e-mail gouvernemental compromis pour soumettre des demandes frauduleuses de données clients. L'entreprise a transmis les données en croyant les requêtes légitimes. Ses systèmes internes et les fonds des clients n'ont pas été compromis. Les autorités poursuivent leurs investigations.
Rapporté par les médias, mais non confirmé officiellement: Le nombre exact de clients touchés, ainsi que l'administration spécifique dont le compte a été compromis.
Affirmé uniquement par l'attaquant, sans validation officielle: Le volume total de données soi-disant obtenues, la durée pendant laquelle le compte gouvernemental a été compromis et le montant de la rançon exigée. En matière de gouvernance, la règle est claire: les déclarations d'un cybercriminel constituent un levier d'extorsion et non des preuves, tant qu'aucun élément indépendant ne vient les confirmer.
Ce que cela implique pour votre organisation face aux réquisitions officielles
Presque toutes les organisations évoluant dans un secteur réglementé (services financiers, santé, télécoms) disposent d'une procédure pour répondre aux réquisitions judiciaires et administratives, la loi l'imposant généralement. La question soulevée par cet incident n'est pas l'existence de cette procédure, mais la présence d'un contrôle ciblé pour ce cas précis: une demande en apparence irréprochable qui pourrait ne pas l'être.
Un contrôle efficace doit être précis et non généraliste. Il devrait idéalement stipuler: Avant toute communication de données personnelles en réponse à une demande administrative, judiciaire ou des forces de l'ordre, vérifier indépendamment l'identité et l'habilitation du demandeur, le fondement juridique de la requête et son périmètre, en utilisant des coordonnées issues d'une source autonome et non celles fournies dans la demande. Les requêtes inhabituellement volumineuses ou atypiques doivent impérativement faire l'objet d'une double validation avant tout envoi.
Formulée ainsi, la règle paraît évidente. Si elle échoue dans la pratique, c'est parce qu'elle est rarement accessible aux équipes opérationnelles au moment opportun, et quasi jamais éprouvée face à une demande d'apparence parfaitement légitime.
Découvrez comment une étape de vérification de ce type s'intègre dans votre programme de conformité
Apportez votre propre procédure de traitement des réquisitions administratives ou judiciaires, aussi informelle soit-elle aujourd'hui. Nous préférons vous montrer concrètement comment structurer ce contrôle plutôt que d'en parler de manière abstraite.
Comment Formalize vous accompagne
Il s'agit avant tout d'un enjeu de contrôle avant d'être un problème technologique. Le rôle de Formalize est de veiller à ce que ce contrôle existe réellement ailleurs que dans un document politique que personne n'ouvre en situation d'urgence. En pratique, cela se traduit par:
Un contrôle documenté pour les réquisitions administratives et judiciaires: Intégré directement au cœur de votre référentiel aux côtés de vos autres contrôles — plutôt que d'être isolé dans un classeur — et attribué à un responsable désigné.
Des étapes de vérification intégrées au flux de travail: Chaque demande est évaluée selon des critères prédéfinis avant toute communication de données, et non à posteriori.
Une traçabilité complète des validations: L'identité de la personne ayant approuvé la transmission et les motifs de sa décision sont conservés. En cas de contrôle ultérieur, l'argumentaire est immédiatement disponible au lieu d'être reconstitué de mémoire.
Un contrôle mutualisé entre les référentiels: Le risque lié à la communication de données relève du RGPD, mais recoupe également des exigences d'autres cadres réglementaires et normes comme DORA ou l'ISO 27001.
Rien de tout cela ne remplace le jugement humain. Cela garantit simplement que ce jugement s'applique de manière rigoureuse et systématique, à chaque fois, y compris le jour où l'enjeu est critique.