Rackspace Hosted Exchange a transformé l'hébergement de courriels en un test de responsabilité de continuité

Synthèse

• Rackspace a divulgué un incident de rançongiciel affectant son environnement Hosted Exchange en décembre 2022. Samise à jour du 6 décembreindiquait que l'incident avait entraîné des perturbations de service pour les clients d'Hosted Exchange, avait conduit Rackspace à isoler l'environnement et avait incité à fournir un support à la migration des clients vers de nouveaux environnements.
• Lamise à jour du 9 décembrede Rackspace et leformulaire 8-K de la SECassocié indiquaient que CrowdStrike avait confirmé que l'incident avait été rapidement circonscrit et limité uniquement à Hosted Exchange, une solution de messagerie gérée principalement utilisée par les petites et moyennes entreprises et représentant environ 1 % du chiffre d'affaires de Rackspace.
• Le préjudice pour les clients était plus important que ce que suggère cette part de revenus. Le courriel est un système d'exploitation pour les petites entreprises: prise en charge des clients, factures, délais légaux, planification des patients, approbations des fournisseurs, messages de paie, événements de calendrier, pièces jointes et dossiers clients peuvent tous résider dans des boîtes aux lettres hébergées.
• Rackspace a poussé les clients vers la migration vers Microsoft 365, a mobilisé du personnel de support supplémentaire et a ensuite fourni une récupération de données échelonnée via des fichiers PST. Sesmises à jour de statutavertissaient que la récupération était limitée aux données de courriels historiques d'Hosted Exchange antérieures au 2 décembre 2022 et que certains courriels et autres données pouvaient rester indisponibles.
• Des dépôts ultérieurs de Rackspace auprès de la SEC indiquaient que l'activité Hosted Exchange était en cours d'arrêt, que de nombreux clients avaient été transférés vers Microsoft 365, que des poursuites judiciaires avaient été engagées et que Rackspace avait comptabilisé des dépenses liées à l'incident, des recouvrements d'assurance et des frais juridiques/professionnels continus. L'incident est donc devenu un dossier de responsabilité de continuité, et pas seulement une panne de décembre.
• Le contexte des vulnérabilités de Microsoft Exchange est important, mais il n'efface pas la responsabilité du fournisseur. Microsoft avait publié des conseils et des mises à jour pour les vulnérabilités d'Exchange, notammentCVE-2022-41040 et CVE-2022-41082, tandis que des rapports publics ultérieurs et des analyses de fournisseurs ont abordé OWASSRF et CVE-2022-41080. Rackspace contrôlait toujours l'environnement hébergé, les décisions de correctifs, les mesures d'atténuation, la conception des sauvegardes et le processus de récupération des clients.

L'hébergement de messagerie représentait un faible chiffre d'affaires mais une forte dépendance

Les documents publics de Rackspace mettent en évidence un fait: Hosted Exchange n'était pas une activité importante pour Rackspace. La mise à jour du 6 décembre sur l'incident indiquait que l'activité Hosted Exchange générait environ 30 millions de dollars de revenus annuels dans le segment Apps & Cross Platform. La mise à jour du 9 décembre et le formulaire 8-K précisaient que cette activité représentait environ 1 % du chiffre d'affaires annuel total de Rackspace et qu'elle était composée principalement de petites et moyennes entreprises qui utilisaient exclusivement le produit. Pour les investisseurs, cela permettait de cadrer la matérialité financière. Pour les clients, cela passait à côté de l'ampleur réelle de la dépendance.

Le courriel n'est pas une application marginale pour une petite entreprise. C'est le lieu où les bons de commande arrivent, où les dates d'audience sont discutées, où les rendez-vous des patients sont confirmés, où les factures sont relancées, où les demandes d'assistance sont traitées, où les dossiers des employés sont échangés, où les documents d'assurance sont conservés, où les négociations de bail ont lieu, où les sous-traitants envoient des pièces jointes et où les clients attendent des réponses. Les données du calendrier et des contacts sont souvent aussi importantes que le corps des messages. Une petite entreprise peut perdre l'accès à un module complémentaire de CRM ou de comptabilité pendant une journée et s'en accommoder. Perdre le courriel et les calendriers sans un chemin de sauvegarde propre peut perturber presque toutes les relations simultanément.

C'est pourquoi l'incident Rackspace relève de la dépendance aux services cloud et de la continuité des services pour les PME. Les clients ont choisi un fournisseur géré en partie parce qu'il est difficile d'exploiter Exchange en toute sécurité. Microsoft Exchange Server a une longue histoire de ciblage et la maintenance de la sécurité n'est pas triviale pour les petites organisations. Un fournisseur hébergé promet d'absorber cette charge opérationnelle: correctifs, surveillance, sauvegardes, disponibilité, support, migration et réponse aux incidents. Lorsque l'environnement de ce fournisseur tombe en panne, les clients n'ont pas d'accès administrateur pour le restaurer eux-mêmes.

Lamise à jour du 6 décembrede Rackspace indiquait qu'elle avait engagé une entreprise leader en cyberdéfense, isolé l'environnement Hosted Exchange, estimé que l'événement était limité à Hosted Exchange et commencé à communiquer avec les clients pour les aider à migrer vers un nouvel environnement aussi rapidement que possible. Elle indiquait également que Rackspace avait mobilisé du personnel de support supplémentaire et prendrait des mesures additionnelles pour guider les clients tout au long du processus.

