Equinix a transformé la divulgation d’un rançongiciel en un test de responsabilité pour la continuité de la colocation

Résumé

• La divulgation du rançongiciel de septembre 2020 d’Equinix est devenue un test de responsabilité pour la continuité de la colocation car l’entreprise a déclaré que le rançongiciel avait affecté certains systèmes internes tandis que les centres de données, les services gérés, les opérations clients et l’équipement client restaient opérationnels.
• Qui avait le contrôle pratique sur la segmentation des systèmes internes, la continuité des services IBX, les preuves d’impact client, la divulgation de la rançon, la communication d’incident et la preuve que les opérations de colocation restaient séparées de l’environnement compromis?
• Le problème de responsabilité est qu’un opérateur de centre de données doit prouver la séparation entre les systèmes internes compromis et les surfaces de continuité client, car les clients ne peuvent pas inspecter indépendamment cette frontière lors d’un incident.
• Les clients de colocation, les utilisateurs d’interconnexion, les charges de travail adjacentes au cloud, les entreprises, les investisseurs et les équipes de risque opérationnel avaient besoin de preuves que l’événement de rançongiciel n’était pas devenu une défaillance de continuité des installations.
• Cet article considère la déclaration d’incident de sécurité d’Equinix àhttps://blog.equinix.com/blog/2020/09/09/equinix-statement-on-security-incident/comme la divulgation principale de l’entreprise, le formulaire 10‑K 2020 d’Equinix àhttps://www.sec.gov/Archives/edgar/data/1101239/000162828021002563/eqix-20201231.htmcomme contexte sur la plateforme IBX, et les documents de DCD, BleepingComputer, CRN, SecurityWeek, The Register, FBI, DOJ, CISA, NIST et SEC comme des reportages ou un contexte de contrôle plutôt que comme des preuves d’artefacts judiciaires privés absents du dossier.

Pourquoi ce cas fait partie d’un dossier de risque et de responsabilité

Equinix fait partie d’un dossier de risque et de responsabilité car l’incident a séparé deux déclarations qui sont souvent confondues après un événement de rançongiciel. La première déclaration était qu’un opérateur avait détecté un rançongiciel sur ses systèmes internes. La seconde était que ses centres de données et ses offres de services restaient pleinement opérationnels. Pour une entreprise de vente au détail, cette distinction pourrait décrire la différence entre les systèmes back‑office et les systèmes front‑office. Pour un fournisseur mondial de colocation, la distinction est plus lourde.

Elle demande si les systèmes utilisés par l’entreprise pour gérer, soutenir, communiquer, surveiller, facturer et coordonner les installations sont significativement séparés des surfaces dont dépendent les clients pour l’alimentation, l’espace, le refroidissement, l’accès physique, l’interconnexion, l’infrastructure gérée et le support opérationnel.

La divulgation principale est inhabituellement directe. Dans sa déclaration d’incident de sécurité de septembre 2020 àhttps://blog.equinix.com/blog/2020/09/09/equinix-statement-on-security-incident/, Equinix a déclaré enquêter sur un rançongiciel sur certains systèmes internes, avoir pris des mesures, avoir notifié les forces de l’ordre, et croire que ses centres de données et offres de services restaient opérationnels. La déclaration indiquait également que la plupart des clients exploitent leur propre équipement dans les centres de données d’Equinix et que l’incident n’avait pas affecté les opérations de ces clients ni les données sur leur équipement. centres de données Dynamics a rapporté la même affirmation de continuité àhttps://www.datacenterdynamics.com/en/news/equinixs-internal-systems-hit-ransomware-data-centers-remain-fully-operational/et a cadré l’événement autour de la séparation entre les systèmes internes et les installations. The Register a rendu explicite la même question d’isolement àhttps://www.theregister.com/on-prem/2020/09/10/equinix-warns-its-infected-with-ransomware-promises-it-can-carry-on-regardless/1055338en traitant la séparation de l’équipement client comme l’affirmation centrale d’assurance.

C’est pourquoi ce n’est pas seulement une histoire de logiciel malveillant. C’est une histoire de dépendance à la colocation. Les clients n’achètent pas seulement de l’espace au sol. Ils achètent une affirmation de continuité: que l’opérateur peut maintenir un environnement physique et réseau stable pendant que chaque client exécute sa propre pile. Le formulaire 10‑K 2020 d’Equinix àhttps://www.sec.gov/Archives/edgar/data/1101239/000162828021002563/eqix-20201231.htmdécrivait une plateforme IBX de plus de 220 centres de données de colocation neutres et les effets de réseau créés par les clients se connectant aux réseaux, clouds, fournisseurs SaaS, partenaires et entre eux. Ce contexte de plateforme importe. Plus la plateforme d’interconnexion est grande, plus une divulgation de rançongiciel devient un test pour savoir si une compromission d’entreprise peut être empêchée de se propager dans une surface de continuité partagée.

