Résumé

Pourquoi ce cas relève d'un dossier de risque et de responsabilité

ION Cleared Derivatives relève d'un dossier de risque et de responsabilité car il montre comment un seul fournisseur de technologie peut devenir un goulot d'étranglement pour la continuité dans un marché construit sur des obligations distribuées. Les membres compensateurs, les courtiers, les bourses, les utilisateurs finaux, les régulateurs et les plateformes de traitement des transactions ne se trouvent pas tous au sein d'une même entreprise.

Pourtant, une perturbation chez un seul fournisseur peut empêcher de nombreuses entreprises de traiter des transactions, de compléter des rapports, de valider des données et de se reconnecter en toute sécurité au reste du marché.

Le communiqué public d'ION àhttps://iongroup.com/press-release/markets/cleared-derivatives-cyber-event/indique qu'ION Cleared Derivatives, une division d'ION Markets, a subi un incident de cybersécurité à compter du 31 janvier 2023 qui a affecté certains de ses services. Il précise que l'incident a été confiné à un environnement spécifique, que tous les serveurs affectés ont été déconnectés et que la remédiation des services était en cours. Ce communiqué est court, mais c'est la source principale de l'entreprise pour l'existence, la date, le cadre de confinement, la décision de déconnexion et la posture de remédiation.

Le communiqué de la CFTC àhttps://www.cftc.gov/PressRoom/SpeechesTestimony/cftcstatement020223donne le point de vue du régulateur public deux jours plus tard. Il indique que les équipes de la CFTC ont travaillé avec d'autres régulateurs, les entités au marché et les parties touchées pour comprendre l'incident cyber et aider à garantir que les marchés de dérivés réglementés par la CFTC n'étaient pas compromis. Il précise que le problème a affecté la capacité de certains membres compensateurs à fournir des données précises et en temps opportun à la CFTC. Il indique également que le rapport hebdomadaire Commitments of Traders serait retardé jusqu'à ce que toutes les transactions puissent être déclarées et que les entreprises concernées devaient utiliser les meilleures estimations pour les rapports quotidiens des grands opérateurs et soumettre des rapports révisés une fois les systèmes opérationnels.

Voilà le cadre de responsabilité. L'incident n'avait pas besoin de détruire une chambre de compensation ou d'arrêter un marché entier pour avoir de l'importance. Il a affecté le pipeline de preuves. Les régulateurs avaient besoin de données précises et en temps opportun. Les utilisateurs du marché public attendaient le rapport Commitments of Traders. Les membres compensateurs avaient des obligations de déclaration légales et opérationnelles.

Si une panne d'un fournisseur empêche ces sorties, la question de responsabilité devient comment les entreprises, les fournisseurs, les régulateurs et les organismes sectoriels coordonnent un mode de déclaration dégradé sans transformer les estimations et le travail manuel en un angle mort permanent.

Le cas est également important car le bilan après action public est exceptionnellement explicite. Le rapport de la FIA de septembre 2023 indique que la panne a été déclenchée par une attaque de rançongiciel sur un seul fournisseur de services tiers utilisé par de nombreux courtiers compensateurs dans le monde. Il indique que l'attaque a démontré qu'une panne chez un seul fournisseur de services peut avoir des effets dommageables sur un large éventail d'entreprises et menacer le fonctionnement ordonné du marché.

Il indique également que certaines entreprises touchées ont eu besoin de jusqu'à deux semaines de travail intensif pour rassembler et traiter les enregistrements de transactions manquants et reconnecter les systèmes au reste du marché. C'est une déclaration claire sur la concentration et la charge de la reprise.

La chronologie publique confirmée est passée du confinement au retard de déclaration puis au rattrapage

La chronologie publique confirmée commence le 31 janvier 2023, date figurant dans le communiqué d'ION. L'entreprise a indiqué que certains services étaient affectés, que l'incident avait été confiné à un environnement spécifique, que les serveurs touchés avaient été déconnectés et que la remédiation était en cours. Le communiqué public n'identifie pas l'attaquant, le vecteur d'accès initial, l'exposition des données, la demande de rançon, le nombre de clients ni le calendrier de rétablissement système par système. L'article traite donc ces détails comme inconnus, sauf s'ils sont étayés par d'autres preuves publiques.

Le 1er février, la FIA a publié un commentaire public àhttps://www.fia.org/fia/articles/fia-comments-ion-group-cyber-incident. La FIA a déclaré qu'elle était au courant de problèmes de réseau causés par un incident cyber sur certains systèmes du groupe ION qui affectaient la négociation et la compensation des dérivés négociés en bourse par les clients d'ION sur les marchés mondiaux. La FIA a indiqué qu'elle travaillait avec les membres concernés, y compris les sociétés de compensation et les bourses, ainsi qu'avec les régulateurs du marché et d'autres, pour évaluer l'impact sur la négociation, le traitement et la compensation. Elle a également précisé qu'elle coordonnait la communication et le partage d'informations par le biais d'appels réguliers pour évaluer les entreprises touchées, comment les entreprises pourraient atténuer la perturbation et clarifier les obligations réglementaires et de déclaration affectées.