Ces actions étaient peut-être nécessaires. Elles montrent également le déséquilibre de pouvoir. Le fournisseur contrôle l'environnement et le client ne contrôle que les solutions de contournement. Un client peut configurer un transfert s'il est demandé, migrer s'il est pris en charge, télécharger des fichiers PST récupérés s'ils sont disponibles et communiquer par des canaux alternatifs. Il ne peut pas restaurer l'environnement hébergé partagé, inspecter le chemin du rançongiciel ou prouver l'intégrité de la boîte aux lettres sans preuve du fournisseur.

La chronologie est passée d'une panne à un rançongiciel puis à une transition forcée

La chronologie des statuts publics est importante car les clients ont vécu de l'incertitude avant de recevoir une explication complète. La page de statut du système de Rackspace a ensuite conservé les premières mises à jour. Lapage de statut des problèmes Hosted Exchangeindiquait que Rackspace avait pris connaissance d'un problème affectant Hosted Exchange le vendredi 2 décembre 2022, avait proactivement mis hors tension et déconnecté l'environnement tout en évaluant la gravité, puis avait déterminé qu'il s'agissait d'un incident de sécurité. Le 6 décembre, Rackspace a annoncé publiquement le rançongiciel.

Cette séquence n'est pas inhabituelle dans la réponse à un incident. Les premières équipes techniques peuvent voir des échecs de connexion, une dégradation du service, une activité suspecte ou des systèmes corrompus avant de pouvoir affirmer en toute sécurité qu'il s'agit d'un rançongiciel. Mais pour les clients, chaque heure d'ambiguïté compte. Un cabinet d'avocats qui manque des communications judiciaires, une clinique qui manque des messages de patients, un entrepreneur qui manque des questions d'appel d'offres ou un détaillant qui manque des commandes de vacances doit savoir si le courriel va revenir, si les messages sont en sécurité et s'il faut activer un nouveau service.

Le communiqué de presse du 6 décembre de Rackspace indiquait qu'elle était en communication continue avec les clients d'Hosted Exchange pour les aider à migrer vers un nouvel environnement aussi rapidement que possible. La mise à jour du 9 décembre était plus explicite: Rackspace faisait activement passer les clients affectés à Microsoft Office 365, beaucoup ayant déjà terminé leur migration, et avait mis à disposition des ressources, notamment du personnel de renfort supplémentaire et une équipe Microsoft Fast Track complétant les effectifs de Rackspace.

Cette réponse a transformé l'incident d'un événement de restauration en un événement de migration. Les clients n'attendaient pas simplement qu'un service hébergé revienne. Ils étaient transférés vers une plateforme différente. La migration dans des conditions d'urgence est difficile. Les administrateurs ont besoin de nouveaux comptes, d'enregistrements de domaine, de modifications DNS, de mots de passe, d'appareils, de profils Outlook, de reconfiguration de la messagerie mobile, de boîtes aux lettres partagées, de listes de distribution, de calendriers, d'autorisations, d'archives, de règles de conservation et de support utilisateur. Chaque tâche est gérable dans une migration planifiée. Lors d'une panne due à un rançongiciel, cela devient un travail de crise.

La question clé de responsabilité n'est donc pas de savoir si Rackspace aurait dû actionner un interrupteur plus rapidement. La meilleure question est de savoir si le service hébergé a été conçu avec une sortie d'urgence crédible: des exportations de boîtes aux lettres portables, des sauvegardes à jour, des manuels de migration testés, un personnel de support adéquat, des registres de propriété spécifiques aux clients, des conseils sur les modifications DNS et des attentes claires sur ce qui pourrait être récupéré comme courrier historique.

Le confinement a protégé l'entreprise dans son ensemble, mais les clients ont quand même perdu le service

Rackspace a mis l'accent sur le confinement. La mise à jour du 9 décembre indiquait que CrowdStrike avait confirmé que l'action rapide de déconnexion du réseau et le suivi des plans de réponse aux incidents avaient rapidement circonscrit l'incident et l'avaient limité uniquement à Hosted Exchange. Elle précisait qu'aucun autre produit, plateforme, solution ou activité de Rackspace n'avait été affecté ou ne subissait de temps d'arrêt en raison de l'incident. Le formulaire 8-K de la SEC portait le même message.

Cette distinction est importante. Un fournisseur confronté à un rançongiciel peut avoir besoin d'isoler les systèmes de manière agressive pour empêcher la propagation. Le confinement peut être la bonne décision de sécurité même lorsqu'il aggrave la disponibilité pour les clients affectés. Un fournisseur qui retarde l'isolement pour préserver la disponibilité peut aggraver la brèche. Un fournisseur qui isole rapidement peut sauver le reste de l'environnement tout en laissant les clients sur la touche.

Le problème de responsabilité n'est pas que Rackspace ait isolé l'environnement. C'est que l'isolement a révélé la dépendance des clients à une récupération contrôlée par Rackspace. On a dit aux clients d'Hosted Exchange de migrer ou d'attendre les travaux de récupération. Ils ne pouvaient pas choisir un autre snapshot de sauvegarde, monter leur propre base de données ou inspecter directement les serveurs Exchange. Pour beaucoup, l'actif opérationnel le plus important était enfermé dans un processus d'incident contrôlé par le fournisseur.

C'est une leçon centrale des services cloud. Le confinement du fournisseur et la continuité du client peuvent aller dans des directions opposées. Le fournisseur doit arrêter l'attaquant et préserver les preuves. Les clients ont besoin de communication, de flux de messages, d'anciens courriels, de calendriers, de contacts et d'une estimation. Le plan de réponse à l'incident doit servir ces deux objectifs. Si le plan ne protège que l'entreprise du fournisseur et non la capacité des clients à continuer à fonctionner, le fournisseur a circonscrit l'événement de sécurité mais a exporté l'interruption d'activité.

