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

Résumé

• Rackspace a divulgué un incident de ransomware affectant son environnement Hosted Exchange en décembre 2022. Samise à jour du 6 décembrea indiqué que l'incident avait provoqué des interruptions de service pour les clients Hosted Exchange, conduit Rackspace à isoler l'environnement et incité à l’assistance à la migration des clients vers de nouveaux environnements.
• Lamise à jour du 9 décembrede Rackspace et leformulaire 8-K de la SECassocié ont déclaré que CrowdStrike avait confirmé que l'incident avait été rapidement confiné 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 a été plus important que ce que cette part de chiffre d'affaires laisse penser. La messagerie est un système d'exploitation pour les petites entreprises: les prises de contact clients, les factures, les échéances légales, la planification des rendez-vous des patients, les approbations des fournisseurs, les messages de paie, les événements du calendrier, les pièces jointes et les dossiers clients peuvent tous résider dans des boîtes aux lettres hébergées.
• Rackspace a poussé les clients vers la migration Microsoft 365, a renforcé son personnel de support, puis a fourni une récupération progressive des données via des fichiers PST. Sesmises à jour de statutavertissaient que la récupération était limitée aux données de messagerie Hosted Exchange antérieures au 2 décembre 2022 et que certains e-mails et autres données pourraient rester indisponibles.
• Des dépôts ultérieurs auprès de la SEC par Rackspace ont indiqué que l'activité Hosted Exchange avait été arrêtée, que de nombreux clients avaient été transférés vers Microsoft 365, que des poursuites avaient été engagées et que Rackspace avait enregistré des dépenses liées à l'incident, des recouvrements d'assurance et des coûts juridiques et professionnels continus. L'incident est donc devenu un dossier de continuité et de responsabilité, 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 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: un petit chiffre d'affaires, une dépendance majeure

Les documents publics de Rackspace établissent clairement un fait: Hosted Exchange n'était pas une ligne d'activité majeure 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 ont déclaré que cette activité représentait environ 1 % du chiffre d'affaires annuel total de Rackspace et était composée principalement de petites et moyennes entreprises utilisant exclusivement ce produit.

Pour les investisseurs, cela a permis de cadrer la matérialité financière. Pour les clients, cela a occulté l'ampleur réelle de la dépendance.

La messagerie n'est pas une application marginale pour une petite entreprise. C'est là que les bons de commande arrivent, que les dates d'audience sont discutées, que les rendez-vous des patients sont confirmés, que les factures sont relancées, que les demandes de support sont traitées, que les dossiers du personnel sont échangés, que les documents d'assurance sont stockés, que les négociations de bail se déroulent, que les sous-traitants envoient des pièces jointes et que les clients attendent des réponses. Les données du calendrier et les contacts sont souvent aussi importants que le corps des messages.

Une petite entreprise peut perdre l'accès à un CRM ou à un module complémentaire comptable pendant une journée et improviser. Perdre l'accès à la messagerie et aux 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é de service pour les PME. Les clients ont choisi un fournisseur géré en partie parce qu’il est difficile d’exécuter Exchange en toute sécurité. Microsoft Exchange Server a une longue histoire d’être ciblé, 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 de cyberdéfense de premier plan, isolé l'environnement Hosted Exchange, estimait que l'événement était circonscrit à Hosted Exchange, et avait commencé à communiquer avec les clients pour les aider à migrer vers un nouvel environnement aussi rapidement que possible. Elle indiquait également que Rackspace avait renforcé son personnel de support et prendrait des mesures supplémentaires 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 le transfert s'il est instruit, 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 ransomware, ou prouver l'intégrité de la boîte aux lettres sans preuves du fournisseur.

La chronologie est passée de la panne au ransomware, puis à la transition forcée

La chronologie des statuts publics est importante parce que les clients ont vécu de l'incertitude avant de recevoir une explication complète. La page d'état du système de Rackspace a par la suite préservé les premières mises à jour. La pageHosted Exchange Issues statusindiquait que Rackspace avait pris connaissance d'un problème affectant Hosted Exchange le vendredi 2 décembre 2022, avait mis hors tension et déconnecté l'environnement de manière proactive tout en évaluant la gravité, et avait déterminé plus tard qu'il s'agissait d'un incident de sécurité. Le 6 décembre, Rackspace a annoncé publiquement le ransomware.