Le dossier public contenait également des affirmations en dehors de la déclaration d’Equinix. BleepingComputer a rapporté àhttps://www.bleepingcomputer.com/news/security/equinix-data-center-giant-hit-by-netwalker-ransomware-45m-ransom/que le rançongiciel était NetWalker et que la demande était de 4,5 millions de dollars. CRN a répété le cadrage NetWalker àhttps://www.crn.com/news/security/equinix-ransomware-attack-hits-company-s-internal-systemstout en notant qu’Equinix n’a pas confirmé ces détails à CRN. SecurityWeek a rapporté l’incident àhttps://www.securityweek.com/data-center-provider-equinix-hit-ransomware/et a distingué la divulgation confirmée d’Equinix des reportages sur la famille de rançongiciels. La frontière des preuves est importante. Cet article ne traite pas chaque détail tiers comme un aveu de l’entreprise. Il traite la déclaration de l’entreprise comme preuve principale de l’affirmation de continuité, et les reportages comme preuve de la façon dont les clients, investisseurs et équipes de sécurité ont dû interpréter l’événement alors que les détails étaient incomplets.

La question responsable est pratique: qui avait le contrôle pratique sur la segmentation des systèmes internes, la continuité des services IBX, les preuves d’impact client, la divulgation de la rançon, la communication d’incident et la preuve que les opérations de colocation restaient séparées de l’environnement compromis? Cette question ne peut être répondue en disant seulement que les clients possèdent leur propre équipement.

L’équipement appartenant au client réduit une catégorie d’exposition, mais n’élimine pas le contrôle de l’opérateur sur la continuité des installations, les flux de travail d’accès, les mains à distance, les communications d’incident, les portails de services, le provisionnement d’interconnexion, l’escalade du support, les services gérés et les preuves de plateforme.

La colocation transforme la segmentation d’entreprise en continuité client

La leçon centrale est que la segmentation dans une entreprise de colocation n’est pas seulement une conception de sécurité interne. C’est une promesse de continuité client. Si le rançongiciel est limité aux systèmes d’entreprise, l’opérateur doit encore prouver que la limitation est réelle. Si les opérations des installations, la prestation de services et le support client continuent, l’opérateur doit montrer qu’ils continuent parce que la frontière a fonctionné, pas parce que le public n’a pas encore vu de défaillance.

Dans une entreprise d’infrastructure fondée sur la confiance, la différence entre « non affecté » et « pas encore visiblement affecté » est un problème de preuve.

La plateforme d’Equinix rend ce problème de preuve plus important. Son dépôt annuel 2020 décrivait les services de colocation, d’interconnexion et d’infrastructure gérée comme faisant partie d’une plateforme d’infrastructure numérique mondiale. La page actuelle de confiance et sécurité d’Equinix àhttps://www.equinix.com/about/trust-securityprésente l’assurance sécurité comme une fonction de confiance orientée client. Cela ne prouve pas ce qui s’est passé pendant l’incident de 2020. Cela montre pourquoi les clients pouvaient raisonnablement s’attendre à ce que l’entreprise dispose d’un dossier de preuves mature pour les contrôles de sécurité, les contrôles des installations et les frontières des données clients. Lorsqu’un fournisseur se commercialise comme une couche d’infrastructure pour les écosystèmes numériques, la réponse au rançongiciel ne peut pas être seulement une affaire de service informatique interne.

L’affirmation de séparation a plusieurs couches. La première est la segmentation logique entre les systèmes internes et les systèmes technologiques opérationnels ou les systèmes des installations. La seconde est la segmentation administrative entre les identifiants professionnels et les identifiants privilégiés des installations ou de la gestion des services. La troisième est la segmentation réseau entre les environnements de bureau, les portails de services, les réseaux de services gérés et les réseaux de colocation clients.

La quatrième est la segmentation des processus entre la réponse aux incidents interne et les opérations de support client. La cinquième est la segmentation des preuves: les journaux, les inventaires et les enregistrements d’état doivent montrer quels actifs ont été affectés et lesquels ne l’ont pas été.

Les clients ne peuvent pas inspecter cette frontière complète pendant l’incident. Un client cloud ou un client de colocation peut surveiller ses propres services, tester l’accessibilité et demander des mises à jour aux équipes de compte. Il ne peut pas, par lui-même, inspecter l’inventaire des actifs internes, les contrôles de domaine, l’état des sauvegardes, les outils de gestion des installations ou les journaux des opérations de sécurité d’Equinix. Cette asymétrie crée la charge de responsabilité.

Le fournisseur qui a le contrôle doit fournir suffisamment d’assurance publique et privée pour permettre aux clients de prendre des décisions sur la continuité, l’acceptation du risque, la planification d’urgence et leurs propres obligations de divulgation.

centres de données Dynamics a ensuite publié un entretien avec les dirigeants de la sécurité d’Equinix àhttps://www.datacenterdynamics.com/en/analysis/michael-montoya-equinixs-ciso-a-year-on-from-its-2020-ransomware-incident/dans lequel l’incident a été discuté comme un test pour savoir si un mouvement latéral vers les installations IBX était possible. L’article n’est pas un rapport judiciaire complet, et cette analyse ne le traite pas comme tel. Il est précieux car il cadre l’incident autour d’un investissement antérieur dans l’isolement et la réponse. La question de preuve responsable demeure: quels artefacts ont montré que la frontière des installations a tenu, quels systèmes ont été examinés, ce qui a été dit aux clients et comment les conclusions ont été vérifiées?

Une assurance de continuité n’est aussi forte que sa chaîne de preuves