Les mises à jour de statut de Rackspace montrent qu'elle a essayé de créer des voies parallèles: migration vers Microsoft 365 pour les futurs courriels, récupération de données pour le courrier historique et ressources de support. Cette séparation était judicieuse. Mais elle a également montré les limites de la conception originale. Les futurs courriels ne pouvaient continuer que si les clients migraient ou transféraient. La récupération du courrier historique nécessitait une extraction méticuleuse de l'environnement Hosted Exchange et une mise à disposition échelonnée de PST. Certaines données pouvaient rester indisponibles. Ces faits suggèrent que le produit n'avait pas un modèle de basculement propre et quasi instantané pour chaque boîte aux lettres client.

Pour un produit de messagerie hébergé legacy, cela n'est peut-être pas surprenant. Mais les clients d'un fournisseur géré ont le droit de comprendre le compromis de continuité avant une crise. Si le produit est peu coûteux parce qu'il manque de résilience moderne, les clients doivent le savoir. Si les sauvegardes ne sont pas en libre-service pour le client, les clients doivent le savoir. Si un événement de rançongiciel peut forcer une migration plutôt qu'une restauration, les clients doivent le savoir.

Le contexte des vulnérabilités de Microsoft Exchange est réel, mais limité

Le contexte des vulnérabilités d'Exchange est essentiel pour l'incident Rackspace. Microsoft a publié des conseils sur les vulnérabilités zero-day signalées dans Exchange Server en septembre 2022. Sonblog MSRCindiquait que Microsoft était conscient d'attaques ciblées limitées utilisant CVE-2022-41040 et CVE-2022-41082, qu'un accès authentifié était nécessaire et que les clients Exchange Online n'avaient pas besoin d'agir. Microsoft a ensuite fortement recommandé d'appliquer les mises à jour d'Exchange Server pour ces vulnérabilités. Sonanalyse de blog de sécuritédécrivait la chaîne SSRF et d'exécution de code à distance et notait les premières attaques ciblées.

Lamise à jour de sécurité Exchange du 8 novembre 2022 KB5019758de Microsoft résolvait plusieurs vulnérabilités d'Exchange, notamment CVE-2022-41040, CVE-2022-41082 et CVE-2022-41080. Lapage NVD pour CVE-2022-41080l'identifie comme une vulnérabilité d'élévation de privilèges dans Microsoft Exchange Server, tandis que laNVD pour CVE-2022-41082identifie une vulnérabilité d'exécution de code à distance et note sa présence dans le catalogue des vulnérabilités connues et exploitées de la CISA. Lecatalogue des vulnérabilités connues et exploitéesde la CISA existe précisément parce que les organisations peinent à prioriser suffisamment rapidement les vulnérabilités exploitées.

Des analyses tierces ultérieures ont relié un chemin d'exploitation connexe, OWASSRF, à CVE-2022-41080 et CVE-2022-41082. Lebrief sur les menaces OWASSRFd'Unit 42 décrivait la méthode d'exploitation comme utilisant OWA et contournant les atténuations antérieures associées à ProxyNotShell. L'analyse publiée par CrowdStrike elle-même a fait partie du dossier technique public, bien que l'article sur Rackspace doive éviter de surestimer au-delà des déclarations officielles de Rackspace et des rapports fiables.

Ce contexte est important car le calendrier des correctifs, les atténuations et l'ambiguïté des vulnérabilités sont difficiles. Un fournisseur hébergé peut être confronté à un risque de compatibilité, à une perturbation des clients et à des conseils d'atténuation initiaux incomplets. Mais la difficulté n'est pas une exonération de responsabilité. Rackspace vendait de la messagerie gérée. Elle contrôlait si les serveurs Exchange étaient exposés, corrigés, atténués, surveillés, segmentés, sauvegardés et isolés. Les clients ne le faisaient pas.

La conclusion mature est donc équilibrée. Microsoft contrôlait le produit Exchange et les mises à jour de sécurité. Les attaquants contrôlaient l'exploitation malveillante et le déploiement du rançongiciel. Rackspace contrôlait l'environnement hébergé et la continuité des clients. Les clients contrôlaient très peu de choses dans cet environnement. Une analyse de responsabilité qui ne blâme que Microsoft ou que Rackspace est trop grossière. Le vrai bilan se situe à travers les conseils de correctifs du fournisseur, la mise en œuvre du fournisseur de services et la dépendance des clients.

La disponibilité des sauvegardes est devenue la ligne de démarcation pratique des préjudices

Après la restauration ou la migration du service de messagerie, la question suivante est celle des anciens courriels. La page de statut de Rackspace est inhabituellement révélatrice sur ce point. Le 21 décembre, elle indiquait que Rackspace avait terminé la préparation de la récupération des données de courriels des clients et mettrait à disposition les données de courriels historiques sous forme de fichiers PST via un portail. Le 22 décembre, elle indiquait que les fichiers PST étaient disponibles pour les clients dont plus de 50 % des boîtes aux lettres avaient été récupérées, et que les fichiers seraient disponibles via le portail client pendant 30 jours. Le 27 décembre, elle rappelait aux clients que la récupération était limitée aux données de courriels historiques d'Hosted Exchange antérieures au 2 décembre 2022 et que certains courriels et autres données pouvaient rester indisponibles.

Ces mises à jour définissent la ligne de préjudice. Un client qui a migré rapidement pouvait reprendre les nouveaux courriels, mais les anciens messages, pièces jointes, éléments de calendrier et contacts n'étaient pas nécessairement disponibles immédiatement. Les données postérieures au 2 décembre dépendaient des choix de migration, de transfert, de service alternatif ou d'archivage. La récupération des données historiques s'est déroulée séparément. Certains éléments pouvaient rester indisponibles. Les fichiers PST nécessitaient un téléchargement, un stockage, un chargement d'archive et un support utilisateur.