Cette séquence n'est pas inhabituelle dans la réponse aux incidents. 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 déclarer avec certitude un ransomware. 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 la messagerie reviendra, si les messages sont sûrs 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 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 la transition des clients affectés vers Microsoft Office 365, nombre d'entre eux ayant déjà terminé la migration, et avait mis à disposition des ressources supplémentaires, y compris du personnel de renfort et une équipe Microsoft Fast Track venant compléter l'effectif 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 le retour d'un service hébergé. Ils étaient transférés vers une plate-forme différente. La migration dans des conditions d'urgence est difficile. Les administrateurs ont besoin de nouveaux comptes, enregistrements de domaine, modifications DNS, mots de passe, appareils, profils Outlook, reconfiguration des messageries mobiles, boîtes aux lettres partagées, listes de distribution, calendriers, autorisations, archives, règles de rétention et support utilisateur.

Chaque tâche est gérable dans une migration planifiée. Pendant une panne de ransomware, cela devient un travail de crise.

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

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

Rackspace a mis l'accent sur le confinement. La mise à jour du 9 décembre déclarait que CrowdStrike avait confirmé que l'action rapide de déconnexion du réseau et de suivi des plans de réponse aux incidents avait rapidement confiné l'incident et l'avait limité uniquement à Hosted Exchange. Il n'y avait pas d'autres produits, plates-formes, solutions ou activités Rackspace affectés ou subissant des temps d'arrêt en raison de l'incident. Le formulaire 8-K de la SEC contenait le même message.

Cette distinction est importante. Un fournisseur confronté à un ransomware 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 abandonnant les clients.

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 Hosted Exchange de migrer ou d'attendre les flux de travail de récupération. Ils ne pouvaient pas choisir un autre instantané 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 par le fournisseur et la continuité pour le 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 courriers, de calendriers, de contacts et d'une estimation. Le plan de réponse aux incidents 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 confiné 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 chemins parallèles: migration Microsoft 365 pour les futurs courriels, récupération de données pour les courriers historiques, et ressources de support. Cette séparation était judicieuse. Mais elle a également montré les limites de la conception originale. Les futurs courriers ne pouvaient continuer que si les clients migraient ou transféraient. La récupération du courrier historique exigeait une extraction méticuleuse de l'environnement Hosted Exchange et une disponibilité progressive des PST. Certaines données pourraient rester indisponibles.

Ces faits suggèrent que le produit n'avait pas de modèle de basculement propre et quasi instantané pour chaque boîte aux lettres client.

Pour un produit de messagerie hébergé patrimonial, 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 les clients, ils doivent le savoir. Si un événement de ransomware peut forcer la migration plutôt que la restauration, ils doivent le savoir.

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

Le contexte des vulnérabilités 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 au courant 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 par la suite fortement recommandé d'appliquer les mises à jour d'Exchange Server pour ces vulnérabilités. Sonblog d'analyse de sécuritéa décrit la chaîne SSRF et d'exécution de code à distance et noté les premières attaques ciblées.

Lamise à jour de sécurité Exchange du 8 novembre 2022 KB5019758de Microsoft a résolu plusieurs vulnérabilités Exchange, y compris CVE-2022-41040, CVE-2022-41082 et CVE-2022-41080. La pageNVD pour CVE-2022-41080l'identifie comme une vulnérabilité d'élévation de privilège de 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 exploitées connues de la CISA. Lecatalogue des vulnérabilités exploitées connues de la CISAexiste précisément parce que les organisations peinent à hiérarchiser les vulnérabilités exploitées assez rapidement.

Des analyses tierces ultérieures ont relié un chemin d'exploitation connexe, OWASSRF, à CVE-2022-41080 et CVE-2022-41082. Lebrief sur la menace OWASSRF de Unit 42a décrit 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 fait partie du dossier technique public, bien que l'article sur Rackspace doive éviter de surévaluer au-delà des déclarations officielles de Rackspace et des rapports fiables.

Ce contexte est important parce que le calendrier des correctifs, les atténuations et l'ambiguïté des vulnérabilités sont difficiles. Un fournisseur hébergé peut faire face à 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, non.

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 ransomware. Rackspace contrôlait l'environnement hébergé et la continuité des clients. Les clients contrôlaient très peu de choses à l'intérieur de cet environnement. Une analyse de responsabilité qui ne blâme que Microsoft ou que Rackspace est trop grossière. Le véritable dossier se situe entre les conseils de correctifs du fournisseur, la mise en œuvre du fournisseur et la dépendance des clients.

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