La déclaration de l’entreprise a donné aux clients la phrase dont ils avaient le plus besoin: les opérations n’étaient pas affectées. Mais une responsabilité mature exige plus qu’une phrase. Une assurance de continuité a besoin d’une chaîne de preuves qui peut être expliquée aux clients sans exposer des détails sensibles du système. Pour un opérateur de centre de données, cette chaîne devrait commencer par le périmètre des actifs. Quels systèmes internes ont été affectés?

Quels domaines d’identité, serveurs de fichiers, outils de collaboration, services desk, systèmes de facturation, outils de gestion à distance ou portails administratifs étaient dans le périmètre? Quels systèmes opérationnels, d’installations et orientés clients étaient hors périmètre? Quelles preuves soutenaient chaque frontière?

Le deuxième maillon est la preuve de l’état des services. Un fournisseur devrait être capable de montrer si l’alimentation, le refroidissement, l’accès physique, les cages clients, les services gérés, les services d’interconnexion, les tickets de support, les mains à distance et les portails de services ont continué dans les limites normales. « Aucun impact » ne devrait pas seulement signifier qu’aucune plainte confirmée n’a été reçue.

Cela devrait signifier que le fournisseur a comparé la télémétrie, les journaux opérationnels, le volume de tickets, les ponts d’incident, les enregistrements des installations et les escalades clients par rapport à la continuité de service attendue. L’affirmation de continuité devrait être mesurable.

Le troisième maillon est la preuve de la frontière des données. La déclaration d’Equinix distinguait l’équipement exploité par le client des données dans les systèmes d’Equinix. Cette distinction est utile, mais elle laisse des questions. Des informations clients dans les systèmes internes ont-elles été mises en risque? Les dossiers de support, coordonnées, contrats, tickets de service, listes d’accès aux cages, données des portails, schémas techniques ou informations de services gérés ont-ils été examinés?

Les clients ont-ils été notifiés privément lorsque leurs dossiers se trouvaient dans des systèmes affectés, même si leur propre équipement n’était pas affecté? Les reportages publics ne fournissent pas toutes ces réponses. C’est pourquoi les frontières des preuves importent.

Le quatrième maillon est la preuve de communication. Le billet de blog public était opportun et mis à jour pendant au moins deux jours suivants. MSSP Alert a rapporté la déclaration àhttps://www.msspalert.com/news/ransomware-attacks-equinix-data-centers-and-managed-services-not-impactedet a souligné ce qui n’a pas été divulgué: le type exact de rançongiciel et quels systèmes internes ont été touchés. Le problème de responsabilité n’est pas que chaque détail technique doit être public immédiatement. C’est que la communication d’incident devrait séparer les faits confirmés, les limites de l’enquête, les preuves d’impact client, les contraintes des forces de l’ordre et les attentes de prochaine mise à jour. Les clients ont besoin d’assez de certitude pour agir sans forcer le fournisseur à publier un manuel pour les attaquants.

Le cinquième maillon est la preuve de récupération. La récupération après rançongiciel n’est pas complète lorsque la déclaration publique est publiée. Elle nécessite le confinement, l’éradication, la restauration, la rotation des identifiants, la validation des sauvegardes, l’examen judiciaire, l’examen juridique, le cadrage client et les leçons apprises. Le guide #StopRansomware de CISA àhttps://www.cisa.gov/stopransomware/ransomware-guideest un contexte utile car il traite le rançongiciel à la fois comme un travail de prévention et de réponse, incluant les sauvegardes, la restauration, l’identité et les pratiques de gestion d’incident. Le guide de traitement des incidents informatiques du NIST àhttps://csrc.nist.gov/pubs/sp/800/61/r2/finaldonne un vocabulaire neutre pour la préparation, la détection, l’analyse, le confinement, l’éradication et la récupération. Ces sources ne prouvent pas les actions privées d’Equinix. Elles définissent ce qu’une chaîne de preuves crédible devrait normalement couvrir.

L’investissement dans les centres de données relève le niveau de la preuve d’incident

L’investissement dans les centres de données est souvent discuté à travers la capacité, l’alimentation, les baux, les acquisitions et la demande d’interconnexion. Les dépôts d’Equinix et les documents pour investisseurs montrent pourquoi l’entreprise est centrale dans cette conversation d’investissement. Mais les incidents de sécurité révèlent un autre côté de l’investissement dans l’infrastructure: la valeur d’une plateforme dépend de la conviction des clients que les problèmes internes du fournisseur ne deviennent pas leurs urgences opérationnelles.

Plus les clients consolident l’hébergement physique, l’interconnexion et l’infrastructure gérée chez un seul fournisseur, plus il devient important de prouver que la propre compromission du fournisseur a un rayon d’explosion limité.

Ce n’est pas seulement un problème d’entreprise. De nombreuses petites et moyennes entreprises comptent directement sur de grands fournisseurs ou par l’intermédiaire de partenaires de services gérés, de plateformes SaaS, de fournisseurs de connectivité et de revendeurs. Une PME peut ne pas avoir sa propre équipe de sécurité capable d’interpréter les déclarations de rançongiciel d’un opérateur mondial de centres de données. Elle peut compter sur des fournisseurs de services qui eux-mêmes dépendent des installations ou de l’interconnexion d’Equinix.

Lorsqu’un opérateur de colocation déclare que les installations ne sont pas affectées, l’assurance voyage à travers les chaînes d’approvisionnement. Le client final peut même ne pas savoir quelle installation ou quel tissu d’interconnexion soutient le service qu’il utilise.