Pour un utilisateur individuel, un PST n'est qu'un fichier d'archive. Pour une entreprise, la récupération de PST peut devenir un projet opérationnel de plusieurs semaines. Quelles versions de boîtes aux lettres sont complètes? Quelle boîte aux lettres partagée appartient à quel service? Où vont les calendriers? Comment les doublons sont-ils gérés? Comment les obligations de conservation légale et de rétention sont-elles préservées? Que se passe-t-il si un utilisateur a quitté l'entreprise pendant l'incident? Que se passe-t-il si un client ne peut pas télécharger dans la fenêtre de 30 jours? Que se passe-t-il si un employé charge une archive dans le mauvais tenant? Que se passe-t-il si des courriels privilégiés ou réglementés sont stockés de manière non sécurisée pendant la récupération d'urgence?

C'est pourquoi la conception des sauvegardes est une question de responsabilité et non une note technique de bas de page. Un fournisseur géré doit savoir si les clients peuvent récupérer des boîtes aux lettres de manière indépendante, à quelle fréquence les sauvegardes sont testées, comment le rançongiciel affecte l'intégrité des sauvegardes, comment les exportations spécifiques aux clients sont authentifiées, combien de temps les fichiers récupérés restent disponibles et quel support existe pour les clients ayant des obligations de conformité. Les clients ne devraient pas découvrir les limites des sauvegardes pendant que leurs boîtes aux lettres sont hors ligne.

Le langage de statut de Rackspace était prudent. Il ne promettait pas que tout serait récupéré. Il décrivait un processus méticuleux et mettait en garde contre les limites. Cette franchise est importante. Mais elle confirme également que certains clients ont été confrontés à l'incertitude quant au retour de leur historique. Pour les entreprises dont les courriels contiennent des dossiers juridiques, médicaux, comptables ou de service client, cette incertitude peut être aussi dommageable que la panne initiale.

Le chemin de migration était à la fois un sauvetage et la fin du produit

Rackspace n'a pas simplement restauré les clients sur le même produit. Ses dépôts ultérieurs auprès de la SEC indiquent qu'elle a arrêté la plateforme Hosted Exchange sur site et a transféré de nombreux clients vers Microsoft 365 via un accord de revendeur avec Microsoft. Leformulaire 10-Q de septembre 2023indique que l'activité de messagerie Hosted Exchange était une solution gérée fournie aux petites et moyennes entreprises, représentait environ 1 % du chiffre d'affaires annuel, a été rapidement circonscrite et limitée à Hosted Exchange, et que Rackspace a arrêté la plateforme Hosted Exchange sur site.

Cela est important car les clients sont entrés dans une panne et sont sortis d'une gamme de produits. La migration vers Microsoft 365 a pu être techniquement et stratégiquement raisonnable. Microsoft 365 peut offrir une résilience de messagerie cloud moderne, des contrôles de sécurité et une échelle opérationnelle que l'Exchange hébergé legacy ne peut égaler. Mais une migration forcée sous la pression d'un rançongiciel n'est pas la même chose qu'un projet de modernisation planifié. Les clients peuvent être confrontés à de nouvelles questions de licence, de configuration, de localisation des données, de formation, de conformité, d'administration et de facturation.

La question de responsabilité n'est pas de savoir si Microsoft 365 était une mauvaise destination. C'était probablement un chemin pratique pour rétablir le flux de courrier. La question est de savoir si les clients ont eu un préavis, un support et des preuves de récupération suffisants lorsque l'ancien service a effectivement pris fin. Un fournisseur qui vend un produit hébergé legacy doit gérer le risque de fin de vie avant une brèche, pas après. Si l'incident a forcé une décision de fin de vie, les clients méritent des clarifications sur les avoirs de service, les conditions contractuelles, l'exportation de données, le transfert, la récupération d'archives et les obligations futures.

La migration a également modifié les frontières de responsabilité. Une fois les clients passés à Microsoft 365, Microsoft contrôlait une grande partie de la plateforme de messagerie sous-jacente, Rackspace pouvait rester un revendeur ou un fournisseur de support, et les clients avaient de nouveaux choix administratifs. Cela peut améliorer la sécurité, mais cela peut également brouiller les responsabilités en cas de problème. Qui gère le support? Qui contrôle la configuration du tenant? Qui conserve les anciens fichiers PST? Qui assure la récupération des boîtes aux lettres? Qui facture? Qui répond aux régulateurs?

Les petites et moyennes entreprises dépendent souvent des fournisseurs précisément parce qu'elles n'ont pas de personnel interne pour ces questions. Une migration de crise peut leur laisser des comptes qui fonctionnent mais une gouvernance désordonnée. La vraie récupération signifie non seulement "le courriel est de retour" mais "les boîtes aux lettres, les calendriers, les archives, les transferts, la rétention, la propriété du support et la facturation ont tous un sens".

La qualité de la communication est devenue une partie de l'incident

Les reportages publics de l'époque se sont fortement concentrés sur la communication. Axios a rapporté la frustration des clients et la difficulté de la transparence après un rançongiciel dansson article de décembre 2022. Le directeur des produits de Rackspace a déclaré, en substance, que l'entreprise privilégiait l'exactitude et faisait attention à ce qu'elle pouvait dire. Cette tension est réelle. Trop partager pendant un événement de rançongiciel en direct peut révéler des informations défensives, perturber les négociations ou les enquêtes et créer une exposition juridique. Sous-communiquer laisse les clients incapables de fonctionner.