Le 2 février, la CFTC a publié sa première déclaration publique. Elle a indiqué que le problème affectait la capacité de certains membres compensateurs à fournir des données précises et en temps opportun. Elle a lié l'incident au retard des données exigées par les déclarants et au retard du rapport hebdomadaire Commitments of Traders. Elle a ordonné aux entreprises déclarantes concernées d'utiliser les meilleures estimations pour les rapports quotidiens des grands opérateurs et de soumettre des rapports révisés une fois les systèmes opérationnels.

Il s'agit d'une instruction notable en mode dégradé: continuer à se conformer autant que possible, utiliser des estimations si nécessaire, coordonner avec les équipes et réparer le dossier plus tard.

Le 10 février, la CFTC a publié un suivi àhttps://www.cftc.gov/PressRoom/PressReleases/8655-23. Elle a indiqué que l'impact de l'incident avait été atténué, mais que les entreprises responsables des déclarations continuaient de rencontrer des problèmes de soumission de données précises et en temps opportun. Elle a précisé que le rapport Commitments of Traders continuerait d'être retardé jusqu'à ce que toutes les transactions puissent être déclarées et qu'un rapport serait publié après réception et validation. Elle a de nouveau demandé aux entreprises concernées de continuer à déployer les meilleurs efforts pour accélérer les obligations de conformité et soumettre des rapports révisés une fois les systèmes opérationnels.

Le 16 février, la CFTC a annoncé àhttps://www.cftc.gov/PressRoom/PressReleases/8662-23que le rapport Commitments of Traders normalement prévu pour le 17 février serait reporté. Le personnel prévoyait de reprendre la publication dès le 24 février, en commençant par le rapport initialement prévu pour le 3 février, puis en publiant successivement les rapports manqués de manière accélérée, sous réserve d'une soumission de données précises et complètes. Le dossier public montre donc un retard de déclaration mesuré en semaines, et non en heures.

La chronologie est importante car chaque phase avait un devoir de responsabilité différent. Pendant le confinement, ION a dû isoler les serveurs affectés et remédier aux services. Pendant la réponse du marché, les membres compensateurs et les bourses ont dû continuer à négocier, compenser et traiter dans la mesure du possible et identifier les obligations réglementaires affectées. Pendant la réponse du régulateur, les équipes de la CFTC ont dû maintenir les attentes de conformité tout en autorisant les meilleures estimations et les rapports révisés.

Pendant le rattrapage, toutes les parties ont dû valider les données en attente avant que les rapports publics ne puissent reprendre.

L'incident a exposé la concentration des tiers dans les flux de travail post-négociation

La concentration des tiers est souvent abordée comme un problème lié au cloud, aux centres de données ou aux réseaux de paiement. L'incident ION montre que la concentration peut également résider dans des logiciels spécialisés post-négociation. Les marchés de dérivés négociés en bourse et compensés ne sont pas seulement des moteurs d'appariement et des chambres de compensation. Ils s'appuient également sur des outils de gestion des ordres, d'exécution, de négociation, d'allocation, de give-up, de capture de transactions, de compensation, de règlement, de rapprochement, de risque et de déclaration réglementaire.

Un fournisseur qui se trouve au cœur de ces flux de travail peut devenir critique même s'il n'est pas lui-même la contrepartie centrale.

Le rapport après action de la FIA est la source publique clé sur ce point. Il indique qu'une attaque de rançongiciel sur un seul fournisseur de services tiers utilisé par de nombreux courtiers compensateurs dans le monde a déclenché une perturbation significative dans le traitement des transactions exécutées sur plusieurs bourses. Il indique que l'attaque était notable par son ampleur et sa gravité, et qu'elle a démontré comment une panne chez un seul fournisseur de services peut avoir des effets dommageables sur un large éventail d'entreprises.

Il indique également que le groupe de travail a travaillé sur l'hypothèse que les futures attaques réussiront, en se concentrant sur la reprise plutôt que de supposer que la prévention fonctionnera toujours.

Ce cadrage est utile car il évite deux positions faibles. La première position faible est de supposer que si les marchés réglementés n'ont pas été compromis, l'incident n'était qu'un problème de fournisseur. Les déclarations de la CFTC montrent pourquoi cela est trop étroit: les déclarations et les données du marché public ont été retardées. La deuxième position faible est de supposer que la cybersécurité consiste uniquement à empêcher l'entrée. Le rapport de la FIA indique qu'il faut supposer que les futures attaques réussiront et que la reprise doit être améliorée.

Dans des marchés complexes, la qualité de la reprise est une question de contrôle du marché.

L'inférence étayée est que les entreprises qui dépendent d'un fournisseur partagé ont besoin d'un inventaire des dépendances dynamique, et non d'une liste statique de fournisseurs.

