La vague DDoS contre les banques (2013) : 5 leçons sur les paiements

Ce qui s'est passé

À partir de début avril 2013, les banques ont été confrontées à des attaques DDoS : la surcharge délibérée de sites web et de services au moyen d'énormes volumes de trafic. Une banque a été la première cible et a été frappée à plusieurs reprises en peu de temps, de sorte que les clients ne pouvaient plus utiliser leur banque en ligne ni mobile.

Peu après, d'autres banques ont suivi et iDEAL est tombé lui aussi, si bien que payer en ligne dans les boutiques en ligne était temporairement impossible. Lors d'une attaque DDoS, il n'y a pas d'intrusion et aucune donnée n'est volée ; le but est la déstabilisation. L'identité des auteurs des attaques n'a jamais été établie. Les banques et le NCSC ont ensuite abordé le problème ensemble.

Leçon 1 : Soyez rapide et honnête, même sans connaître la cause

Les clients qui ne peuvent pas payer par carte ou effectuer un virement veulent savoir immédiatement ce qui se passe. Lors d'une attaque DDoS, on ne sait souvent pas encore, au début, combien de temps cela va durer. N'attendez pas pour autant : donnez rapidement un message honnête indiquant qu'il y a une perturbation, que vous y travaillez et ce que les clients peuvent ou non faire.

Soyez clair sur le fait qu'aucune donnée n'a été dérobée. En cas de problèmes de paiement, les gens pensent vite à une fraude ; vous devez activement dissiper cette inquiétude.

Leçon 2 : Communiquez sur un canal qui ne tombe pas avec les autres

Si votre site web et votre application sont la cible, vous ne pouvez pas compter sur eux pour votre communication.

• Utilisez une page de statut qui fonctionne sur une infrastructure indépendante, distincte des systèmes attaqués.
• Mobilisez les réseaux sociaux et la presse pour atteindre les clients qui ne consultent pas vos canaux.
• Veillez à ce que le service client dispose du même message à jour ; rien n'est plus nuisible que des informations contradictoires.
• Proposez une alternative lorsque c'est possible, par exemple par téléphone ou au guichet.

Leçon 3 : Les paiements forment une chaîne

Lorsque iDEAL est tombé, non seulement les clients des banques l'ont remarqué, mais aussi les boutiques en ligne et leurs clients. Les paiements forment une chaîne : un problème chez une banque ou dans l'infrastructure de paiement partagée touche de nombreuses parties à la fois.

Coordonnez-vous donc au sein du secteur et avec l'infrastructure de paiement. Une communication cohérente évite que chaque maillon ne raconte sa propre version et n'amplifie l'inquiétude.

Leçon 4 : Protégez la confiance, car c'est votre capital

Pour une banque, la confiance est le bien le plus précieux. Une panne de quelques heures est désagréable ; le sentiment que la banque ne maîtrise pas la situation ou ne communique pas honnêtement est bien plus dommageable.

Soyez donc transparent, montrez que vous prenez la situation au sérieux et respectez vos engagements. Un geste commercial en cas de dommage démontrable et un suivi clair contribuent davantage à la confiance qu'un rétablissement technique parfait que vous n'expliquez pas.

Leçon 5 : Connaissez vos obligations de notification (DORA, NIS2 et CER)

Pour le secteur financier, DORA (Digital Operational Resilience Act) s'applique depuis 2025 : un incident TIC grave se signale à De Nederlandsche Bank (DNB), avec une notification initiale, des mises à jour intermédiaires et un rapport final. Pour les entités financières, DORA est le régime spécifique applicable aux incidents TIC.

En outre, les banques sont des entités critiques au titre de la loi sur la résilience des entités critiques (CER) pour la résilience physique et tous risques ; la loi sur la cybersécurité (NIS2) constitue le cadre cyber plus large. Consignez pendant la crise quelles notifications ont été faites, quand et auprès de qui.

Comment CrisisRadar vous aide

CrisisRadar donne à votre cellule de crise une image partagée : la direction, l'informatique, les experts en paiements, le service client et la communication travaillent avec les mêmes informations. Vous consignez les faits, rédigez en quelques minutes un message client rassurant et une notification pour l'autorité de surveillance, et publiez le statut sur votre propre page de statut qui fonctionne indépendamment de vos systèmes centraux. Les minuteurs d'obligation de notification surveillent les délais DORA.

Vous souhaitez voir à quoi ressemble, étape par étape, une perturbation des paiements dans la plateforme ? Consultez alors la mise en situation correspondante.

Stappenplan

Veelgestelde vragen

Qu'est-ce qu'une attaque DDoS et des données sont-elles volées à cette occasion ?

Une attaque DDoS surcharge un site web ou un service avec un trafic énorme, de sorte qu'il devient inaccessible. Il n'y a pas d'intrusion et aucune donnée n'est volée ; le but est de perturber la disponibilité.

Comment communiquer lorsque votre propre site web et votre application sont hors service ?

Utilisez une page de statut sur une infrastructure indépendante, et mobilisez les réseaux sociaux, la presse et le service client avec le même message à jour. Vous atteignez ainsi les clients même lorsque les canaux attaqués ne fonctionnent pas.

Quelle obligation de notification s'applique aux banques lors d'un incident TIC ?

Pour le secteur financier, DORA s'applique : un incident TIC grave se signale à De Nederlandsche Bank (DNB), avec une notification initiale, des mises à jour intermédiaires et un rapport final. Les banques sont en outre des entités critiques au titre de la CER, avec NIS2 comme cadre cyber plus large.