Une fois le service de messagerie restauré ou migré, la question suivante est celle des anciens courriers. 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 messagerie des clients et mettrait à disposition les données de messagerie 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 messagerie Hosted Exchange historiques, antérieures au 2 décembre 2022, et que certains e-mails et autres données pourraient 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 de la migration, du transfert, d'un service alternatif ou de choix d'archivage. La récupération des données historiques s'est déroulée séparément. Certains éléments pourraient 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îte aux lettres sont complètes? Quelle boîte aux lettres partagée appartient à quel service? Où vont les calendriers? Comment les doublons sont-ils traités? Comment les obligations de conservation légale 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 le délai 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 de la sauvegarde est une question de responsabilité, pas une note technique. Un fournisseur géré devrait savoir si les clients peuvent récupérer les boîtes aux lettres de manière indépendante, à quelle fréquence les sauvegardes sont testées, comment le ransomware 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 de la sauvegarde 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 avertissait des limites. Cette franchise compte. 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 a été à la fois un sauvetage et la fin du produit

Rackspace n'a pas simplement restauré les clients vers le même produit. Ses dépôts ultérieurs auprès de la SEC indiquent qu'elle a arrêté la plate-forme Hosted Exchange sur site et a fait migrer 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 confinée et limitée à Hosted Exchange, et que Rackspace a arrêté la plate-forme Hosted Exchange sur site.

Cela importe parce que les clients sont entrés dans une panne et sont sortis d'une ligne 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é patrimonial ne peut pas égaler. Mais une migration forcée sous la pression d'un ransomware 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 messagerie. La question est de savoir si les clients ont bénéficié d'un préavis, d'un support et de preuves de récupération suffisants lorsque l'ancien service a effectivement pris fin. Un fournisseur qui vend un produit hébergé patrimonial 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 éclaircissements sur les avoirs de service, les conditions contractuelles, l'exportation des données, le transfert, la récupération des 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 plate-forme 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 peut aussi brouiller la responsabilité 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 s'appuient souvent sur les fournisseurs précisément parce qu'elles n'ont pas de personnel interne pour ces questions. Une migration de crise peut les laisser avec des comptes qui fonctionnent mais une gouvernance qui est désordonnée. Une véritable reprise signifie non seulement « la messagerie est de retour », mais « les boîtes aux lettres, les calendriers, les archives, le transfert, la conservation, 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 post-ransomware dansson article de décembre 2022. Le chef de produit de Rackspace a déclaré, en substance, que l'entreprise privilégiait l'exactitude et était prudente sur ce qu'elle pouvait dire. Cette tension est réelle. Trop partager pendant un événement de ransomware 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 messagerie était interrompu, si les messages étaient mis en file d'attente ou perdus, et s'ils devaient utiliser des canaux alternatifs. Une fois le ransomware 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 de complétude, de procédures de téléchargement et de gestion des 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 par le biais de communiqués pour les investisseurs, de dépôts auprès de la SEC et d'une page de statut. Elle a renforcé le 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 courrier, créent une tempête de support.

C'est là que la planification des incidents doit être brutalement pratique. Un fournisseur devrait préparer à l'avance 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 la messagerie 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 l'identité des administrateurs clients avant de remettre les fichiers de récupération.

Il devrait se coordonner avec les principaux partenaires de migration avant la crise si un produit patrimonial 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 ransomware dans la messagerie hébergée 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 en même temps.

Les états financiers n'ont capté qu'une partie du coût

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 de Hosted Exchange et créer des coûts de réponse supplémentaires. Lapublication des résultats de l'exercice 2022indiquait 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 ransomware Hosted Exchange. Le 10-Q de 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, comprenant les coûts d'enquête et de remédiation, les services juridiques et professionnels et le personnel de renfort supplémentaire, tout en enregistrant les recouvrements d'assurance attendus ou reçus.

Ces chiffres comptent, mais ils ne représentent pas le préjudice total 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, la perte de clients, les coûts de service de remplacement et le travail de conformité d'une petite entreprise n'apparaissent pas nécessairement dans les dépenses de Rackspace. La part de chiffre d'affaires 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 % de la messagerie d'un client.

Cette asymétrie devrait façonner la responsabilité du fournisseur 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 pleinement à 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 les dossiers de ses clients.