Un inventaire dynamique devrait indiquer quelles fonctions commerciales dépendent du fournisseur, quels rapports dépendent des données du fournisseur, quelles solutions de contournement manuelles existent, quels employés peuvent les utiliser, quels clients sont affectés, quelles bourses et chambres de compensation sont impliquées, quels régulateurs doivent être informés et quelles portes de reconnexion doivent être satisfaites avant que les flux normaux ne reprennent.

Des inconnues subsistent. Le dossier public n'identifie pas chaque client d'ION, chaque bourse affectée, chaque produit touché, chaque enregistrement de transaction manquant, ni chaque solution de contournement. Il ne montre pas non plus comment chaque entreprise individuelle avait contracté pour la résilience, l'accès aux données, les objectifs de délai de reprise, les droits d'audit, la notification cyber ou le soutien à la reconnexion. L'article ne prétend pas fournir ces détails. Il identifie les catégories de preuves qui comptent lorsqu'un fournisseur soutient de nombreuses entreprises.

Les retards de déclaration ont transformé une panne de fournisseur en un problème de preuve pour le marché public

Les déclarations de la CFTC sont importantes car elles montrent que l'incident est passé d'une reprise par un fournisseur privé à des données réglementaires publiques. Le rapport Commitments of Traders est largement utilisé par les entités au marché, les analystes et les chercheurs pour comprendre le positionnement. Un retard dans ce rapport n'est pas la même chose qu'un arrêt du marché, mais c'est une lacune dans les preuves publiques. Cela signifie que les régulateurs et les utilisateurs attendent des données complètes, précises et validées des entreprises touchées.

Le communiqué de la CFTC du 2 février indique que les entreprises déclarantes concernées ne disposaient pas à ce moment-là d'informations suffisantes pour préparer complètement les rapports quotidiens des grands opérateurs exigés en vertu de la partie 17 des règlements de la CFTC. Les exigences de déclaration des grands opérateurs de la partie 17 de la CFTC sont disponibles via le texte réglementaire àhttps://www.ecfr.gov/current/title-17/chapter-I/part-17. Le communiqué a demandé aux entreprises concernées d'utiliser les meilleures estimations et de soumettre des rapports révisés une fois les systèmes opérationnels. Ce langage préserve la responsabilité: les estimations sont autorisées comme pont temporaire, mais elles doivent être révisées lorsque le dossier devient disponible.

Les communiqués de la CFTC des 10 et 16 février montrent que le problème de déclaration a persisté même après l'atténuation de l'impact. Le communiqué du 16 février décrivait un plan de rattrapage séquentiel, commençant par le rapport manqué du 3 février, puis en publiant les rapports manqués de manière accélérée, sous réserve de données en attente précises et complètes. C'est un exemple pratique de gouvernance de la déclaration en mode dégradé. Le régulateur n'a pas simplement publié des données incomplètes parce que le marché voulait un rapport. Il a attendu la réception et la validation.

L'inférence étayée est que la continuité de la déclaration réglementaire doit être conçue avant un incident. Les entreprises doivent savoir quels rapports dépendent des systèmes du fournisseur, quelles données sources peuvent être exportées, comment les estimations sont créées, qui les approuve, comment les révisions sont suivies, comment les régulateurs sont notifiés et comment les enregistrements en attente sont validés. Le fournisseur doit savoir quelles exportations de données clients sont nécessaires pour soutenir une déclaration dégradée, et les clients ne doivent pas avoir à rétro-ingénier cela pendant une panne.

La question de responsabilité publique n'est pas de savoir si les équipes de la CFTC ont géré le retard de manière raisonnable; le dossier public suggère une approche structurée. La question est de savoir si les entités au marché et les fournisseurs disposaient d'une capacité de portabilité des données et de reconstruction des rapports suffisamment planifiée à l'avance. Le rapport de la FIA suggère que certaines entreprises ont eu besoin d'un travail intensif pour rassembler et traiter les enregistrements de transactions manquants.

Cela implique un écart entre les flux de travail automatisés normaux et les besoins urgents en matière de preuves.

La reconnexion est une décision de contrôle, pas seulement un redémarrage technique

Le communiqué d'ION indique que les serveurs affectés ont été déconnectés. Le rapport après action de la FIA a ensuite souligné la reconnexion comme une leçon majeure. La reconnexion dans un environnement de marché financier ne consiste pas simplement à rebrancher les systèmes. Elle nécessite l'assurance que l'environnement est propre, que les données sont précises, que les interfaces sont sûres, que les contreparties sont prêtes, que les régulateurs sont informés et que les clients comprennent quels enregistrements ont été traités normalement et lesquels nécessitent un rapprochement.

Le rapport de la FIA indique que la reconnexion nécessitait des attestations et que des exigences disparates ajoutaient des retards. Il considère la reconnexion comme l'une des étapes critiques du processus de reprise. Cela a de l'importance car chaque entreprise touchée doit décider quand il est sûr de se reconnecter à un fournisseur qui a subi un incident cyber, et chaque fournisseur doit fournir suffisamment de preuves pour satisfaire des clients ayant des politiques de risque, des régulateurs, des chambres de compensation, des bourses et des normes de contrôle interne différents.