C’est pourquoi l’argument « le client possède l’équipement » est nécessaire mais insuffisant. Si un client possède son serveur dans une cage d’Equinix, ses données sur ce serveur peuvent ne pas être touchées par un rançongiciel sur les systèmes internes d’Equinix. Mais la continuité du client dépend toujours des contrôles d’accès, des tickets, de l’alimentation, du refroidissement, des mains à distance, du provisionnement des interconnexions, des notifications d’incident, de la sécurité physique et des processus de support du fournisseur.

Un incident de rançongiciel dans les systèmes internes pourrait toujours s’il interfère avec le support ou s’il expose les coordonnées clients et les métadonnées d’infrastructure. Le dossier de responsabilité doit couvrir les surfaces de dépendance qui subsistent même lorsque l’équipement client est séparé.

Le contexte de 2020 importe également. Les opérateurs de rançongiciels combinaient de plus en plus le chiffrement avec le vol de données et l’extorsion. L’alerte NetWalker du FBI àhttps://www.ic3.gov/CSA/2020/200929-2.pdfdécrivait l’activité de NetWalker contre des organisations gouvernementales, éducatives, privées et de santé. Le ministère de la Justice a ensuite annoncé une action de perturbation de NetWalker àhttps://www.justice.gov/archives/opa/pr/department-justice-launches-global-action-against-netwalker-ransomwareet a décrit l’écosystème criminel plus large. Ces sources ne sont pas des conclusions judiciaires d’Equinix. Elles expliquent pourquoi une divulgation de rançongiciel en 2020 a créé des questions immédiates sur le vol de données, l’extorsion, les demandes de paiement et le périmètre de divulgation.

Le rapport de BleepingComputer àhttps://www.bleepingcomputer.com/news/security/equinix-data-center-giant-hit-by-netwalker-ransomware-45m-ransom/a rendu ces questions concrètes en rapportant une demande de rançon présumée et une pression de vol de données présumée. Equinix n’a pas mis ces détails dans sa déclaration. Une analyse responsable doit donc tenir les deux faits à la fois: les reportages publics ont créé un environnement interprétatif à haut risque pour les clients, tandis que la déclaration confirmée de l’entreprise se limitait aux systèmes internes, à la notification aux forces de l’ordre, à la poursuite des opérations et à l’enquête en cours. La responsabilité n’est pas servie en exagérant des affirmations non confirmées. Elle est servie en demandant quelles preuves résoudraient les questions pour les personnes qui devaient prendre des décisions.

Le moment de la divulgation fait partie de la gestion de la continuité

La divulgation par blog d’Equinix était courte, mais son moment importait. Un incident de rançongiciel chez un opérateur de centres de données peut créer un marché de rumeurs plus rapidement qu’une enquête formelle ne peut se clore. Les clients peuvent voir des articles de presse, des affirmations d’acteurs de la menace, des anomalies de service, des retards de support ou des préoccupations internes avant de recevoir des réponses formelles. La tâche de divulgation du fournisseur est d’éviter deux échecs à la fois. Il ne doit pas cacher des informations matérielles aux clients qui en ont besoin.

Il ne doit pas non plus publier des suppositions qui s’effondreront plus tard.

La page de la règle de divulgation de cybersécurité de la SEC de 2023 àhttps://www.sec.gov/rules-regulations/2023/07/s7-09-22et le communiqué de presse àhttps://www.sec.gov/intelligence team/press-releases/2023-139sont postérieurs à l’incident d’Equinix, ils ne sont donc pas une référence légale pour ce qu’Equinix devait faire en septembre 2020. Ils sont utiles car ils montrent la direction de la politique de divulgation des sociétés cotées: les incidents de cybersécurité, les processus de gestion des risques, les rôles de direction et la surveillance du conseil sont pertinents pour les investisseurs lorsqu’ils sont matériels. Pour une entreprise d’infrastructure cotée, le problème de responsabilité sous-jacent existait avant la règle. Les investisseurs et les clients devaient savoir si l’incident affectait les opérations, le risque matériel ou les coûts futurs.

La divulgation la plus forte rendrait quatre distinctions claires. Premièrement, qu’est-ce qui est confirmé? Deuxièmement, qu’est-ce qui est encore sous enquête? Troisièmement, quelle action client est requise maintenant? Quatrièmement, quelle mise à jour future ou processus de notification privé suivra? La déclaration d’Equinix a répondu à des parties des première et troisième questions en disant que les opérations et l’équipement client n’étaient pas affectés et en ne donnant pas d’instructions aux clients pour prendre des mesures d’urgence.

Elle a laissé les deuxième et quatrième questions partiellement ouvertes, ce qui est courant dans les premières déclarations d’incident. Le test responsable est de savoir si les communications privées aux clients et le cadrage ultérieur ont comblé ces lacunes.

La divulgation est aussi un problème de charge de support. Pendant un incident de rançongiciel, chaque équipe de compte client peut faire face aux mêmes questions. Si le fournisseur n’a pas préparé de preuves cohérentes, les clients reçoivent des réponses incohérentes. Dans une entreprise de colocation, cette incohérence peut créer un risque de continuité car les clients peuvent indépendamment initier des migrations, geler les changements, suspendre les demandes d’accès ou escalader vers leurs propres régulateurs.