Les dépôts montrent également des résidus juridiques. Le 10-Q de septembre 2023 indiquait que Rackspace était nommée dans plusieurs poursuites en lien avec l'incident de ransomware 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 la récupération des données chercheront à obtenir des comptes par le biais de théories contractuelles, délictuelles, de consommation ou de perte d'activité.

La limite de l'article approprié est prudente. 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 interruption de service, une migration forcée, des limitations de récupération des données, des dépenses liées à l'incident, des recouvrements d'assurance, des poursuites et l'arrêt du produit. C'est suffisant pour analyser la gouvernance sans exagérer le droit.

L'exposition des données des clients a été 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 rapports 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é à des fichiers Personal Storage Table pour 27 clients sur près de 30 000 clients Hosted Exchange, tout en notant l'absence de preuve de vol de données réel dans ce compte. Cybersecurity Dive a rapporté que Rackspace avait confirmé l'implication du ransomware 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 les investisseurs de Rackspace se sont concentrés sur le ransomware, le confinement, l'isolement, la migration et l'impact sur l'activité. 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'un accès aux archives de boîtes aux lettres modifie le modèle de préjudice.

Les archives de courriers électroniques peuvent contenir des données personnelles, des pièces jointes, des contrats, des formulaires fiscaux, des détails de santé, des conseils juridiques, des informations d'identification 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 tout de même avoir perdu des jours ou des semaines d'activité.

Cette division est courante dans les cas de ransomware. Le rayon de souffle de la disponibilité peut être beaucoup plus grand que le rayon de souffle de l'exfiltration. Le débat public les réduit souvent à un seul chiffre, mais les clients subissent des préjudices différents. La réponse aux incidents 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 étaient impliqués, quels avis sont requis et quelles preuves étayent ces réponses?

Sans preuves spécifiques au client, les entreprises sont réduites à deviner. Deviner coûte cher. Cela conduit à une notification excessive, une sous-notification, des retouches inutiles, des obligations réglementaires manquées 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 à sa messagerie 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 ses dépôts se sont concentrés sur le support à la migration, la récupération des données et l'impact sur l'activité plutôt que sur une analyse publique détaillée des avoirs de service. Cela est approprié pour un article sur l'incident parce que la question plus profonde 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. La messagerie hébergée peut être facturée par boîte aux lettres et par mois. Son interruption peut affecter des flux de revenus entiers.

Ce décalage explique pourquoi les clients de SaaS critiques ont besoin d'une planification de la continuité qui va au-delà du SLA du fournisseur. Les PME devraient savoir comment joindre leurs clients en cas de défaillance de la messagerie hébergée, comment accéder au DNS du domaine, comment configurer des boîtes aux lettres d'urgence, comment conserver les anciens enregistrements MX, comment contacter le personnel en dehors de la messagerie, comment collecter les messages envoyés pendant une panne et comment prioriser la récupération.

Les MSP devraient maintenir la documentation du domaine et du tenant afin de pouvoir aider rapidement leurs clients. Les fournisseurs devraient fournir des manuels de migration d'urgence et les tester.

Mais il serait injuste de faire porter tout le fardeau aux PME. Le fournisseur se présente comme une expertise gérée. Il devrait concevoir pour la réalité que les clients ne sont pas des spécialistes d'Exchange. Cela inclut des options claires de sauvegarde/exportation, des objectifs de récupération transparents, un isolement testé contre les ransomwares, 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 les clients avaient le plus besoin.

Les produits patrimoniaux ont besoin d'une gouvernance honnête du risque de fin de vie

Hosted Exchange existait sur un marché qui évoluait vers Microsoft 365 et d'autres services de messagerie cloud native. Les produits patrimoniaux 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 patrimoniale peut accumuler des risques: architectures plus anciennes, dépendances de correctifs complexes, focalisation d'ingénierie plus réduite, part de chiffre d'affaires en diminution et moindre appétit pour un investissement majeur en résilience.

La déclaration ultérieure de Rackspace selon laquelle elle a arrêté la plate-forme Hosted Exchange sur site est un signal de gouvernance. Si le produit a pu ê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 l'échec d'un produit patrimonial sous une attaque active.