L'inférence étayée est que les normes de reconnexion devraient être pré-négociées. Les entreprises ne devraient pas découvrir lors d'un incident de rançongiciel que chaque client exige un dossier de preuves différent, que chaque bourse a un seuil différent, que chaque régulateur attend une notification différente et que chaque comité des risques interne demande des attestations différentes.

Un dossier de reconnexion de base pourrait inclure le statut de confinement de l'incident, le périmètre de l'environnement affecté, la preuve d'éradication du logiciel malveillant, les vérifications d'intégrité, le statut de rapprochement des données, la revue des accès privilégiés, le statut des correctifs et de la configuration, la validation par un tiers et une déclaration claire du risque résiduel.

La reconnexion a également des implications en matière d'équité du marché. Si certaines entreprises se reconnectent plus tôt que d'autres parce que leurs exigences en matière de preuves sont moins lourdes, la capacité opérationnelle peut revenir de manière inégale. Cela ne prouve pas une injustice ou une mauvaise conduite. Cela signifie simplement que la reconnexion n'est pas seulement un jugement de cybersécurité. Elle affecte la négociation, la compensation, la déclaration, le service client, la charge de travail du personnel et potentiellement la position concurrentielle.

Un bon cadre de responsabilité devrait rendre ces critères de reconnexion suffisamment transparents pour être prévisibles avant le prochain incident.

L'article n'affirme pas que les décisions de reconnexion d'ION étaient déficientes. Les preuves publiques ne permettent pas cette conclusion. Il indique que l'événement a démontré que la reconnexion elle-même devrait être une norme de contrôle sectorielle, car un fournisseur qui sert de nombreux courtiers compensateurs ne peut pas restaurer la confiance une conversation bilatérale à la fois.

Les membres compensateurs ont supporté la charge opérationnelle de l'incident d'un autre

L'un des problèmes difficiles de responsabilité dans les incidents de fournisseurs est le transfert des coûts. Un fournisseur peut être la partie compromise, mais les clients supportent la charge opérationnelle. Dans l'incident ION, les membres compensateurs et d'autres entreprises ont dû évaluer les processus impactés, poursuivre l'activité du marché dans la mesure du possible, préparer les meilleures estimations, soumettre ensuite des rapports révisés, rassembler les enregistrements de transactions manquants, traiter les retards et satisfaire aux exigences de reconnexion internes et externes. Ce travail n'est pas gratuit.

Le commentaire de la FIA du 1er février indique que l'association a travaillé avec les membres concernés, les sociétés de compensation, les bourses, les régulateurs du marché et d'autres pour évaluer l'impact sur la négociation, le traitement et la compensation. Cela signifie que la charge a été répartie sur l'ensemble du secteur. Le rapport après action de la FIA indique que certaines entreprises touchées ont eu besoin de jusqu'à deux semaines de travail intensif pour rassembler et traiter les enregistrements de transactions manquants et reconnecter les systèmes. C'est une déclaration directe de l'effort de reprise côté client.

L'inférence étayée est que les contrats avec les tiers et les programmes de résilience devraient répartir les obligations de reprise avec plus de précision. Si un fournisseur soutient des fonctions post-négociation critiques, les contrats devraient aborder les droits d'exportation des données, le soutien d'urgence, le délai de notification des incidents, les objectifs de reprise, l'assurance indépendante, les preuves de reconnexion, la participation aux tests, la responsabilité, la coordination avec les clients et l'assistance aux régulateurs.

Si ces termes sont vagues, les clients peuvent découvrir lors d'un incident que leurs droits théoriques à la continuité ne se traduisent pas en données et en soutien utilisables.

Ce n'est pas seulement un problème de contrat bilatéral. Les remarques du Trésor àhttps://home.treasury.gov/news/press-releases/jy2029traitent de la résilience opérationnelle, de la transparence, de la concentration et de la nécessité pour les fournisseurs de services d'assumer davantage de responsabilité pour la sécurité des clients. Bien que ces remarques ne soient pas des conclusions spécifiques concernant ION, elles capturent un thème politique qui correspond au cas: lorsque les clients du secteur financier dépendent de fournisseurs de technologie concentrés, la charge de la résilience ne devrait pas incomber entièrement au client.

Les inconnues sont importantes. Le dossier public ne divulgue pas les contrats d'ION, ses engagements de niveau de service, les communications de reprise avec les clients, les crédits financiers, les coûts de l'incident, les réclamations d'assurance, la position contentieuse ou tout accord réglementaire avec ION. L'article n'infère pas ces faits. Il indique que le dossier public de l'incident rend ces catégories de responsabilité pertinentes.

L'attribution du rançongiciel doit être traitée avec prudence