Le cas Rackspace montre pourquoi les mises à jour de statut génériques sont insuffisantes pour les services gérés critiques pour l'entreprise. Les clients avaient besoin de différents types d'informations à différents moments. Au début, ils avaient besoin de savoir si le flux de courrier était interrompu, si les messages étaient mis en file d'attente ou perdus, et s'il fallait utiliser des canaux alternatifs. Une fois le rançongiciel confirmé, ils avaient besoin d'instructions de migration, de conseils DNS, de contacts de support et de conseils de sécurité. Pendant la récupération, ils avaient besoin de calendriers PST, d'attentes d'exhaustivité, de procédures de téléchargement et de gestion d'archives. Après l'incident, ils avaient besoin de preuves pour les assureurs, les régulateurs, les clients et leurs propres conseils d'administration ou propriétaires.

Rackspace a bien publié des mises à jour via des communiqués pour investisseurs, des dépôts auprès de la SEC et une page de statut. Elle a mobilisé du support et impliqué Microsoft Fast Track. Ce sont des actions significatives. Mais l'existence de la frustration des clients montre que la charge de communication était plus lourde que ce que les canaux ordinaires de Rackspace pouvaient facilement supporter. Des milliers de PME, chacune avec des utilisateurs demandant où était passé leur courriel, créent une tempête de support.

C'est là que la planification des incidents doit être brutalement pratique. Un fournisseur devrait pré-construire des modèles de messages pour les administrateurs, les utilisateurs finaux, les clients réglementés, les partenaires MSP et les cadres. Il devrait avoir des canaux de communication alternatifs car le courriel peut être indisponible. Il devrait avoir des outils de statut en libre-service qui ne nécessitent pas le produit affecté. Il devrait avoir un moyen de vérifier les administrateurs clients avant de remettre les fichiers de récupération. Il devrait coordonner avec les principaux partenaires de migration avant la crise si un produit legacy peut nécessiter une évacuation d'urgence.

Le dossier public ne prouve pas que Rackspace a ignoré ces devoirs. Il montre que la communication en direct est devenue une dimension de l'incident. Un événement de rançongiciel dans un courriel hébergé ne concerne pas seulement le chiffrement ou l'exploitation; il s'agit de milliers d'entreprises ayant soudainement besoin d'instructions opérationnelles du même fournisseur au même moment.

Les états financiers n'ont capturé qu'une partie des coûts

Les divulgations financières de Rackspace montrent le coût de l'incident pour l'entreprise. La mise à jour du 6 décembre avertissait que l'incident pourrait interrompre les revenus d'Hosted Exchange et créer des coûts de réponse supplémentaires. Lesrésultats de l'exercice 2022 completindiquaient que la société avait enregistré des charges de dépréciation non monétaires importantes au T4 2022, y compris une dépréciation du goodwill dans le segment Apps & Cross Platform, principalement due à la baisse de la capitalisation boursière suite à l'attaque de rançongiciel Hosted Exchange. Le 10-Q 2023 indiquait que Rackspace avait enregistré 5,0 millions de dollars de dépenses liées à l'incident Hosted Exchange pour les neuf mois clos le 30 septembre 2023, y compris les coûts d'enquête et de remédiation, les services juridiques et professionnels, et les ressources en personnel supplémentaires, tout en comptabilisant les recouvrements d'assurance attendus ou reçus.

Ces chiffres sont importants, mais ils ne représentent pas le total des préjudices pour les clients. Les pertes de facturation, les délais manqués, les coûts de consultants d'urgence, les heures supplémentaires du personnel, l'attrition des clients, les coûts de services de remplacement et les travaux de conformité d'une petite entreprise n'apparaissent pas nécessairement dans les dépenses de Rackspace. La part de revenus d'un fournisseur peut sous-estimer la dépendance des clients d'un ordre de grandeur. Un produit représentant 1 % du chiffre d'affaires du fournisseur peut représenter 100 % du courriel d'un client.

Cette asymétrie devrait façonner la responsabilité des fournisseurs de services. La matérialité financière pour le fournisseur n'est pas la même que la matérialité opérationnelle pour les clients. Les dépôts auprès de la SEC répondent aux questions des investisseurs. Ils ne répondent pas entièrement à la question de savoir si un cabinet d'avocats a manqué des communications privilégiées, si une clinique a reporté des rendez-vous, si un entrepreneur a perdu une correspondance d'appel d'offres ou si un comptable a pu récupérer des dossiers clients.

Les dépôts montrent également des séquelles juridiques. Le 10-Q de septembre 2023 indiquait que Rackspace avait été nommée dans plusieurs poursuites en lien avec l'incident de rançongiciel de décembre 2022, demandant des réparations équitables et compensatoires, et que Rackspace se défendait vigoureusement dans ces affaires. Ces poursuites sont des allégations, pas des conclusions. Mais leur existence est prévisible. Les clients qui ont acheté de la messagerie gérée et ont ensuite perdu l'accès à la messagerie et à la certitude de récupération des données chercheront des responsabilités par le biais de théories contractuelles, délictuelles, consuméristes ou de pertes d'exploitation.

La bonne limite pour l'article est la prudence. Il ne doit pas déclarer Rackspace juridiquement responsable à moins qu'un tribunal ne le fasse. Il peut dire que le dossier public montre une perturbation de service, une migration forcée, des limitations de récupération de données, des dépenses d'incident, des recouvrements d'assurance, des poursuites et l'arrêt du produit. Cela suffit pour analyser la gouvernance sans exagérer le droit.

L'exposition des données des clients était plus faible que l'impact de la panne, mais pas sans importance

