Après l'incident Liquid Network à 320 millions de dollars : une ligne de défense est tombée, que peuvent encore protéger les plateformes d'actifs numériques ?

Les récents incidents de sécurité ramènent une fois de plus le secteur des actifs numériques à une question familière : qu'est-ce qui rend une plateforme réellement « sûre » ?

Début septembre, un incident de sécurité majeur s'est produit sur le sidechain Bitcoin Liquid Network. Les attaquants ont exploité une faille de validation du logiciel Elements, entraînant le transfert d'environ 4 000 BTC, soit environ 320 millions de dollars au moment des faits. Il est important de noter que les clés PAK et Federation elles-mêmes n'ont pas été compromises. Cela soulève une question encore plus pertinente : lorsque les clés elles-mêmes ne sont pas compromises, comment un transfert d'actifs qui n'aurait jamais dû avoir lieu a-t-il pu traverser le système ?

Des risques similaires apparaissent également dans d'autres maillons. En août, des attaquants ont exploité une faille de sécurité critique de Cosmos EVM pour attaquer plusieurs réseaux, six réseaux ayant été effectivement compromis, alors que la faille avait déjà été signalée via un programme de bug bounty. En juillet, Triple-A a été victime d'une attaque d'ingénierie sociale : les attaquants ont obtenu les identifiants du personnel concerné et ont ensuite pénétré l'environnement opérationnel, entraînant le transfert d'une partie des actifs propres de l'entreprise. Cependant, les fonds des clients étant conservés séparément dans des comptes fiduciaires, isolés de l'environnement opérationnel compromis, ils n'ont pas été affectés.

Les causes de ces trois incidents sont différentes, mais elles pointent toutes vers une question plus concrète : les incidents de sécurité sont peut-être difficiles à éviter totalement, mais lorsqu'un maillon du code, du personnel ou des autorisations est compromis, jusqu'où le risque peut-il s'étendre ?

Ce qu'il faut vraiment prévenir, ce n'est pas seulement « être piraté », mais jusqu'où le risque peut aller

La question plus importante que « avons-nous été attaqués ? » est : après la défaillance de la première ligne de défense, jusqu'où l'attaquant peut-il aller ? La compromission d'un compte suffit-elle à effectuer des opérations critiques sur les actifs ? Une autorisation compromise permet-elle d'accéder à des systèmes plus centraux ? Lorsque l'environnement en ligne rencontre des problèmes, quelle part des actifs essentiels est réellement exposée sur la trajectoire d'attaque ?

C'est aussi une leçon importante des incidents récents : l'impact final d'une attaque ne dépend pas seulement de ce que l'attaquant a réussi à compromettre, mais aussi du nombre de lignes de défense restantes dans le système après la compromission.

Si la compromission d'un compte permet d'accéder directement aux autorisations critiques, ou si un problème dans l'environnement en ligne peut affecter directement une grande partie des actifs essentiels, alors n'importe quel maillon faible peut être rapidement amplifié. À l'inverse, s'il existe une isolation multicouche entre les autorisations, les opérations critiques, la surveillance des risques et le stockage des actifs, une seule compromission ne se transformera pas nécessairement en une perte totale.

En d'autres termes, mesurer la capacité de sécurité d'une plateforme ne consiste pas seulement à vérifier si « la première porte peut être tenue », mais aussi : après la chute de la première porte, combien de portes restent derrière.

En suivant la chaîne d'attaque, où se trouve la « prochaine porte » de BIT ?