Un processus de communication d’incident mature donne aux équipes de compte un script vérifié, un chemin d’escalade et un ensemble de preuves qui distingue l’équipement client, les services gérés, les données internes et les installations opérationnelles.

L’article de The Register àhttps://www.theregister.com/on-prem/2020/09/10/equinix-warns-its-infected-with-ransomware-promises-it-can-carry-on-regardless/1055338a capturé pourquoi l’affirmation semblait plausible aux observateurs externes: isoler l’équipement des différents clients est inhérent au modèle de colocation. Mais plausible n’est pas la même chose que prouvé. Dans un incident sérieux, le fournisseur devrait être capable de montrer que l’architecture a fonctionné dans ce cas spécifique. Cela peut inclure des briefings non publics aux clients, une assurance indépendante, des rapports de réponse aux incidents ou des notifications spécifiques au contrat.

La séparation opérationnelle doit survivre à la compromission d’identité

Les incidents de rançongiciel commencent souvent comme des incidents d’identité. Les attaquants obtiennent des identifiants, escaladent les privilèges, se déplacent latéralement, désactivent les défenses, préparent les données et chiffrent les systèmes. Même lorsque le dossier source public ne spécifie pas le chemin d’intrusion initial, l’analyse de responsabilité devrait demander si le contrôle d’identité était assez fort pour le rôle de dépendance du fournisseur.

Un opérateur de centre de données ne devrait pas dépendre d’un seul annuaire interne, d’un seul chemin d’accès à distance ou d’un seul plan d’identifiants administratifs pour à la fois les systèmes internes et la continuité opérationnelle.

NIST SP 800-53 Rev. 5 àhttps://csrc.nist.gov/publications/detail/sp/800-53/rev-5/finalest un vocabulaire utile ici car il organise les contrôles autour du contrôle d’accès, de l’identification et de l’authentification, de la gestion de la configuration, de l’audit, de la planification de la continuité, de la réponse aux incidents, de l’intégrité du système et du risque de la chaîne d’approvisionnement. Le cadre de cybersécurité du NIST àhttps://www.nist.gov/cyberframeworkdonne une structure plus large pour identifier, protéger, détecter, répondre et récupérer. Ces documents ne disent pas ce qu’Equinix a fait en interne. Ils aident à définir les preuves que les clients attendraient raisonnablement d’un fournisseur dont les installations soutiennent la continuité d’autres entreprises.

La séparation des identités importe pour les mains à distance et les services gérés. Si le personnel d’un fournisseur doit soutenir l’équipement client ou l’infrastructure gérée pendant un incident, le fournisseur doit savoir que les comptes de support, les hôtes de rebond, les approbations d’accès, les flux de travail de tickets et les systèmes d’accès aux installations ne sont pas contrôlés par l’environnement compromis. Sinon, la réponse peut créer un risque de second ordre: l’entreprise essaie de continuer à soutenir les clients tout en n’étant pas sûre des identités internes fiables.

Il en va de même pour les sauvegardes et la restauration. Un incident de rançongiciel sur les systèmes internes teste si les sauvegardes sont isolées du plan d’identité compromis. Il teste également si les systèmes restaurés peuvent être fiables avant d’être reconnectés aux flux de travail opérationnels. Le guide CISA sur le rançongiciel àhttps://www.cisa.gov/stopransomware/ransomware-guidemet l’accent sur les pratiques de sauvegarde et de restauration car la récupération après rançongiciel échoue lorsque les sauvegardes sont incomplètes, connectées au même environnement compromis ou non testées. Dans un cadre de centre de données, l’assurance de sauvegarde ne concerne pas seulement les fichiers internes. Elle concerne les systèmes métiers qui permettent à l’opérateur de communiquer, authentifier, facturer, dispatcher et soutenir.

La posture fortement responsable est compartimentée. Les systèmes de collaboration internes peuvent échouer sans affecter les opérations des installations. La surveillance des installations peut continuer sans dépendre d’annuaires internes compromis. Les portails de services peuvent être isolés ou placés en mode maintenance contrôlée sans perdre les preuves clients. Les équipes de support peuvent opérer à partir de canaux de continuité durcis. Les avis aux clients peuvent être distribués par des voies de contact vérifiées. Chaque couche devrait avoir des journaux montrant qu’elle s’est comportée comme conçu pendant l’incident.

Le dossier public montre une affirmation de frontière, pas un rapport judiciaire complet

La preuve la plus forte disponible au public est l’affirmation de frontière. Equinix a déclaré que l’incident impliquait certains systèmes internes, que les forces de l’ordre avaient été notifiées, que les centres de données et les offres de services restaient pleinement opérationnels, et que les opérations clients et les données sur l’équipement client n’étaient pas affectées. DCD, SecurityWeek, The Register, CRN et MSSP Alert ont rapporté cette affirmation. BleepingComputer et CRN ont discuté de l’attribution présumée à NetWalker et de la demande de rançon, CRN notant qu’Equinix a refusé de commenter ces détails.

L’entretien DCD de 2021 a ensuite connecté l’événement à l’investissement dans l’isolement et à la réponse au rançongiciel.

