Lorsqu’on parle de résilience dans le secteur bancaire, on pense immédiatement aux cyberattaques, aux pannes informatiques, aux plans de reprise d’activité ou à la disponibilité des applications. C’est évidemment indispensable, mais c’est une vision incomplète de la résilience.
Une banque peut disposer de systèmes redondants, de sauvegardes, d’un SOC performant et d’excellents mécanismes de reprise après incident tout en restant vulnérable à un élément beaucoup plus difficile à sécuriser : la confiance accordée à une demande apparemment légitime. Le cas récent impliquant Revolut est particulièrement intéressant à analyser sous cet angle.
Être résilient, ce n’est pas simplement éviter la panne
La cyber-résilience désigne la capacité d’une organisation à se préparer aux cybermenaces, à leur résister, à récupérer après un incident et à adapter ses défenses. Cette approche est aujourd’hui au cœur de DORA (Digital Operational Resilience Act), le règlement européen qui impose au secteur financier un cadre structuré de résilience opérationnelle numérique.
DORA couvre notamment la gestion des risques liés aux technologies de l’information et de la communication (TIC), la gestion et la notification des incidents, les tests de résilience et les risques liés aux prestataires technologiques. L’objectif n’est donc plus seulement de se demander comment empêcher une attaque. Il faut également savoir ce qui se passe lorsque les mécanismes de prévention échouent et si l’organisation est capable de détecter qu’une situation apparemment normale ne l’est pas.
Revolut : quand l’attaquant ne cherche pas à pirater la banque
Revolut, comme les autres grands acteurs financiers, doit traiter des demandes provenant d’autorités judiciaires et administratives. L’entreprise dispose naturellement de procédures permettant aux autorités compétentes de lui transmettre des demandes concernant ses clients.
Mais un processus parfaitement légitime peut lui-même devenir une surface d’attaque. Si un attaquant parvient à se faire passer de manière suffisamment crédible pour une autorité, il n’a plus nécessairement besoin de pénétrer techniquement dans l’infrastructure de la banque : il peut tenter de convaincre la banque d’effectuer elle-même l’action recherchée.
C’est une différence fondamentale. Dans une cyberattaque classique, l’attaquant cherche à contourner une protection technique. Dans une attaque fondée sur l’ingénierie sociale, il cherche à exploiter les procédures et la confiance de l’organisation. Le processus métier devient alors lui-même une partie de la surface d’attaque.
Une apparence officielle n’est pas une preuve
Le problème dépasse évidemment Revolut. Les entreprises reçoivent quotidiennement des demandes qui semblent provenir de partenaires, de dirigeants, de fournisseurs, de banques, d’administrations ou d’autorités judiciaires. Dans un environnement numérique, l’apparence de légitimité ne constitue pourtant jamais une preuve suffisante d’authenticité.
Une demande sensible devrait donc déclencher plusieurs contrôles indépendants : vérification de l’identité de l’émetteur, contrôle du canal utilisé, examen de la légitimité de la demande et, pour les opérations les plus sensibles, validation supplémentaire ou confirmation par un second canal.
C’est finalement une forme de Zero Trust appliquée aux processus métier. Une demande ne devient pas fiable simplement parce qu’elle ressemble aux demandes que l’organisation traite habituellement.
Le paradoxe des banques numériques
Les banques numériques ont énormément investi dans l’automatisation, et c’est l’une de leurs forces. Des processus automatisés permettent de traiter rapidement des millions d’opérations tout en réduisant les coûts et les délais. Mais cette automatisation crée également un paradoxe : plus un processus est rapide et efficace, plus il devient important de disposer de mécanismes capables d’identifier les situations exceptionnelles.
Une banque extrêmement efficace pour traiter une demande légitime peut également devenir extrêmement efficace pour traiter une demande frauduleuse qui lui ressemble suffisamment. La résilience impose donc parfois de ralentir volontairement certains processus. Une demande inhabituelle concernant des données sensibles ne devrait pas nécessairement être traitée à la même vitesse qu’une opération ordinaire.
Dans certains cas, quelques minutes de vérification valent beaucoup plus que quelques millisecondes gagnées par l’automatisation.
DORA : tester la capacité à résister, pas seulement à redémarrer
Depuis le 17 janvier 2025, DORA impose aux acteurs financiers européens une approche harmonisée de la résilience opérationnelle numérique. Le règlement exige notamment un cadre de gestion des risques TIC ainsi qu’un programme de tests de résilience opérationnelle numérique fondé sur les risques.
DORA prévoit différents types d’évaluations et de tests techniques, allant des analyses de vulnérabilités aux tests d’intrusion. Pour certaines entités financières désignées, le dispositif va plus loin avec les TLPT (Threat-Led Penetration Testing), c’est-à-dire des tests d’intrusion avancés fondés sur des scénarios de menace réalistes.
Il faut toutefois être précis : DORA n’impose pas explicitement à toutes les banques de réaliser périodiquement des campagnes de phishing. Mais son approche de la résilience invite à regarder bien au-delà de la simple disponibilité des serveurs.
Dans cet esprit, des exercices d’ingénierie sociale peuvent utilement compléter les tests techniques. Une simulation de phishing ciblé est un exemple classique, mais le scénario pourrait aller beaucoup plus loin : pourquoi ne pas simuler une fausse demande provenant d’une administration, d’une autorité judiciaire ou d’un partenaire de confiance ?
Et si l’on testait une fausse demande officielle ?
Imaginons qu’une équipe de sécurité autorisée transmette à une banque une demande administrative parfaitement crédible. Pas un phishing grossier rempli de fautes, mais un message correctement rédigé, utilisant le vocabulaire approprié, imitant les procédures habituelles et demandant une opération plausible.
L’objectif ne serait surtout pas de piéger un employé pour ensuite lui reprocher son erreur. Il serait de tester le système dans son ensemble.
L’identité de l’émetteur est-elle réellement vérifiée ? Existe-t-il une confirmation par un canal indépendant ? Une opération sensible nécessite-t-elle une seconde validation ? Un comportement inhabituel déclenche-t-il une alerte ? Combien de temps faut-il à l’organisation pour comprendre qu’elle fait face à une tentative de manipulation ?
Ce type d’exercice permettrait d’évaluer quelque chose qu’un simple scan de vulnérabilités ne révélera jamais : la capacité de l’organisation à résister à une demande crédible mais frauduleuse.
La résilience est aussi une question de gouvernance
L’un des changements culturels importants apportés par DORA consiste justement à ne plus considérer la cybersécurité comme une simple accumulation de technologies. La résilience devient également une question de gouvernance : qui peut décider, qui vérifie, comment une anomalie est remontée, que fait-on lorsqu’un contrôle échoue et comment l’organisation apprend-elle de ses incidents ?
Cette logique est essentielle, car la meilleure technologie de cybersécurité du monde ne compensera jamais totalement un processus qui accorde trop facilement sa confiance. À l’inverse, une organisation qui multiplie intelligemment les contrôles indépendants peut arrêter une attaque même lorsqu’un premier mécanisme de sécurité a échoué.
C’est précisément le principe de la défense en profondeur : ne jamais faire dépendre la sécurité d’un seul contrôle.
La cybersécurité moderne est une question de confiance
Le cas Revolut illustre finalement une évolution fondamentale de la cybersécurité. Pendant longtemps, nous avons principalement cherché à protéger les machines contre les attaquants. Aujourd’hui, ceux-ci cherchent de plus en plus à exploiter les relations de confiance entre les machines, les organisations et les humains.
Une banque peut avoir des serveurs parfaitement protégés et malgré tout transmettre une information à la mauvaise personne si son processus de validation est insuffisant. La sécurité ne peut donc plus seulement demander si l’infrastructure est protégée. Elle doit aussi déterminer pourquoi l’organisation fait confiance à une demande et quelles preuves permettent de justifier cette confiance.
C’est probablement l’une des meilleures manières de comprendre la résilience numérique moderne. Une organisation résiliente n’est pas une organisation dans laquelle aucun incident ne survient jamais. C’est une organisation qui part du principe qu’un jour quelque chose franchira ses défenses et qui s’organise pour que cette première erreur ne se transforme pas en catastrophe.