Récemment, la plateforme mondiale de services financiers numériques BIT (anciennement Matrixport) a publié le Livre blanc sur la confiance BIT V2.0 (https://www.bit.com/whitepaper). Si l'on relit ce livre blanc à travers la question « que se passe-t-il après la défaillance de la première ligne de défense ? », un point mérite l'attention : le système de sécurité de BIT ne repose pas sur une seule ligne de défense, mais met en place une protection multicouche entre l'identité, les autorisations, les opérations et les actifs.

Par exemple, l'obtention des identifiants d'un compte ne signifie pas que l'attaquant dispose de toutes les autorisations nécessaires pour effectuer des opérations critiques sur les actifs. Le livre blanc révèle que BIT applique le principe du moindre privilège pour limiter les systèmes et les opérations auxquels les employés peuvent accéder. Les opérations critiques telles que les transferts d'actifs, la sécurité des comptes, les changements d'autorisations, la génération et l'approbation des ordres de transaction nécessitent la participation d'au moins deux personnes autorisées. Prenons l'exemple de Cactus Custody, cette approche en couches s'étend également aux scénarios de conservation d'actifs numériques de niveau institutionnel.

Passer l'authentification ne signifie pas non plus que les opérations suivantes bénéficient d'un « feu vert » permanent. BIT surveille en continu les comportements anormaux tels que les connexions inhabituelles, les appareils inhabituels et les retraits inhabituels. Côté actifs, la majorité des actifs numériques sont stockés dans des portefeuilles froids, ce qui réduit encore l'exposition des actifs essentiels en cas de problème dans l'environnement en ligne.

En considérant ces mécanismes ensemble, la logique de sécurité de BIT devient plus intuitive : une identité compromise ne signifie pas l'obtention de toutes les autorisations ; l'obtention d'une autorisation ne signifie pas pouvoir effectuer indépendamment des opérations critiques ; passer l'authentification ne signifie pas que les actions ultérieures échappent à l'évaluation des risques ; un problème dans l'environnement en ligne ne signifie pas que tous les actifs essentiels sont exposés simultanément.

Ce qui détermine réellement jusqu'où une attaque peut aller, ce sont précisément ces « ne signifie pas ». Cela ne veut pas dire que toute attaque peut être totalement évitée, mais cela signifie que même si une ligne de défense présente un problème, il reste possible d'identifier les anomalies, de limiter les autorisations ou d'isoler les risques.

L'écart en matière de sécurité se cache souvent après la chute de la première porte.

Une fois le risque détecté, qui a le pouvoir d'appuyer réellement sur le « bouton d'arrêt » ?

Mais multiplier les lignes de défense techniques ne suffit pas. Dans l'incident Cosmos EVM, un détail mérite l'attention : la faille avait déjà été signalée via un programme de bug bounty, mais selon les informations disponibles à l'époque, elle avait été initialement jugée comme ne pouvant pas entraîner de pertes de fonds sur les configurations de réseau de production connues.

Cela révèle un autre problème souvent négligé : détecter un risque ne signifie pas que le risque a été correctement évalué et pleinement traité.

Une fois une faille soumise, qui juge de sa gravité ? Si l'équipe de sécurité estime le risque inacceptable, a-t-elle le pouvoir d'empêcher la mise en ligne du produit ? Lorsque les délais métier entrent en conflit avec le jugement de sécurité, qui a le dernier mot ?

Le Livre blanc sur la confiance BIT V2.0 révèle que lorsque des solutions produit, des exigences, des architectures ou des changements de mise en ligne présentent des risques de sécurité majeurs, ou ne respectent pas les exigences de base en matière de sécurité et de conformité, l'équipe de sécurité dispose d'un « droit de veto » et peut suspendre les activités concernées, exiger des corrections et une nouvelle validation avant de poursuivre.

Ce qui rend ce mécanisme vraiment intéressant, ce n'est pas seulement l'ajout d'une étape d'approbation, mais le fait qu'il répond à une question très concrète : lorsque le risque apparaît réellement, quelqu'un a-t-il le pouvoir de dire « non » ? Pour un système de sécurité, la capacité à détecter les problèmes est certes importante, mais permettre au jugement de sécurité d'influencer réellement les décisions métier détermine également si une ligne de défense reste simplement inscrite dans les procédures ou si elle peut réellement fonctionner.

À mesure que les activités se complexifient, la « sécurité » ne se limite plus aux actifs dans le portefeuille

Lorsque les plateformes de services financiers numériques commencent à connecter simultanément différents types d'actifs et d'infrastructures financières — actifs numériques, actions américaines, RWA —, les problèmes de sécurité ne se limitent plus aux portefeuilles et aux comptes. Qui traite les actifs, par quelles institutions ils passent, où ils sont compensés et détenus, tout cela devient également un élément important de l'évaluation des risques par les utilisateurs.

C'est aussi là que le Livre blanc sur la confiance BIT V2.0 approfondit le système de sécurité et de confiance. Au-delà des mesures de gestion des risques et de sécurité, le livre blanc révèle les dispositifs de réglementation, d'audit et de vérification indépendante correspondant aux différentes entités commerciales, permettant aux observateurs extérieurs de mieux comprendre : qui est responsable de quoi, quels mécanismes peuvent être vérifiés, et jusqu'où ces mécanismes s'étendent.

Prenons l'exemple de l'activité actions américaines de BIT : ses activités de valeurs mobilières sont opérées par Matrix Gelephu Pte. Ltd. et réglementées par la GFSO, et sont connectées à des institutions financières américaines agréées ainsi qu'aux infrastructures de compensation et de conservation correspondantes.

Pour l'utilisateur moyen, ces arrangements financiers complexes se résument en réalité à quelques questions simples : qui traite mes actifs ? Par quelles étapes passent-ils ? De quoi chaque institution est-elle responsable ? L'identité et le statut réglementaire de ces institutions peuvent-ils être vérifiés ?

C'est là que la « vérifiabilité » prend tout son sens : la sécurité ne peut pas reposer uniquement sur ce que la plateforme affirme, mais aussi sur ce que les utilisateurs et les observateurs extérieurs peuvent vérifier.

En revenant sur Liquid Network, Cosmos EVM et Triple-A, les points d'entrée des trois incidents sont totalement différents, mais ils rappellent tous au marché : aucune ligne de défense ne doit être supposée infaillible pour toujours. Ce qui creuse réellement l'écart en matière de sécurité n'est peut-être pas une technologie de sécurité particulière, mais la capacité à établir suffisamment d'isolation et de contrepoids entre l'identité, les autorisations, les opérations, les actifs et les décisions organisationnelles, afin qu'une compromission locale ait plus de mal à se transformer en perte totale.

De ce point de vue, ce qui mérite l'attention dans le Livre blanc sur la confiance BIT V2.0, ce n'est pas seulement le nombre de mesures de sécurité énumérées, mais la capacité de ces mesures à former un système de défense complet : si un maillon présente un problème, il y a une couche suivante ; si la couche suivante présente un problème, il reste possible de continuer à identifier, bloquer et isoler les risques.

Pour les plateformes d'actifs numériques, « n'avoir jamais subi d'attaque » est peut-être difficile à promettre de façon permanente. Mais une autre chose peut être construite en continu : la véritable sécurité consiste à faire en sorte que, même si une ligne de défense tombe, une seule compromission ne se transforme pas facilement en perte totale. Et lorsque ces lignes de défense non seulement existent, mais peuvent aussi être vérifiées en continu par l'extérieur, la « confiance » cesse d'être une simple déclaration de la plateforme.