Ce dossier est suffisant pour soutenir une analyse de responsabilité de risque, mais il n’est pas suffisant pour reconstruire l’incident complet. Le public ne dispose pas d’une liste complète des actifs, d’une chronologie des logiciels malveillants, d’un inventaire des systèmes affectés, d’un périmètre de compromission d’identité, d’une détermination d’exfiltration de données, d’une population de clients notifiés, d’une chronologie des forces de l’ordre, d’un dossier de décision de paiement, de preuves de récupération de sauvegarde ou d’un rapport judiciaire indépendant.

Cet article ne prétend donc pas qu’aucune information client interne n’a été touchée à moins que le dossier public ne le soutienne. Il dit que la déclaration disponible de l’entreprise affirmait qu’il n’y avait pas d’impact sur les opérations ou l’équipement client, puis demande quelle preuve un fournisseur devrait détenir derrière cette affirmation.

La distinction n’est pas pédante. Elle protège les deux côtés de la responsabilité. Les clients ne devraient pas traiter une courte déclaration publique comme un rapport technique complet. Les fournisseurs ne devraient pas être forcés de révéler des détails défensifs sensibles en public pendant qu’une enquête est active. Le juste milieu responsable est une assurance structurée. Le fournisseur peut divulguer assez pour définir la frontière, donner des conseils d’action aux clients, s’engager à une notification privée si nécessaire, et plus tard fournir aux auditeurs, grands clients ou régulateurs des preuves plus approfondies.

Plus la dépendance est forte, plus l’obligation de preuve est forte. Un fournisseur à faible dépendance peut fournir un avis de base et une remédiation. Un fournisseur mondial de colocation dont les sites hébergent des charges de travail adjacentes au cloud et des écosystèmes d’interconnexion devrait s’attendre à un examen plus approfondi. Les clients peuvent demander des rapports d’incident, des attestations de contrôle, des questionnaires de sécurité mis à jour, des preuves de continuité d’activité et des engagements concernant les futures notifications. Ces demandes ne sont pas bureaucratiques.

Elles sont la façon dont les clients transforment l’affirmation de continuité d’un fournisseur en leur propre décision de risque.

La gouvernance client doit demander des preuves avant le prochain incident

Le cas Equinix montre également une faiblesse du côté client. De nombreux clients traitent les fournisseurs de centres de données comme une infrastructure stable et les examinent lourdement lors de l’approvisionnement initial, puis légèrement lors du renouvellement. Une divulgation de rançongiciel devrait changer ce rythme. La question de gouvernance pertinente n’est pas de savoir si le fournisseur reste un opérateur réputé. C’est de savoir si le client a suffisamment de preuves pour comprendre quelles parties de son propre plan de continuité dépendent des contrôles d’incident internes du fournisseur.

Pour une grande entreprise, cette demande de preuves devrait être structurée. Le client devrait demander comment le fournisseur sépare l’informatique interne, les opérations des installations, l’administration des services gérés, les portails clients, les flux de travail de support et le provisionnement de l’interconnexion. Il devrait demander si les identités privilégiées pour ces fonctions sont isolées et surveillées.

Il devrait demander comment les déterminations d’impact client sont faites, qui approuve les avis aux clients, quelles informations sont disponibles pendant le premier jour d’un incident et quel matériel d’assurance est fourni après la récupération. La demande ne devrait pas exiger de schémas sensibles en public. Elle devrait exiger une manière crédible de vérifier que l’affirmation de frontière n’est pas seulement une phrase de relations publiques.

Pour une petite ou moyenne entreprise, la même discipline est plus difficile mais encore possible. Les PME peuvent ne pas avoir de levier direct sur un fournisseur mondial, mais elles peuvent demander à leur fournisseur de services gérés, courtier cloud, revendeur d’hébergement ou fournisseur de réseau quelle dépendance en amont existe. Si leur charge de travail dépend d’une installation d’Equinix, elles devraient savoir qui reçoit les avis d’incident, comment ces avis sont relayés, quelles alternatives de continuité existent et si le support peut continuer si les systèmes internes du fournisseur en amont sont dégradés.

Le problème de continuité des PME est souvent indirect. L’entreprise qui ressent la douleur opérationnelle peut ne pas être celle qui reçoit l’avis original du fournisseur.

Les clients devraient également séparer la continuité de service de la confidentialité des données. Un fournisseur peut maintenir l’alimentation et les services réseau en fonctionnement tout en enquêtant pour savoir si les systèmes internes contenaient des coordonnées clients ou des données de configuration. L’équipe de risque d’un client devrait donc poser deux séries de questions. La piste opérationnelle demande si les charges de travail, l’accès, l’interconnexion, le support et le provisionnement ont continué.

La piste de confidentialité demande si les métadonnées clients, les contrats, les listes d’accès, les tickets, les schémas ou les enregistrements de services gérés étaient dans les systèmes affectés. Combiner les deux permet à un fournisseur de répondre « opérations non affectées » tout en laissant une question de données non résolue. Les séparer produit un dossier de responsabilité plus propre.

Les équipes d’assurance, d’audit et d’approvisionnement devraient traiter cela comme une preuve vivante. Les assureurs cyber peuvent demander si les fournisseurs critiques ont testé la récupération après rançongiciel et la segmentation. Les auditeurs peuvent demander si les évaluations de risque tiers incluent l’examen de l’historique des incidents. Les équipes d’approvisionnement peuvent demander des clauses de droit d’audit, des délais de notification et une assurance post-incident.