Un programme de fin de vie mature ne se contente pas d'annoncer le retrait. Il cartographie les clients, classifie les risques, offre des fenêtres de migration, fournit des incitations financières, teste les outils de migration, documente l'exportation des 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 patrimonial 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 à l'intérieur d'un fournisseur. Un petit produit peut avoir une base de clients concentrée qui en dépend profondément. Il peut ne pas recevoir le même investissement 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 dirigeants, c'est une leçon de risque de portefeuille. Chaque produit patrimonial qui stocke des données clients et exécute les opérations des clients devrait avoir un dossier de résilience et de fin de vie. Que se passerait-il s'il était indisponible pendant deux semaines? Combien de clients pourraient s'auto-exporter? Combien n'ont aucune alternative? Quelle montée en puissance du support serait nécessaire? Que dirait le fournisseur si un ransomware imposait un arrêt immédiat? Si ces réponses sont inconfortables, le retrait 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 de la messagerie hébergée par l'intermédiaire d'intermédiaires ou avec l'aide de fournisseurs de services gérés. 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 plate-forme affectée. Microsoft contrôlait la plate-forme 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 d'affaires 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 avec de 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 sa messagerie mobile. Le courrier archivé peut se charger lentement. Les autorisations de calendrier peuvent se rompre. 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 ransomware 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 publics d'incident de première classe. Les MSP ont besoin de manuels techniques, de l'état de la clientèle en vrac, 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 des partenaires devient un canal de rumeurs. S'il équipe bien les partenaires, l'écosystème des partenaires devient un multiplicateur de récupération.

Les communiqués publics de Rackspace mentionnent Microsoft Fast Track et le personnel de renfort. 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. En cas de panne de messagerie, la partie qui peut modifier le DNS et configurer le tenant de destination peut être plus importante que le propriétaire 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 des données et la stratégie produit.

Les clients étaient responsables de leur propre planification de la 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 ransomware. Cela signifie que le fournisseur détenait les leviers pratiques de la prévention, du confinement, de la restauration et des preuves.

L'incident montre également pourquoi la responsabilité du cloud ne peut pas être mesurée uniquement par la disponibilité après la migration. Un client qui retrouve de nouveaux courriers électroniques 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é intégralement rétabli. La récupération a de multiples états: flux de messagerie, 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 en matière de cyberdéfense, divulgations publiques aux investisseurs, support de migration Microsoft 365, montée en puissance du support, mises à jour de statut et flux de travail de récupération des données. Le dossier public montre également des limites strictes: interruption de service grave, 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 aspects appartiennent à l'évaluation.

La leçon plus large pour tout fournisseur de cloud géré est inconfortable. Si vous exploitez une plate-forme patrimoniale pour les petites entreprises, vous possédez plus que des serveurs. Vous possédez les options de continuité du client lorsque vos serveurs ne peuvent plus être fiables. 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, lots 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 en faveur de contrôles de continuité de base mais souvent négligés. Possédez les identifiants du registrar de domaine et du DNS. Conservez une liste à jour des boîtes aux lettres, alias, groupes de distribution, boîtes aux lettres partagées et administrateurs. Sachez qui peut modifier les enregistrements MX. Maintenez une liste de contacts hors bande pour les employés et les clients critiques. Exportez ou archivez les courriers électroniques critiques conformément aux exigences légales et commerciales. Testez la configuration de la messagerie d'urgence.

Conservez les contrats et les contacts de support des fournisseurs en dehors de la boîte aux lettres affectée. Demandez aux fournisseurs ce qui se passe si leur plate-forme 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 patrimoniaux gérés sans une histoire d'échec crédible. Si un ransomware force l'arrêt, comment les clients obtiennent-ils le flux de messagerie en quelques heures? Comment obtiennent-ils leurs anciens courriers en quelques jours? Comment savent-ils si les données ont été consultées? Comment les clients réglementés satisfont-ils à leurs obligations de notification? Comment les partenaires reçoivent-ils des instructions groupées? Comment la montée en puissance du support est-elle financée et dotée en personnel?

Comment les avoirs de service se rapportent-ils aux obligations réelles de récupération? Quels clients sont encore sur la plate-forme 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 parcs Exchange multi-tenants ou multi-clients. Les conseils qui fonctionnent pour une seule entreprise peuvent ne pas être opérationnellement simples 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 parce que 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-intérêts peuvent avoir du mal avec le préjudice distribué 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.

Rackspace Hosted Exchange est devenu un cas d'école parce qu'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é progressive et limitée. Un produit patrimonial a pris fin. Des poursuites ont suivi. Les dépenses et les 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 conditions ».

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.