L'incident Rackspace est parfois retenu comme une défaillance de disponibilité, mais les reportages publics ont également décrit l'accès aux données pour un sous-ensemble de clients. SecurityWeek a rapporté dansRackspace completes investigation into ransomware attackque Rackspace a constaté que les attaquants avaient accédé aux fichiers de table de stockage personnel (Personal Storage Table) de 27 clients sur près de 30 000 clients Hosted Exchange, tout en notant l'absence de preuve de vol de données réelles dans ce compte. Cybersecurity Dive a rapporté que Rackspace avait confirmé l'implication du rançongiciel Play et que les attaquants avaient utilisé un exploit associé à CVE-2022-41080, avec un petit pourcentage de clients Hosted Exchange affectés par l'accès aux données danssa couverture de janvier 2023.

L'article doit traiter ces rapports tiers comme utiles mais secondaires par rapport aux communiqués et dépôts officiels de Rackspace. Les principaux communiqués publics pour investisseurs de Rackspace se sont concentrés sur le rançongiciel, le confinement, l'isolement, la migration et l'impact commercial. Ils n'ont pas publié de rapport médico-légal complet de la même manière qu'un blog technique de fournisseur pourrait le faire. Néanmoins, la possibilité d'accès aux archives des boîtes aux lettres modifie le modèle de préjudice. Les archives de courriels peuvent contenir des données personnelles, des pièces jointes, des contrats, des formulaires fiscaux, des détails de santé, des conseils juridiques, des identifiants et des informations commerciales confidentielles.

Le nombre 27, s'il est utilisé, ne doit pas minimiser l'incident. L'accès aux données pour un sous-ensemble est un problème de confidentialité pour ces clients. L'indisponibilité du service pour des milliers est un problème de continuité pour la population plus large. Les deux peuvent être vrais. Un client dont le PST a été consulté fait face à un risque potentiel de divulgation. Un client dont le PST n'a pas été consulté peut quand même avoir perdu des jours ou des semaines d'activité.

Cette division est courante dans les cas de rançongiciel. Le rayon d'impact de la disponibilité peut être beaucoup plus grand que le rayon d'impact de l'exfiltration. Le débat public les fusionne souvent en un seul chiffre, mais les clients subissent des préjudices différents. La réponse à l'incident devrait donc fournir des déterminations spécifiques au client: le service a-t-il été perturbé, les données de la boîte aux lettres ont-elles été récupérées, des données ont-elles été consultées, quelle période a été affectée, quels enregistrements ont été impliqués, quels avis sont nécessaires et quelles preuves soutiennent ces réponses?

Sans preuves spécifiques au client, les entreprises sont laissées à deviner. Deviner coûte cher. Cela conduit à une notification excessive, à une sous-notification, à des refontes inutiles, à des manquements aux obligations réglementaires et à une méfiance évitable.

Les avoirs de service ne restaurent pas la continuité

Les contrats de services gérés incluent souvent des avoirs pour les pannes. Les avoirs peuvent être utiles. Ils sont également structurellement inadéquats pour les événements de continuité graves. Si une petite entreprise perd l'accès au courriel pendant une période critique, un avoir sur les frais de service futurs ne restaure pas les messages manqués, ne rétablit pas la confiance des clients, ne récupère pas les délais légaux, ne paie pas les heures supplémentaires du personnel ni ne remplace les coûts de consultation.

Les documents publics de Rackspace sur l'incident et les dépôts se sont concentrés sur le support à la migration, la récupération de données et l'impact commercial plutôt que sur une analyse détaillée des avoirs de service publics. Cela est approprié pour un article d'incident car le problème plus profond n'est pas la formule exacte des avoirs. C'est le décalage entre le prix de l'abonnement et la valeur de la dépendance. Le courriel hébergé peut être facturé par boîte aux lettres et par mois. Son interruption peut affecter des flux de revenus entiers.

Ce décalage est la raison pour laquelle les clients de SaaS critiques ont besoin d'une planification de continuité qui va au-delà du SLA du fournisseur. Les PME doivent savoir comment joindre les clients si le courriel hébergé tombe en panne, comment accéder au DNS de domaine, comment configurer des boîtes aux lettres d'urgence, comment préserver les anciens enregistrements MX, comment contacter le personnel en dehors du courriel, comment collecter les messages envoyés pendant une panne et comment prioriser la récupération. Les MSP doivent maintenir une documentation sur les domaines et les tenants pour aider rapidement les clients. Les fournisseurs doivent fournir des manuels de migration d'urgence et les tester.

Mais il serait injuste de faire porter tout le fardeau sur les PME. Le fournisseur se présente comme une expertise gérée. Il devrait concevoir en partant du principe que les clients ne sont pas des spécialistes d'Exchange. Cela inclut des options de sauvegarde/exportation claires, des objectifs de récupération transparents, un isolement de rançongiciel testé, des canaux de notification client indépendants du produit affecté et des limites en langage clair sur ce que le fournisseur peut récupérer.

Les avoirs sont un mécanisme comptable post-incident. La continuité est un mécanisme d'ingénierie et de gouvernance pré-incident. L'incident Rackspace a montré lequel des deux les clients avaient le plus besoin.

Les produits legacy nécessitent une gouvernance honnête des risques de fin de vie

Hosted Exchange existait sur un marché évoluant vers Microsoft 365 et d'autres services de messagerie cloud natifs. Les produits legacy peuvent rester précieux pour les clients ayant des préférences, des structures de coûts, des modèles administratifs ou des contraintes de migration spécifiques. Mais l'infrastructure legacy peut accumuler des risques: architectures plus anciennes, dépendances complexes de correctifs, focalisation d'ingénierie plus réduite, part de revenus en diminution et moins d'appétit pour des investissements majeurs de résilience.