Les équipes de continuité d’activité peuvent cartographier les sites, les interconnexions, les opérateurs, les accès cloud et les contacts de support qui dépendent du fournisseur. La question utile n’est pas « le fournisseur a-t-il eu un incident de rançongiciel? » De nombreuses organisations sérieuses en auront. La question utile est « qu’a prouvé l’incident sur la capacité du fournisseur à préserver la frontière de continuité du client? »

Le fournisseur devrait accueillir ce type d’examen si la frontière a tenu. Un opérateur bien gouverné peut transformer un incident en preuve de résilience: les systèmes internes ont été contenus; les opérations des installations sont restées stables; l’équipement client était isolé; les canaux de support ont continué; les dossiers clients ont été cadrés; les forces de l’ordre ont été notifiées; les artefacts de récupération ont été conservés; des améliorations de contrôle ont été apportées. Cette histoire est plus forte lorsqu’elle inclut des artefacts, des chronologies, des métriques et une assurance indépendante.

Elle est plus faible lorsqu’elle ne dépend que de la confiance en la marque.

Il y a aussi une raison commerciale d’être précis. L’investissement dans les centres de données repose de plus en plus sur des promesses concernant la densité des écosystèmes, la proximité du cloud, l’infrastructure d’IA, les charges de travail réglementées et l’interconnexion. Ces promesses créent une concentration. Lorsque de nombreux clients se regroupent autour du même fournisseur, les contrôles d’incident de ce fournisseur font partie de la résilience partagée du marché. Un événement de rançongiciel qui ne provoque pas de panne visible peut encore révéler si le fournisseur a la discipline de preuve nécessaire pour ce rôle.

La gouvernance client devrait tirer cette leçon avant le prochain événement qui force les mêmes questions sous plus de pression.

La même discipline de preuve devrait s’étendre aux opérations régionales. Un client avec de l’équipement dans une installation peut encore dépendre des équipes de support internes, des tickets centralisés, de l’accès partagé aux fournisseurs, de l’administration d’identité commune et du provisionnement réseau interrégional. Si ces couches partagées sont dégradées, la salle de données locale peut rester alimentée tandis que la capacité du client à demander des changements, confirmer l’accès ou coordonner un travail d’urgence se dégrade.

Un dossier de continuité mature sépare donc la preuve de l’état des installations de la preuve de la gestion des services. Il montre non seulement que les racks, l’alimentation, le refroidissement et l’interconnexion sont restés stables, mais aussi que les processus opérationnels autour d’eux ont conservé une communication fiable et des enregistrements de décision responsables.

Ce qu’une réparation durable devrait prouver

Une réparation durable après un incident de rançongiciel chez un opérateur de colocation devrait prouver six choses. Premièrement, elle devrait prouver le périmètre. Le fournisseur devrait savoir quels systèmes ont été affectés, lesquels ont été examinés et lesquels étaient en dehors de l’environnement compromis. Le périmètre devrait être basé sur des journaux, des preuves de points de terminaison, des enregistrements d’identité, de la télémétrie réseau et une analyse judiciaire, et non sur des hypothèses sur la propriété des unités commerciales.

Deuxièmement, elle devrait prouver la continuité opérationnelle. Le fournisseur devrait conserver des enregistrements montrant que les opérations des installations, les offres de services, les services gérés, le support client et les services d’interconnexion ont continué ou, si une partie s’est dégradée, comment la dégradation a été mesurée et communiquée. « Pleinement opérationnel » devrait pouvoir être retracé à des métriques opérationnelles. Cela n’exige pas de publier chaque métrique. Cela exige de les conserver.

Troisièmement, elle devrait prouver les frontières des données clients. En colocation, l’équipement client peut être en dehors de la compromission interne du fournisseur. Mais les métadonnées clients dans les systèmes du fournisseur peuvent encore. Les contrats, listes de contacts, journaux d’accès, tickets de service, détails d’interconnexion, schémas réseau, dossiers de facturation et enregistrements de services gérés peuvent tous créer un risque s’ils sont exposés. La réparation devrait inclure une analyse du cadrage des données clients et un dossier de décision de notification.

Quatrièmement, elle devrait prouver la réinitialisation des identités et le confinement des privilèges. Chaque compte privilégié, chemin d’accès à distance, groupe administratif, compte de service et identifiant de support connecté à l’environnement affecté devrait être examiné. Si les systèmes opérationnels utilisent des plans d’identité séparés, la réparation devrait prouver que cette séparation a tenu. S’il existait un pont d’identité, la réparation devrait expliquer comment il a été fermé ou surveillé.

Cinquièmement, elle devrait prouver l’intégrité des sauvegardes et de la restauration. Restaurer les systèmes internes après un rançongiciel est risqué si les sauvegardes ne sont pas propres ou si les systèmes restaurés sont reconnectés avant que la compromission ne soit comprise. Un fournisseur devrait conserver des preuves des points de restauration, des vérifications de logiciels malveillants, des rotations d’identifiants, du durcissement des systèmes et de la validation. L’objectif n’est pas seulement de rouvrir les systèmes. C’est de les rouvrir avec une affirmation défendable que l’attaquant n’a plus de contrôle pratique.