Les reportages publics, dont Reuters àhttps://www.reuters.com/technology/hackers-say-ransom-paid-case-derivatives-data-firm-ion-company-declines-comment-2023-02-03/, ont discuté des affirmations des pirates et des assertions liées à la rançon. D'autres reportages ont décrit les affirmations de LockBit et le contexte potentiel de paiement. Ces reportages sont utiles pour comprendre le récit public et la préoccupation du marché, mais ils ne sont pas traités ici comme une preuve de paiement de rançon, d'exfiltration de données ou de cause racine technique.

La raison de la prudence est la même que dans les autres dossiers de responsabilité liés au rançongiciel. Les attaquants ont des incitations à exagérer. Une publication sur le dark web n'est pas un rapport médico-légal. Une revendication de rançon peut être impossible à vérifier à partir de sources publiques. Un rapport indiquant que l'entreprise a refusé de commenter n'est pas une confirmation. L'analyse publique devrait éviter de transformer le marketing des adversaires en fait établi.

Les faits publics confirmés sont suffisants. ION a confirmé un incident de cybersécurité affectant certains services, un confinement dans un environnement spécifique, la déconnexion des serveurs et une remédiation en cours. La CFTC a confirmé les retards de déclaration et les impacts sur la capacité de certains membres compensateurs à fournir des données précises et en temps opportun. La FIA a confirmé la coordination sectorielle et a ensuite décrit la panne comme déclenchée par une attaque de rançongiciel sur un seul fournisseur utilisé par de nombreux courtiers compensateurs.

Ces sources établissent le dossier de responsabilité sans recourir aux affirmations des acteurs de la menace.

Le guide ransomware de CISA àhttps://www.cisa.gov/stopransomware/ransomware-guide, le cadre de cybersécurité du NIST àhttps://www.nist.gov/cyberframeworket le NIST SP 800-61 Rev. 3 àhttps://csrc.nist.gov/pubs/sp/800/61/r3/finalfournissent un contexte général pour la réponse aux incidents, la reprise, la communication et l'amélioration. Ils ne sont pas une preuve privée concernant ION. Ils aident à définir ce qu'une réponse mature devrait documenter.

L'article maintient donc une limite ferme. Il peut dire que l'événement a été publiquement discuté comme du rançongiciel car le rapport après action de la FIA utilise ce cadrage. Il peut dire que Reuters a rapporté des affirmations de pirates. Il ne peut pas dire que la rançon a été payée, que des données particulières ont été volées, qu'une vulnérabilité spécifique a été exploitée ou qu'un acteur particulier est définitivement responsable, à moins qu'une source publique primaire ne l'établisse.

La réponse de la CFTC montre comment la conformité en mode dégradé peut fonctionner

Les déclarations publiques de la CFTC sont utiles car elles ne prétendent pas que les déclarations se sont poursuivies normalement. Elles reconnaissent que certaines entreprises manquaient d'informations suffisantes pour préparer complètement les rapports quotidiens des grands opérateurs. Elles permettent les meilleures estimations, exigent une coordination avec les équipes et demandent des rapports révisés après la mise en service des systèmes. Elles retardent le rapport Commitments of Traders jusqu'à ce que les transactions puissent être déclarées et les données validées. C'est un modèle de conformité en mode dégradé pragmatique.

Cela importe car les marchés réglementés ne peuvent pas attendre une reprise parfaite avant la reprise de chaque obligation. En même temps, ils ne peuvent pas traiter les estimations comme définitives. La réponse de la CFTC a créé un pont: meilleurs efforts maintenant, révisions plus tard, publication après validation, rattrapage séquentiel. Ce modèle est applicable au-delà de la déclaration des dérivés. Dans tout incident cyber sur un marché financier, les régulateurs ont besoin d'un moyen de recevoir des données provisoires sans perdre le dossier probant final.

L'inférence étayée est que les entreprises devraient avoir des manuels « estimer et réviser » pour les rapports réglementés. Le manuel devrait définir quand les estimations sont autorisées, comment elles sont étiquetées en interne, quelles sources de données les soutiennent, qui les approuve, quel niveau de confiance leur est attribué, comment les rapports révisés sont générés, comment les différences sont expliquées et comment le dossier final est conservé. Sans ces contrôles, les estimations peuvent devenir des suppositions incontrôlées.

Avec des contrôles, les estimations peuvent tenir les régulateurs informés tout en préservant l'obligation de corriger.

Le dossier public ne montre pas comment chaque entreprise déclarante concernée a mis en œuvre l'instruction de la CFTC. Il ne montre pas si les estimations étaient matériellement inexactes, combien de rapports révisés ont été déposés, combien d'entreprises ont été touchées, ou si une action coercitive a suivi pour un déclarant spécifique. L'article ne revendique pas ces résultats. Il identifie les déclarations de la CFTC comme preuve d'un mode dégradé géré par le régulateur.

