Quand une banque se fait braquer, je regarde le coffre, pas tout le système

Quand une banque se fait braquer, je regarde le coffre, les journaux d'accès et l'identifiant qui a été compromis. Je ne me demande pas si le système bancaire devrait exister. C'est la distinction qui manque dans la plupart de ce que j'ai lu sur le piratage de Binance cette semaine, et il vaut mieux l'expliciter avant que le discours du « crypto n'est pas sûr » ne devienne une évidence collective.

Binance a perdu environ 6,3 milliards de dollars le 29 octobre. TRM Labs a retracé environ 6,36 milliards de dollars déplacés sur dix blockchains en une vingtaine de minutes, le plus grand vol de cryptomonnaies jamais enregistré. Premières leçons, du point de vue d'un responsable de la sécurité plutôt que d'un trader crypto : il s'agit d'une défaillance des identifiants et du contrôle d'accès, et elle mérite exactement l'attention que mérite toute violation chez un dépositaire d'actifs. Ce qu'elle ne mérite pas, c'est d'être traitée comme la preuve qu'une classe d'actifs entière est structurellement défaillante.

Ma thèse : jugez Binance comme vous jugeriez n'importe quel dépositaire victime d'une violation, sur le contrôle qui a échoué et sur la question de savoir s'il est corrigé, et non sur la technologie de registre sous-jacente.

Ce qui a réellement échoué

Le propre récit de Binance pointe vers l'ordinateur portable compromis d'un ingénieur DevOps, qui a permis d'atteindre un conteneur de service, lequel a ensuite soumis des transactions de retrait non autorisées. Kok Tin Gan, PDG de la société de cybersécurité NyxLab, a décrit la situation comme une seule signature ayant donné à l'attaquant un jeton d'accès complet et sans expiration vers un portefeuille actif (hot wallet). Binance a ensuite indiqué que son enquête avait révélé d'autres points de compromission au-delà de l'ordinateur portable. TRM Labs et Chainalysis attribuent indépendamment l'attaque, avec un haut niveau de confiance, à TraderTraitor, l'unité nord-coréenne que le FBI avait déjà désignée pour le piratage de Bybit, à hauteur de 1,5 milliard de dollars, en février 2025.

Rien de tout cela n'est une propriété des blockchains. Un identifiant permanent sans expiration, atteint via un seul point compromis, est le même type de défaillance qui a vidé des coffres bien avant que quiconque n'ait entendu parler d'un portefeuille actif.

La version la plus solide de « mais la crypto, c'est différent »

Je veux donner à cet argument tout son poids avant d'y répondre, parce que sa version faible est facile à balayer, mais pas sa version forte. Les plateformes crypto détiennent les actifs de leurs clients comme le ferait une banque, mais sans assurance des dépôts, sans prêteur en dernier ressort, et avec un règlement définitif dès qu'il est validé sur un bloc. Un virement bancaire peut parfois être annulé. Une transaction blockchain ne le peut pas. Quand le portefeuille actif de Binance a signé ces retraits, l'argent avait disparu le temps de préparer un café, sans banque centrale pour couvrir la perte et sans dispositif d'assurance des dépôts pour les clients. Binance s'est engagée à couvrir la perte sur ses fonds propres, ce qui est une promesse, pas une structure de garantie.

C'est une différence structurelle réelle, et je ne vais pas prétendre le contraire.

Pourquoi cela ne constitue toujours pas un réquisitoire contre la classe d'actifs

Voici ce que le discours « la crypto n'est pas sûre » oublie : l'attaquant n'est pas nouveau dans ce domaine, et la méthode non plus. Les sociétés de renseignement blockchain attribuent à la fois ce piratage et celui de Bybit en 2025 à la même unité nord-coréenne que le gouvernement américain tenait déjà pour responsable du vol de la Bangladesh Bank en 2016, où des messages SWIFT frauduleux avaient fait transiter 81 millions de dollars depuis un compte correspondant à la Réserve fédérale de New York. Ce vol avait été intercepté en plein vol, grâce à une imprimante défaillante et à un employé d'une banque intermédiaire qui avait repéré une faute dans le nom d'un bénéficiaire, et non grâce à une protection structurelle intégrée au système SWIFT ou à la relation bancaire sur laquelle il reposait. Le même adversaire a désormais exécuté le même scénario, compromission d'identifiants, accès privilégié, déplacement des fonds avant que quiconque ne s'en aperçoive, contre un compte bancaire correspondant en 2016 et un portefeuille actif en 2026. La classe d'actifs a changé. La méthode non.

Ce qui ne correspond pas non plus au récit du « sans foi ni loi et irréversible » : Tether et Circle ont gelé à eux deux environ 2,38 milliards de dollars de stablecoins volés en quelques heures après le piratage, sur environ 3 milliards de dollars que Binance affirme avoir gelés au total. C'est un disjoncteur centralisé fonctionnant à l'intérieur d'un système censé en être dépourvu. La finalité du règlement en crypto est réelle, mais l'écosystème qui l'entoure a mis en place des solutions de contournement qu'un virement passant par une chaîne de banques correspondantes n'a souvent pas.