Sixièmement, elle devrait prouver la gouvernance. La direction, les responsables de sécurité, les équipes juridiques, les gestionnaires d’exploitation, les équipes clients et le conseil ont chacun des positions de contrôle différentes. La déclaration publique d’Equinix indiquait que les forces de l’ordre avaient été notifiées. Un dossier de responsabilité complet montrerait également qui a décidé de la divulgation publique, qui a approuvé la messagerie client, qui possédait le cadrage judiciaire, qui a examiné les preuves de continuité, qui a évalué la matérialité et qui a vérifié la remédiation.

Le contre-factuel n’est pas l’absence de rançongiciel; c’est un confinement inspectable

Aucun client sérieux d’infrastructure ne devrait s’attendre à ce qu’un grand fournisseur ne fasse jamais face à un rançongiciel. Le meilleur contre-factuel est que le confinement d’un fournisseur est inspectable. Cela signifie que le fournisseur peut montrer, sous pression, que la compromission des systèmes internes ne donne pas automatiquement accès aux opérations des installations, à l’équipement client, aux plans de contrôle des services gérés ou aux processus de continuité de service.

Cela signifie également que le fournisseur peut expliquer les effets clients sans attendre que les attaquants, les rumeurs ou les rapports tiers définissent le récit.

La déclaration d’Equinix affirmait le résultat de confinement central. L’angle de responsabilité demande si les preuves de confinement étaient assez solides pour le rôle de dépendance. Un fournisseur mature aurait préparé exactement cette question avant l’incident. Il aurait cartographié les services métiers critiques, les chaînes de dépendance, les frontières d’identité, les magasins de données clients, les niveaux de sauvegarde, les voies de contact avec les forces de l’ordre, les déclarations médiatiques, les scripts pour les équipes de compte clients et les seuils d’escalade réglementaire.

Il répéterait non seulement la récupération technique mais aussi la production de preuves pour les clients.

Le contre-factuel inclut également la préparation côté client. Les clients de colocation ne devraient pas externaliser toute la réflexion sur la continuité au fournisseur d’installations. Ils devraient savoir quelles charges de travail dépendent d’une installation, quels chemins d’accès alternatifs existent, quels tickets de support sont critiques, quelles interconnexions sont des points uniques de défaillance et comment ils répondraient si les systèmes de support du fournisseur se dégradaient.

Mais le client ne peut bien faire cela que si le fournisseur donne des informations claires, opportunes et techniquement limitées pendant les incidents.

Pour les PME, cela est particulièrement difficile. Les petits clients peuvent acheter via des partenaires et peuvent manquer de levier pour demander des preuves détaillées. C’est pourquoi la qualité de la divulgation publique importe. Une déclaration publique concise, précise et mise à jour peut réduire l’escalade alimentée par les rumeurs. Un ensemble d’assurance client ultérieur peut soutenir les décisions d’approvisionnement et de renouvellement. Des questionnaires de sécurité standardisés et des portails de confiance peuvent aider, mais seulement s’ils sont mis à jour après de véritables incidents plutôt que de rester génériques.

La responsabilité suit le contrôle sur la surface de continuité partagée

L’allocation finale devrait suivre le contrôle pratique. Equinix contrôlait ses systèmes internes, ses opérations d’installations, ses flux de travail de support de service, sa communication client, son processus de réponse aux incidents et sa production de preuves. Les clients contrôlaient leur propre équipement et applications dans l’environnement de colocation. Les forces de l’ordre contrôlaient l’enquête criminelle. Les journalistes tiers contrôlaient les reportages publics sur la famille de rançongiciel présumée et la demande de rançon.

Les investisseurs et les équipes d’approvisionnement contrôlaient leurs propres décisions de risque, mais ils dépendaient des preuves fournies par la partie la plus proche de l’environnement compromis.

Cette allocation ne signifie pas qu’Equinix était responsable de chaque interprétation aval de l’incident. Cela signifie que la charge de la preuve était la plus élevée sur l’opérateur qui pouvait inspecter la frontière. Si la frontière a tenu, l’opérateur devrait pouvoir le prouver. Si certains dossiers clients dans les systèmes internes étaient à risque, l’opérateur devrait pouvoir les cadrer et notifier. Si aucune action client n’était requise, l’opérateur devrait pouvoir expliquer pourquoi. Si des détails privés ne pouvaient être publics, l’opérateur devrait quand même fournir une structure fiable pour l’assurance client.

L’incident de rançongiciel d’Equinix en 2020 reste important car il n’a pas été retenu comme une panne majeure de colocation. C’est précisément pourquoi il est utile. Il montre le problème de responsabilité dans le meilleur des cas: lorsqu’un fournisseur déclare que l’incident n’a pas atteint la surface de continuité partagée, les clients ont encore besoin d’une preuve de la frontière. L’absence de panne visible n’est pas la même chose qu’une responsabilité complète.

La leçon durable est que la confiance dans les centres de données dépend de la preuve que la compromission d’entreprise, l’équipement client, les opérations des installations, les services gérés et les canaux de communication sont séparés par conception et en pratique.

Pour l’infrastructure numérique mondiale, la divulgation du rançongiciel est donc une discipline de continuité. Un fournisseur gagne la confiance non pas en disant que le rançongiciel était limité, mais en étant capable de montrer comment la limitation a été détectée, mesurée, maintenue, communiquée et réparée.