La leçon plus large en matière de responsabilité est que les régulateurs et les organismes sectoriels devraient prédéfinir des catégories de déclaration dégradée pour les incidents de tiers. Si un fournisseur critique est en panne, les entreprises devraient savoir quels champs peuvent être estimés, quels champs ne le peuvent pas, quels rapports doivent être déposés en retard, quelles révisions sont obligatoires et quels rapports publics doivent attendre la validation. L'incident ION a montré que ces questions ne sont pas théoriques.

La coordination sectorielle était nécessaire car aucune entreprise ne détenait l'ensemble du problème

Le rôle de la FIA est important car aucun membre compensateur unique ne pouvait résoudre seul une panne de fournisseur touchant plusieurs entreprises. La FIA a coordonné la communication et le partage d'informations, a organisé des appels avec les parties concernées, a évalué les entreprises touchées, a exploré les mesures d'atténuation et a cherché des éclaircissements sur les obligations réglementaires et de déclaration. Plus tard, la FIA a créé un groupe de travail sur le risque cyber et a publié des conclusions et recommandations.

C'est un modèle de responsabilité au niveau sectoriel: lorsque les dépendances sont partagées, la coordination doit être partagée.

La déclaration du commissaire de la CFTC du 8 mars àhttps://www.cftc.gov/PressRoom/SpeechesTestimony/johnsonstatement030823est utile car elle a placé l'incident ION dans une discussion plus large sur la résilience opérationnelle, la réponse aux incidents majeurs, la protection des actifs et des informations des clients, les fournisseurs de services tiers et la création du groupe de travail de la FIA. Elle a également relié la discussion à la stratégie nationale de cybersécurité, disponible àhttps://www.whitehouse.gov/wp-content/uploads/2023/03/National-Cybersecurity-Strategy-2023.pdf, qui mettait l'accent sur le rééquilibrage des responsabilités et le réalignement des incitations.

L'inférence étayée est que la concentration des fournisseurs nécessite des exercices coordonnés avant les incidents. Un bon exercice inclurait le fournisseur, les clients majeurs, les chambres de compensation, les bourses, les régulateurs, les organismes sectoriels et peut-être les destinataires critiques de données. Il testerait la notification d'incident, la priorisation des clients, l'exportation de données, le traitement manuel, la déclaration réglementaire, les critères de reconnexion, la communication publique et les preuves après action.

Si le premier appel de coordination complète a lieu après l'incident, le secteur est déjà en retard.

La coordination sectorielle doit également préserver les limites de responsabilité. Un organisme sectoriel peut partager des informations et coordonner des appels, mais il ne peut pas remplacer l'obligation d'un fournisseur de restaurer et de prouver ses systèmes. Un régulateur peut autoriser les meilleures estimations, mais il ne peut pas rendre complets les dossiers d'un membre compensateur. Un client peut créer des solutions de contournement, mais il ne peut pas voir à l'intérieur de l'environnement médico-légal du fournisseur. Chaque acteur a un domaine de contrôle différent.

Un bon bilan après action devrait rendre ces domaines explicites.

Le cas ION est précieux car les sources publiques montrent les couches ensemble: communiqué de l'entreprise, déclarations du régulateur, coordination sectorielle, rapport après action et discussion politique. De nombreux incidents cyber ne laissent qu'un avis d'entreprise succinct. Ici, le public peut voir comment un incident chez un fournisseur tiers a traversé les opérations de marché et les preuves réglementaires.

L'automatisation de la sécurité doit inclure la reconstruction des enregistrements de transactions et des rapports

Le manifeste inclut l'automatisation de la sécurité, et l'incident ION montre pourquoi l'automatisation ne peut pas s'arrêter à la détection des points de terminaison. Pour un fournisseur de flux de travail de dérivés compensés, l'automatisation devrait soutenir le confinement, la reconstruction propre, les vérifications d'intégrité des données, la communication avec les clients, l'exportation des enregistrements de transactions, la reconstruction des rapports, le séquencement des retards et les preuves de reconnexion. Si la reprise dépend entièrement de la découverte manuelle des enregistrements manquants, le marché paie pour l'écart.

Le rapport de la FIA indique que certaines entreprises ont eu besoin d'un travail intensif pour rassembler et traiter les enregistrements de transactions manquants. Cette phrase est opérationnellement importante. Elle suggère que les systèmes normaux n'ont pas fourni un package de reprise propre et immédiatement utilisable pour chaque entreprise touchée. Cela peut être compréhensible lors d'un incident de rançongiciel, mais c'est exactement ce que l'ingénierie de la résilience devrait améliorer. L'identification des enregistrements manquants devrait être rapide, structurée et vérifiable.

L'inférence étayée est que les fournisseurs et les clients devraient maintenir des vues de données indépendamment récupérables pour les obligations réglementaires et de compensation critiques. Cela ne signifie pas dupliquer chaque système de production dans chaque environnement client. Cela signifie identifier les données minimales nécessaires pour reconstruire les transactions, les positions, les rapports, les allocations, les give-ups, les soumissions de compensation et les rapprochements si l'environnement du fournisseur est indisponible.