La déclaration ultérieure de Rackspace selon laquelle elle a arrêté la plateforme Hosted Exchange sur site est un signal de gouvernance. Si le produit pouvait être arrêté après l'incident, les clients et le fournisseur doivent se demander si la fin de vie aurait dû intervenir plus tôt, de manière plus délibérée, ou avec des incitations à la migration plus fortes. Ce n'est pas un blâme rétrospectif. C'est la question standard après la défaillance d'un produit legacy sous une attaque active.

Un programme de fin de vie mature ne se contente pas d'annoncer la retraite. Il cartographie les clients, classe les risques, offre des fenêtres de migration, fournit des incitations financières, teste les outils de migration, documente l'exportation de données, répond aux besoins réglementaires, forme le personnel de support et crée des chemins d'escalade pour les clients qui ne peuvent pas migrer rapidement. Il indique également le risque résiduel de rester. Si un produit legacy reste disponible, les clients peuvent supposer que le fournisseur continue d'investir suffisamment pour le rendre sûr et résilient.

L'incident Rackspace illustre pourquoi un "petit chiffre d'affaires" peut être dangereux au sein d'un fournisseur. Un petit produit peut avoir une clientèle concentrée qui en dépend profondément. Il peut ne pas recevoir les mêmes investissements de modernisation que les produits de croissance. Pourtant, s'il échoue, les conséquences réputationnelles et juridiques peuvent dépasser la ligne de revenus. Le produit n'est petit que du point de vue comptable du fournisseur.

Pour les conseils d'administration et les cadres, c'est une leçon de risque de portefeuille. Chaque produit legacy qui stocke des données clients et exécute des opérations clients devrait avoir un dossier de résilience et de fin de vie. Que se passerait-il s'il tombait en panne pendant deux semaines? Combien de clients pourraient auto-exporter? Combien n'ont pas d'alternative? Quel renfort de support serait nécessaire? Que dirait le fournisseur si un rançongiciel forçait un arrêt immédiat? Si ces réponses sont inconfortables, la retraite ou la refonte n'est pas un travail stratégique optionnel. C'est un travail de responsabilité.

Les MSP et les partenaires faisaient partie de la chaîne de récupération

De nombreuses petites entreprises consomment du courriel hébergé par le biais d'intermédiaires ou avec l'aide de fournisseurs de services gérés (MSP). Pendant l'incident Rackspace, les MSP et les consultants informatiques sont devenus des traducteurs, des équipes de migration, des opérateurs DNS et des conseillers clients. La discussion publique dans les communautés MSP a reflété le stress de décider s'il fallait attendre, migrer, transférer ou abandonner le service. Cette discussion n'est pas une preuve principale, mais elle illustre une chaîne de dépendance réelle.

Rackspace contrôlait la plateforme affectée. Microsoft contrôlait la plateforme de destination et les mises à jour du produit Exchange. Les MSP contrôlaient l'administration locale des clients, l'accès DNS dans de nombreux cas, le support des appareils et la formation des utilisateurs. Les clients finaux contrôlaient les décisions commerciales et les communications avec leurs propres clients. Le succès de la récupération dépendait de la manière dont ces acteurs se coordonnaient.

La migration d'urgence crée de petites erreurs aux grands effets. Un MSP peut mettre à jour les enregistrements MX avant que tous les utilisateurs ne soient prêts. Un client peut oublier une boîte aux lettres partagée. Un utilisateur peut perdre le courriel mobile. Le courrier archivé peut se charger lentement. Les autorisations du calendrier peuvent se casser. Une conservation légale peut ne pas être transférée proprement. Un groupe de distribution peut être oublié. L'ancien mot de passe d'un utilisateur peut être réutilisé. Aucune de ces erreurs n'est l'incident de rançongiciel d'origine, mais toutes sont des conséquences de l'incident.

C'est pourquoi les fournisseurs gérés devraient traiter les partenaires comme des audiences de première classe pour les incidents. Les MSP ont besoin de manuels opérationnels techniques, de statuts clients en masse, de contacts administrateurs vérifiés, de conseils DNS, de scripts de migration, d'instructions de récupération d'archives et de contacts d'escalade. Si le fournisseur ne communique qu'aux propriétaires de comptes individuels, l'écosystème de partenaires devient un canal de rumeurs. S'il équipe bien les partenaires, l'écosystème de partenaires devient un multiplicateur de récupération.

Les communiqués publics de Rackspace mentionnent Microsoft Fast Track et le renforcement du personnel. C'était un signe de l'ampleur du travail. Les incidents futurs devraient aller plus loin en prédéfinissant les rôles des partenaires et les chemins d'autorisation d'urgence. Lors d'une panne de messagerie, la partie qui peut modifier le DNS et configurer le tenant de destination peut être plus importante que le titulaire nominal du contrat.

La carte de responsabilité est partagée, mais pas égale

L'attribution la plus claire est stratifiée. Les acteurs criminels étaient responsables de l'activité malveillante. Microsoft était responsable des mises à jour de sécurité du produit Exchange, des conseils sur les vulnérabilités et de l'architecture de sécurité d'Exchange et d'Exchange Online. Rackspace était responsable de l'environnement Hosted Exchange qu'elle exploitait, y compris les correctifs, les atténuations, la gestion de l'exposition, la surveillance, la segmentation, la sauvegarde et la restauration, la communication avec les clients, le support à la migration, la récupération de données et la stratégie produit. Les clients étaient responsables de leur propre planification de continuité, de l'accès au domaine, de la configuration des terminaux, de la communication avec les utilisateurs et de la gouvernance post-migration. Les MSP et les partenaires étaient responsables de l'exécution locale là où les clients dépendaient d'eux.