Ce qu'un responsable de la sécurité retient réellement de cela

Je ne dis pas que les contrôles de Binance étaient adéquats. Un identifiant qui n'expire jamais et un compte de service disposant d'un accès en écriture permanent à un portefeuille actif sont des constats que je signalerais dans n'importe quel audit, crypto ou non. Mais « le signaler dans l'audit » est en soi la version la plus faible de la leçon, car un constat issu d'une revue trimestrielle vous l'aurait appris des mois après qu'un attaquant ait déjà trouvé la faille. Le véritable problème de contrôle d'accès n'est pas que l'identifiant existait. C'est que rien dans l'architecture ne plafonnait ce qu'un seul identifiant compromis pouvait faire, et que rien dans la surveillance n'a détecté le résultat en temps réel.

Trois questions que je poserais à tout dépositaire soumis à ce type d'audit, plateforme crypto ou non :

• Un identifiant unique dispose-t-il d'une autorité permanente et non supervisée sur l'action sensible ? Un portefeuille actif pouvant être entièrement vidé par une seule signature est, par conception, un point de défaillance unique. Une signature multipartite, une approbation à plusieurs, ou un second système devant attester de manière indépendante avant l'exécution d'un retrait, auraient transformé un vol de vingt minutes en une transaction bloquée.
• Les jetons privilégiés expirent-ils, et « n'expire jamais » est-il une réponse acceptable ? Un jeton à accès complet et de longue durée est un passif dès le moment où il est émis, pas seulement au moment où il est volé. Des identifiants de courte durée, délivrés juste à temps et réémis pour chaque action sensible plutôt que détenus indéfiniment, réduisent le périmètre de dégâts d'exactement ce type de compromission d'ordinateur portable.
• Le comportement des retraits est-il lui-même surveillé, indépendamment de la validité apparente de l'identifiant utilisé ? Six milliards de dollars déplacés sur dix blockchains en vingt minutes constituent une anomalie en volume et en vitesse à eux seuls, quelle que soit la signature qui l'a autorisée. Un système capable de signaler et de suspendre ce type de schéma en temps réel n'a pas besoin de savoir à l'avance que l'identifiant a été volé.

Rien de tout cela n'est un contrôle spécifique aux blockchains. Un programme de sécurité mature pose les trois mêmes questions aux opérations de trésorerie d'une banque, à une console d'administration cloud, ou à un fournisseur SaaS détenant des clés API permanentes au sein de votre environnement : qui est responsable de ce contrôle, est-il surveillé en continu plutôt que vérifié lors du prochain cycle d'audit, et une anomalie atteint-elle quelqu'un capable d'agir en quelques minutes plutôt qu'à la prochaine réunion du comité de gouvernance. Un programme qui ne produit que des constats documente le risque, il ne le gère pas.

Détecter que 6 milliards de dollars ont été déplacés en vingt minutes est un signal rétrospectif. Il est utile pour l'analyse post-incident, pas pour arrêter le vol. La question la plus difficile est de savoir si le risque aurait pu être évalué avant même que cet identifiant ne soit utilisé : un jeton sans expiration, à accès complet et sans double approbation, est un passif prévisible dès le jour de son émission, pas seulement le jour de son vol. C'est le changement de logique sur lequel insAIght est construit pour les systèmes d'IA et les accès fournisseurs : évaluer en continu le risque d'un système ou d'un accès au regard des référentiels qui s'y appliquent, de sorte qu'un identifiant non révisé et sur-privilégié apparaisse comme un constat ouvert avant qu'un attaquant ne le trouve, et non dans l'analyse post-incident qui suit. L'autre moitié de ce changement est l'application du contrôle directement dans le flux de travail plutôt que sur un tableau de bord que quelqu'un doit penser à consulter : un contrôle capable d'exiger un second approbateur, de limiter dans le temps un accès, ou de bloquer une action dès qu'un seuil de risque est franchi, plutôt qu'un contrôle qui se contente de déclencher une alerte qu'un humain devra trier une fois l'argent déjà parti.

La leçon porte sur l'endroit où diriger l'attention : sur le contrôle précis qui a échoué et sur la question de savoir si la correction tient, et non sur un verdict global visant toute une catégorie d'infrastructure financière parce que la gestion des accès privilégiés d'un seul opérateur présentait une faille.

Jugez le coffre. Réparez la serrure. Ne condamnez pas la banque parce qu'une fenêtre est restée ouverte.

Pour aller plus loin

• insAIght : le suivi continu des fournisseurs, systèmes et accès présents dans votre registre de risques, plutôt qu'une revue ponctuelle.
• Your Chatbot Is Not a Feature. It Is a Legal Exposure. : le même raisonnement, juger le contrôle précis, appliqué au risque lié aux fournisseurs d'IA.
• ExplAIn : rendre explicable auprès des auditeurs et des régulateurs le comportement des systèmes d'IA et automatisés sur lesquels repose votre entreprise, le même réflexe appliqué un niveau au-dessus du contrôle d'accès.

Besoin d'un second avis sur la façon dont vos propres contrôles d'accès résisteraient à ce type d'examen ? Réservez une démo.