Cela signifie également tester si ces exportations peuvent être utilisées par les équipes opérationnelles réelles sous pression de temps.

Les directives de réponse aux incidents du NIST et les directives ransomware de CISA sont utiles ici car elles mettent l'accent sur la préparation, la communication, le confinement, l'éradication, la reprise et les leçons apprises. Mais les fournisseurs de technologie des marchés financiers ont besoin de couches spécifiques au domaine. Une sauvegarde générique ne suffit pas si elle ne peut pas soutenir les rapports réglementaires. Un ticket d'incident générique ne suffit pas si les clients ont besoin de la traçabilité des données au niveau des champs.

Un statut de restauration générique ne suffit pas si les membres compensateurs ont besoin de savoir quelles transactions manquent et quels rapports nécessitent une révision.

Des inconnues subsistent autour de l'architecture d'ION et des contrôles clients. Le dossier public ne divulgue pas la conception de la sauvegarde, la conception de l'exportation des données, la couverture de la journalisation, la segmentation, l'accès privilégié, les règles de détection, la méthode de reconstruction ou la validation externe. L'article n'infère pas ces détails. Il indique que l'incident démontre le type d'automatisation et de preuves qui devrait exister pour les fournisseurs post-négociation critiques.

À quoi ressemblerait une réparation responsable pour un fournisseur de marché critique

Les sources publiques ne publient pas la feuille de route interne de remédiation d'ION, et cet article ne prétend pas la connaître. Néanmoins, le dossier de la CFTC et de la FIA identifie ce qu'une réparation responsable devrait pouvoir prouver. La première exigence est une carte de services utile en cas d'urgence. Elle devrait montrer quels flux de travail clients dépendent de chaque service, quels rapports dépendent de chaque ensemble de données, quelles bourses et chambres de compensation sont connectées, quels clients ont besoin d'une notification immédiate et quelles exportations de données soutiennent les opérations dégradées.

Un catalogue de services générique ne suffit pas lorsque les clients ont besoin de savoir quels enregistrements de transactions sont manquants.

La deuxième exigence est des données de reprise portables. Les clients critiques ne devraient pas avoir à attendre une restauration complète du fournisseur avant de pouvoir identifier leurs propres lacunes de déclaration. Un fournisseur peut protéger la sécurité et la confidentialité tout en concevant des exportations d'urgence, des rapports d'intégrité et des dictionnaires de données qui permettent aux clients de reconstruire les transactions, les positions, les allocations, les give-ups, les soumissions de compensation et les rapports réglementaires.

Ces exportations devraient être testées avec des utilisateurs réels, car un fichier que seuls les ingénieurs peuvent interpréter ne soutiendra pas une échéance de conformité en direct.

La troisième exigence est une norme de reconnexion. La discussion sur la reconnexion dans le rapport de la FIA montre pourquoi cela est important. Les clients doivent savoir quelles preuves seront fournies avant la restauration des interfaces: statut du confinement, périmètre de l'environnement affecté, preuve d'éradication du logiciel malveillant, méthode de reconstruction, vérifications d'intégrité, revue des accès privilégiés, statut des correctifs, statut de la surveillance, validation par un tiers et problèmes résiduels connus. Si ces éléments sont négociés pendant un incident, la reprise ralentit et la confiance devient inégale.

La quatrième exigence est un manuel partagé de déclaration en mode dégradé. Les instructions de la CFTC sur les meilleures estimations et les rapports révisés étaient pragmatiques, mais les entreprises ne devraient pas avoir à inventer les mécanismes lors d'un incident de rançongiciel. Le manuel devrait définir les étiquettes d'estimation, les propriétaires d'approbation, les déclencheurs de révision, le suivi des écarts, les communications avec les régulateurs et la conservation finale des preuves.

Il devrait également identifier les champs de données trop sensibles ou trop incertains pour être estimés sans coordination explicite avec le régulateur.

La cinquième exigence est l'exercice sectoriel. Un incident chez un fournisseur multi-client ne peut pas être entièrement testé au sein d'une seule entreprise. Les fournisseurs, les membres compensateurs, les bourses, les chambres de compensation, les régulateurs et les associations sectorielles devraient répéter la notification, l'exportation de données, le traitement manuel, le retard de déclaration, la communication publique et la reconnexion. L'objectif n'est pas de publier tous les contrôles sensibles.

L'objectif est de rendre la prochaine réponse moins improvisée et de réduire la quantité de preuves critiques pour le marché piégées dans un environnement endommagé.

Faits confirmés, inférences étayées et inconnues

Les faits publics confirmés incluent qu'ION Cleared Derivatives, une division d'ION Markets, a subi un incident de cybersécurité à compter du 31 janvier 2023 qui a affecté certains services; qu'ION a indiqué que l'incident avait été confiné à un environnement spécifique; que les serveurs affectés ont été déconnectés; et que la remédiation était en cours.