Ces responsabilités sont partagées mais pas égales. Les clients ont acheté de la messagerie gérée parce qu'ils ne contrôlaient pas les serveurs Exchange. Rackspace contrôlait l'environnement qui a échoué et le processus de récupération qui a suivi. Cela ne signifie pas que Rackspace a causé le rançongiciel. Cela signifie que le fournisseur détenait les leviers pratiques de prévention, de confinement, de restauration et de preuve.

L'incident montre également pourquoi la responsabilité cloud ne peut pas être mesurée uniquement par la disponibilité après la migration. Un client qui récupère de nouveaux courriels mais perd d'anciennes données de calendrier, attend des semaines pour les archives, ne peut pas prouver si les données ont été consultées ou doit payer des consultants d'urgence n'a pas été remis en état. La récupération a plusieurs états: flux de courrier, historique des boîtes aux lettres, continuité du calendrier, intégrité des archives, appareils des utilisateurs, posture de sécurité, preuves juridiques et confiance des clients.

La réponse de Rackspace contenait de bons éléments: confinement, engagement de cyberdéfense, divulgations publiques aux investisseurs, support à la migration Microsoft 365, renfort de support, mises à jour de statut et travaux de récupération de données. Le dossier public montre également des limites strictes: perturbation de service sévère, migration d'urgence, contraintes de récupération des données historiques, arrêt du produit, poursuites, coûts et incertitude résiduelle des clients. Les deux côtés appartiennent à l'évaluation.

La leçon plus large pour tout fournisseur de cloud géré est inconfortable. Si vous exploitez une plateforme legacy pour les petites entreprises, vous possédez plus que des serveurs. Vous possédez les options de continuité du client lorsque vos serveurs ne sont plus dignes de confiance. Cette propriété devrait être visible dans l'architecture avant l'attaque: sauvegardes testées, exportations en libre-service, RTO/RPO clairs, outils de migration d'urgence, manuels pour les partenaires, packages de preuves et planification honnête de la fin de vie.

Ce qui devrait changer après Rackspace

Pour les clients, l'incident Rackspace plaide pour des contrôles de continuité de base mais souvent négligés. Posséder les identifiants du registraire de domaine et du DNS. Tenir une liste à jour des boîtes aux lettres, alias, groupes de distribution, boîtes aux lettres partagées et administrateurs. Savoir qui peut modifier les enregistrements MX. Maintenir une liste de contacts hors bande pour les employés et les clients critiques. Exporter ou archiver les courriels critiques conformément aux exigences légales et commerciales. Tester la configuration de messagerie d'urgence. Conserver les contrats des fournisseurs et les contacts de support en dehors de la boîte aux lettres affectée. Demander aux fournisseurs ce qui se passe si leur plateforme de messagerie hébergée est arrêtée pour des raisons de sécurité.

Pour les fournisseurs, la leçon est plus exigeante. Ne vendez pas de services legacy gérés sans une histoire de défaillance crédible. Si un rançongiciel force l'arrêt, comment les clients récupèrent-ils le flux de courrier en quelques heures? Comment récupèrent-ils les anciens courriels en quelques jours? Comment savent-ils si les données ont été consultées? Comment les clients réglementés satisfont-ils aux obligations de notification? Comment les partenaires reçoivent-ils des instructions en masse? Comment le renfort de support est-il financé et doté en personnel? Comment les avoirs de service sont-ils liés aux obligations réelles de récupération? Quels clients sont encore sur la plateforme parce que la migration est difficile, et quel est le plan pour les aider à partir en toute sécurité?

Pour les éditeurs de logiciels, en particulier Microsoft dans ce contexte, les conseils sur les vulnérabilités doivent supposer que les clients incluent des fournisseurs gérés exploitant de grands domaines Exchange multi-tenant ou multi-clients. Les conseils qui fonctionnent pour une seule entreprise peuvent ne pas être simples sur le plan opérationnel pour un fournisseur ayant de nombreuses dépendances clients. Des déclarations claires sur l'exploitabilité, la priorité des correctifs, les limites des atténuations et les conseils de détection sont importants car les clients en aval ne peuvent pas voir les serveurs vulnérables.

Pour les régulateurs et les tribunaux, l'incident soulève une question familière: comment les systèmes juridiques devraient-ils évaluer un fournisseur dont le produit affecté est financièrement petit mais critique pour les clients? Les cadres traditionnels de matérialité et de dommages peuvent avoir du mal avec les préjudices distribués aux PME. Des milliers de petites pertes sont difficiles à agréger, documenter et plaider, mais elles peuvent représenter une réelle perturbation économique et civique.

Hosted Exchange de Rackspace est devenu un dossier édifiant car il a compressé ces questions en un seul événement. Un service géré est tombé en panne. Les clients ont dû migrer. La récupération des données historiques a été échelonnée et limitée. Un produit legacy a pris fin. Des poursuites ont suivi. Des dépenses et des recouvrements d'assurance sont apparus dans les dépôts. Le fournisseur a survécu, mais les clients ont appris que "hébergé" ne signifie pas "récupérable selon mes termes".

La norme de responsabilité après Rackspace devrait être simple: si un fournisseur de cloud est la seule partie qui peut restaurer le dossier opérationnel d'un client, le fournisseur doit plus que des promesses de disponibilité ordinaires. Il doit une continuité testée, des preuves portables, des communications claires et un chemin de sortie qui fonctionne avant le jour où les clients en ont désespérément besoin.