Les faits publics confirmés incluent également que la FIA a déclaré que l'événement avait affecté la négociation et la compensation des dérivés négociés en bourse par les clients d'ION sur les marchés mondiaux et que la FIA a coordonné la communication avec les membres concernés, les sociétés de compensation, les bourses, les régulateurs et autres.

Les faits publics confirmés incluent que les équipes de la CFTC ont déclaré que l'incident avait affecté la capacité de certains membres compensateurs à fournir des données précises et en temps opportun, a retardé les données exigées par les déclarants, a retardé le rapport Commitments of Traders, a exigé que les entreprises concernées utilisent les meilleures estimations pour les rapports quotidiens des grands opérateurs et a exigé des rapports révisés une fois les systèmes opérationnels.

Les faits publics confirmés incluent la déclaration du 10 février selon laquelle les problèmes de déclaration persistaient même après l'atténuation de l'impact, et la déclaration du 16 février décrivant un rapport CoT reporté et un rattrapage séquentiel prévu.

Les faits publics confirmés incluent les constats après action de la FIA selon lesquels une attaque de rançongiciel sur un seul fournisseur tiers utilisé par de nombreux courtiers compensateurs dans le monde a déclenché une perturbation significative dans le traitement des transactions exécutées sur plusieurs bourses, que l'attaque a montré comment une panne chez un seul fournisseur de services peut endommager un large éventail d'entreprises et menacer le fonctionnement ordonné, et que certaines entreprises touchées ont eu besoin de jusqu'à deux semaines de travail intensif pour rassembler et traiter les enregistrements de transactions

manquants et reconnecter les systèmes.

L'inférence étayée inclut l'avis que la concentration des fournisseurs tiers, la continuité des déclarations, la conformité en mode dégradé, la portabilité des données, les preuves de reconnexion, le contrôle des solutions de contournement manuelles, la charge de reprise côté client et la coordination sectorielle sont toutes des surfaces de responsabilité dans cet incident. L'inférence étayée inclut également l'avis que les fournisseurs critiques devraient fournir des données de reprise testées et une assurance de reconnexion suffisamment solide pour permettre aux clients réglementés de remplir leurs obligations sous stress.

Les inconnues restent importantes. Le dossier public ne divulgue pas le vecteur d'accès initial, l'attribution définitive de l'attaquant à partir d'une source primaire, la demande de rançon, le paiement de rançon, le vol de données, le nombre exact de clients affectés, tous les produits et bourses touchés, les lacunes de déclaration entreprise par entreprise, les pertes spécifiques aux clients, le calendrier complet de restauration, les conditions contractuelles, les crédits de service, les résultats d'assurance, les conclusions médico-légales privées ou la correspondance réglementaire finale avec ION ou les entreprises touchées.

L'article ne comble pas ces lacunes par des accusations.

Le test de responsabilité durable

Le test de responsabilité durable est de savoir si un marché peut maintenir sa chaîne de preuves intacte lorsqu'un fournisseur post-négociation critique est perturbé. Le communiqué public d'ION montre le cadre de confinement du fournisseur. Les déclarations de la CFTC montrent la dégradation et le rattrapage des déclarations gérés par le régulateur. Les documents de la FIA montrent la coordination sectorielle, le risque de concentration, la charge de reconnexion et la nécessité de supposer que les futures attaques réussiront.

Ensemble, ces sources montrent un cas de responsabilité dans le domaine de la technologie financière plutôt qu'une simple panne de fournisseur.

Pour les membres compensateurs, la leçon est que la dépendance au fournisseur doit être associée à des données de reprise indépendantes, des procédures manuelles testées et des estimations et révisions de déclaration pré-planifiées. Pour les fournisseurs, la leçon est que le confinement n'est que le premier devoir; les clients ont besoin d'accès aux enregistrements de transactions, de séquencement de la reprise, de preuves de reconnexion et de communications claires.

Pour les régulateurs, la leçon est que la déclaration en mode dégradé devrait être conçue avant un incident de fournisseur et devrait inclure des mécanismes de validation et de révision. Pour les organismes sectoriels, la leçon est que les dépendances partagées nécessitent des exercices partagés et des canaux de réponse partagés.

ION Cleared Derivatives a fait du rançongiciel un test de responsabilité pour la continuité de la compensation car il a révélé comment une panne d'un fournisseur tiers peut se propager du traitement des transactions aux données réglementaires et aux preuves du marché public. Le fournisseur contrôlait l'environnement affecté et la remédiation. Les clients contrôlaient leurs propres solutions de contournement et leurs obligations de déclaration. Les régulateurs contrôlaient les attentes de déclaration et le calendrier de publication.

La responsabilité exigeait que les trois travaillent ensemble, avec suffisamment de preuves pour prouver non seulement que les systèmes étaient revenus, mais que les transactions, les rapports, les reconnexions et les données en attente étaient complets et fiables.