DigitalOcean transforme un incident fournisseur d'email marketing en test de responsabilité cloud

Résumé

• DigitalOcean a déclaré en août 2022 qu'un incident de sécurité chez Mailchimp a probablement exposé les adresses email associées à certains clients de DigitalOcean et qu'un très petit nombre de clients de DigitalOcean ont subi des tentatives de compromission de compte par réinitialisation de mot de passe.
• La question de responsabilité n'est pas de savoir si un fournisseur d'email marketing est équivalent à un plan de contrôle cloud. Elle porte sur qui avait le contrôle concret du compte email tiers, de la liste d'emails clients, du canal de réinitialisation de mot de passe, de la notification de risque de phishing, de l'examen des accès fournisseur et des protections d'identité de la console cloud.
• Les données publiques permettent de traiter ce cas comme une exposition d'emails clients et un risque de phishing ciblé, et non comme une compromission avérée de l'infrastructure des clients de DigitalOcean. Cette distinction n'est utile que si le fournisseur peut fournir des preuves aux clients plutôt que de simples assurances.
• La dépendance de DigitalOcean à Mailchimp pour les communications transactionnelles a transformé une relation avec un fournisseur non lié à la production en un problème de confiance de production, car les confirmations de compte, les réinitialisations de mot de passe, les alertes et les notifications aux clients font partie intégrante de la manière dont les utilisateurs du cloud gardent le contrôle.
• Les développeurs, petites entreprises, agences, administrateurs d'infrastructure et services d'abus ont dû distinguer l'exposition d'une liste d'emails d'une compromission des ressources cloud, tout en répondant à des tentatives de phishing ciblé plus crédibles à l'encontre des propriétaires de comptes.

Dossier de preuves et son utilisation

Cet article utilise des documents publics de manière structurée. Le billet de DigitalOcean est considéré comme le compte-rendu principal de ce que la société a dit avoir découvert, de la manière dont elle a caractérisé l'impact sur les clients et de la description qu'elle a faite des tentatives de suivi sur les comptes. La déclaration de Mailchimp est utilisée pour le point de vue du fournisseur sur une attaque plus large ciblant des utilisateurs de crypto-monnaies.

Les reportages des médias spécialisés en sécurité et technologie sont utilisés pour la chronologie, les frictions et les interprétations externes, tout en préservant la distinction entre les informations rapportées et les faits confirmés par l'entreprise. La documentation de DigitalOcean et les pages publiques sur la sécurité sont utilisées pour expliquer les contrôles que les clients et les équipes pouvaient mettre en œuvre après l'exposition. Les documents gouvernementaux et normatifs sont utilisés pour le contexte général du phishing, des identifiants et de la gouvernance.

Pourquoi un incident lié à un email marketing est devenu un incident de compte cloud

L'épisode Mailchimp de DigitalOcean en 2022 est facile à sous-estimer si le lecteur ne regarde que l'étiquette « email marketing ». L'adresse email d'un client du cloud n'est ni un mot de passe racine, ni une clé SSH, ni un jeton API, ni un instantané de base de données. Elle n'est pas non plus inoffensive.

Pour une plateforme cloud, l'adresse email est souvent l'identifiant de connexion, la destination de réinitialisation du mot de passe, le canal pour les alertes de connexion inhabituelle, l'endroit où arrivent les avertissements de facturation et le moyen par lequel les petites équipes apprennent qu'une ressource, un jeton, un droplet, un domaine ou un ticket d'assistance nécessite une attention. Une fois cette adresse exposée avec la connaissance que la personne est un client de DigitalOcean, l'attaquant n'a pas besoin d'une vaste campagne de phishing.

L'attaquant peut tenter de réinitialiser un mot de passe DigitalOcean, imiter les notifications de la plateforme, cibler un administrateur cloud connu ou chercher des seconds facteurs faibles.

C'est pourquoi la question de responsabilité est plus étroite qu'une histoire générale de violation de données et plus large qu'une note de gestion des fournisseurs. DigitalOcean n'a pas déclaré publiquement que la compromission de Mailchimp avait donné à un attaquant l'accès à l'infrastructure de DigitalOcean. Les données publiques appuient une conclusion plus précise: une liste d'emails clients et un canal de communication transactionnel se trouvaient suffisamment près de la sécurité des comptes pour que l'exposition crée un travail concret pour les clients.

Certains clients ont dû évaluer des tentatives de réinitialisation de mot de passe non autorisées. D'autres ont dû distinguer les avis de sécurité légitimes du nouveau risque de phishing. Les équipes ont dû se demander si l'authentification à deux facteurs (2FA) était activée, si les membres de l'équipe disposaient d'une connexion sécurisée, si les jetons API devaient être examinés et si une alerte par email pouvait être fiable pendant la fenêtre de l'incident.

La distinction est importante. Si le cas est décrit à tort comme une compromission avérée des ressources cloud, cela invente des faits et peut pousser les clients vers des mesures correctives inappropriées. S'il est balayé comme un simple problème de liste de diffusion marketing, il ignore la manière dont les comptes cloud sont réellement contrôlés. La position médiane exacte est que l'incident a créé un chemin crédible vers une attaque ciblée de compte, et que le fournisseur avait le devoir de preuve de démontrer que ce chemin n'était pas devenu plus large.

Cette obligation de preuve incombe en partie à DigitalOcean, en partie à Mailchimp et en partie aux clients qui contrôlaient leurs propres mots de passe, facteurs, paramètres d'équipe et jetons API.

L'épisode montre également comment les petits et moyens utilisateurs vivent la sécurité du cloud. De nombreux clients de DigitalOcean sont des développeurs, des agences, des startups, des opérateurs indépendants et des petites entreprises qui s'appuient sur les paramètres par défaut de la plateforme et des notifications claires. Ils ne disposent peut-être pas d'une équipe dédiée à la gestion des identités ou d'un bureau d'évaluation des risques fournisseurs. Une suspension confuse du fournisseur, une confirmation tardive ou un avis ambigu de réinitialisation de mot de passe peut entraîner un travail disproportionné.

La norme de responsabilité devrait donc demander ce qu'un utilisateur concret pourrait comprendre et faire, et pas seulement ce qu'une entreprise mature pourrait déduire après avoir lu un post-mortem.

Ce que DigitalOcean a dit qu'il s'était passé

Le compte-rendu public de DigitalOcean commence par la livraison des emails. Le 8 août 2022 à 15 h 30, heure de l'Est, a déclaré la société, les emails transactionnels de la plateforme DigitalOcean distribués via Mailchimp ont cessé d'arriver dans les boîtes de réception des clients. Les exemples n'étaient pas de simples campagnes promotionnelles. Ils comprenaient des confirmations de compte, des réinitialisations de mot de passe, des messages d'alerte et des emails liés aux produits.

DigitalOcean a déclaré avoir découvert le problème lors d'un contrôle technique de l'état des inscriptions et avoir constaté que son compte Mailchimp avait été suspendu sans accès et sans détail utile de la part du fournisseur à ce moment-là.

Ce point de départ est important car il s'agissait à la fois d'une interruption de service et d'un signal de sécurité. Si les emails de réinitialisation de mot de passe n'arrivent pas, les clients peuvent perdre l'accès ou être incapables de terminer la récupération. Si les emails de confirmation de compte n'arrivent pas, les nouveaux utilisateurs peuvent ne pas être en mesure de commencer un service normal. Si les alertes n'arrivent pas, les clients peuvent manquer des signaux de compte ou de ressource. Le chemin de communication n'est pas le plan de calcul, mais il aide les clients à gouverner le plan de calcul.

Pour un fournisseur cloud, le système de messagerie utilisé pour les événements de compte fait partie du chemin de confiance.

DigitalOcean a ensuite décrit un second signal. La société a déclaré que l'équipe de sécurité d'un client l'avait informée que le mot de passe du client avait été réinitialisé sans action de sa part. DigitalOcean a indiqué avoir enquêté et constaté qu'un très petit nombre de clients avait subi des tentatives de compromission par réinitialisation de mot de passe. Le compte-rendu public précise que certaines tentatives n'ont pas abouti et que, lorsque les réinitialisations de mot de passe ont réussi, l'authentification à deux facteurs a bloqué l'accès au compte dans certains cas.

C'est la ligne entre l'exposition et la compromission dans ce dossier: les adresses email et les tentatives de réinitialisation sont des faits publics dans le compte-rendu de DigitalOcean; une compromission généralisée de l'infrastructure des clients n'est pas établie par les données publiques.

La notification officielle de Mailchimp est arrivée plus tard, selon DigitalOcean. DigitalOcean a déclaré que Mailchimp l'avait officiellement informé le 10 août de l'accès non autorisé à son compte et à d'autres par un attaquant qui, selon DigitalOcean, avait compromis les outils de Mailchimp utilisés pour le support client ou l'administration des comptes. DigitalOcean avait déjà commencé à déplacer les services critiques hors de Mailchimp. Ce calendrier est important car il montre pourquoi la communication avec le fournisseur est elle-même un contrôle.

Un fournisseur ne peut pas attendre passivement l'explication d'un fournisseur lorsque les flux de mots de passe des clients et les avis de sécurité sont affectés. Il doit préserver la confiance des clients alors que les faits sont encore incomplets.

Ce que Mailchimp a dit, et pourquoi le cadre côté fournisseur est incomplet pour les clients du cloud

La déclaration de Mailchimp a décrit une attaque ciblant les utilisateurs de crypto-monnaies et a indiqué que la société avait temporairement suspendu l'accès aux comptes où une activité suspecte avait été détectée pendant qu'elle enquêtait. Elle a évoqué des tactiques sophistiquées de phishing et d'ingénierie sociale et a déclaré avoir notifié les contacts principaux concernés tout en ajoutant des mesures de sécurité renforcées. Cette déclaration est pertinente car elle fournit le contexte plus large du côté du fournisseur.

Elle est également incomplète pour une décision de client cloud, car les clients de DigitalOcean n'avaient pas seulement besoin de savoir que Mailchimp avait subi un incident plus large lié aux crypto-monnaies. Ils avaient besoin de savoir si le risque pour leur compte DigitalOcean avait changé.

Il n'y a pas de contradiction à utiliser les deux comptes-rendus de cette manière. Mailchimp pouvait décrire l'attaque de la plateforme fournisseur telle qu'il la voyait. DigitalOcean devait traduire cet événement fournisseur en conséquences pour les comptes clients. Ce sont des devoirs différents. Un fournisseur d'automatisation du marketing peut penser en termes de comptes clients sur sa propre plateforme, de données de campagne, d'outils de support et d'accès suspect aux audiences des emails.

Un fournisseur cloud doit penser en termes de récupération de compte, d'authentification à deux facteurs, de connexion à la console, de modifications de ressources, de jetons API, d'appartenance à une équipe, de facturation, de support et de rapports d'abus. La même adresse email exposée signifie des choses différentes selon le système qu'elle peut aider à déverrouiller.

Le cadre côté fournisseur montre également pourquoi les outils tiers ne peuvent pas être jugés uniquement par les étiquettes de classification des données. Une liste d'emails clients peut se trouver en dehors du plan de contrôle de production d'un fournisseur cloud, mais elle reste sensible sur le plan de la sécurité car elle identifie des cibles. Les attaquants ont souvent besoin d'une liste de cibles fiable avant d'avoir besoin d'identifiants.

Une fois qu'ils savent quelles adresses appartiennent à des administrateurs cloud, ils peuvent élaborer des tentatives de réinitialisation de mot de passe, de faux avis de suspension, des avertissements de facturation, des plaintes pour abus ou des leurres de rotation de jetons. Une relation fournisseur qui stocke l'audience des notifications transactionnelles devient donc une partie de la surface de défense des comptes.

La déclaration de Mailchimp elle-même n'a pas établi tous les effets en aval sur les utilisateurs de DigitalOcean. La déclaration de DigitalOcean n'a pas établi tous les détails privés sur l'environnement de Mailchimp. Une lecture sérieuse de la responsabilité ne comble pas ces lacunes par des spéculations.

Elle demande quelle partie était en mesure de savoir quoi: Mailchimp contrôlait les journaux d'accès du fournisseur et les preuves des outils de support; DigitalOcean contrôlait sa propre télémétrie de sécurité des comptes et les notifications aux clients; les clients contrôlaient leurs facteurs, mots de passe, appartenance à une équipe et journaux de ressources. Les preuves devaient traverser ces frontières assez rapidement pour soutenir l'action.

Les listes d'emails clients sont des actifs de sécurité lorsqu'elles identifient des administrateurs cloud

L'objet exposé dans le compte-rendu public de DigitalOcean était une adresse email associée à un client. Cela peut sembler modeste à côté de catégories de violation plus sensibles. Mais dans les opérations cloud, une adresse email d'administrateur peut suffire à rendre un attaquant plus efficace. Elle réduit le coût du ciblage. Elle soutient des prétextes convaincants. Elle indique à l'attaquant quelle plateforme imiter.

Elle peut identifier des clients disposant de droplets, de bases de données, de stockage d'objets, de domaines, de clusters Kubernetes ou de relations de facturation qui peuvent être abusés ou extorqués si l'accès au compte est obtenu.

Le point économique est simple: une liste d'adresses modifie le coût unitaire de l'attaquant. Une vaste campagne de phishing doit deviner qui utilise quel cloud. Une liste de clients cloud permet à l'attaquant d'éviter ces conjectures. L'attaquant peut envoyer des messages spécifiques à la plateforme, déclencher des réinitialisations de mot de passe lorsque cela est possible ou combiner l'adresse exposée avec d'autres matériaux d'identification provenant de violations non liées. La liste exposée n'a pas besoin d'inclure des mots de passe pour augmenter le risque.

Elle peut transformer une menace générique en une pression ciblée sur les comptes.

C'est particulièrement pertinent pour les petits opérateurs. Une petite agence peut héberger des sites clients. Un développeur peut détenir des identifiants pour des ressources de production de plusieurs clients. Un fondateur de startup peut utiliser une seule adresse email pour la facturation, la récupération de compte, les clés API, les alertes de domaine et le support. Un administrateur solo peut compter sur l'email comme principal canal de notification. La posture de sécurité du titulaire du compte peut être inégale.

Certains disposeront d'une 2FA basée sur une application, d'une connexion sécurisée d'équipe, de contacts de facturation distincts et d'une bonne journalisation. D'autres peuvent avoir un seul mot de passe, un compte email réutilisé, une ancienne appartenance à une équipe et des jetons d'accès personnels qui n'ont pas été examinés depuis des années.

La documentation de DigitalOcean sur la 2FA et la connexion d'équipe montre le type de contrôles qui font la différence après une exposition. Les seconds facteurs peuvent bloquer l'accès après une réinitialisation du mot de passe. Les exigences de connexion sécurisée pour les équipes peuvent relever le niveau pour chaque membre. L'historique de sécurité peut aider les propriétaires à examiner les actions du compte telles que les modifications de ressources ou de jetons. Les contrôles des jetons API et OAuth sont importants car l'accès au compte n'est pas le seul chemin vers le contrôle du cloud.

Si un attaquant obtient ou abuse d'un accès délégué, les dégâts peuvent ne pas ressembler à une connexion console ordinaire.

La conclusion en matière de responsabilité n'est donc pas que tous les clients de DigitalOcean ont été compromis. La conclusion est que la liste exposée était un actif de sécurité, car elle associait des personnes à une surface de compte cloud. Cet actif aurait dû être gouverné, surveillé et couvert par un examen des accès fournisseur en conséquence.

L'email transactionnel fait partie du chemin de récupération

Les exemples de types d'emails affectés fournis par DigitalOcean sont cruciaux. Les confirmations de compte, les réinitialisations de mot de passe, les alertes et les avis de produits se situent à la frontière entre la communication et le contrôle. Ce ne sont pas des identifiants d'infrastructure, mais ils aident les utilisateurs à récupérer des identifiants, à reconnaître un changement de compte et à maintenir une conscience des ressources. Si ce chemin échoue, les clients peuvent être bloqués, induits en erreur ou retardés.

Si ce chemin est abusé, les clients peuvent être poussés vers des flux de récupération malveillants ou de fausses actions de compte.

Pour les fournisseurs de cloud, la résilience de l'email transactionnel est donc un problème de continuité. Les clients ont besoin de recevoir des messages légitimes, et ils ont besoin que ces messages puissent être distingués des messages malveillants. Lorsqu'un fournisseur passe d'un fournisseur de messagerie à un autre pendant un incident, il doit prendre en compte l'authentification, la délivrabilité, la confusion des clients, la réputation de l'expéditeur et le calendrier. Un avis légitime du fournisseur qui semble différent des avis précédents peut lui-même créer une incertitude de phishing.

Cela ne signifie pas qu'un fournisseur doit préserver une relation risquée avec un fournisseur. Cela signifie que la migration et la conception des avis font partie de la réponse aux incidents.

C'est là que le cas devient un test de responsabilité plutôt qu'un simple ticket fournisseur. DigitalOcean a déclaré avoir déplacé les services critiques hors de Mailchimp avant l'accusé de réception formel de Mailchimp. Cela ressemble à une étape de confinement sensée dans les données publiques. Mais les clients avaient encore besoin de savoir ce qui avait changé. Si les emails de réinitialisation de mot de passe provenaient d'un nouveau fournisseur, les clients devaient distinguer les messages légitimes de récupération des messages de l'attaquant. Si les alertes avaient été retardées, les clients devaient savoir quelle période examiner.

Si un client n'a pas reçu d'avis, il devait savoir si cela signifiait aucune exposition ou simplement aucune communication ciblée.

Le meilleur dossier de preuves répondrait à ces questions pratiques. Il définirait la plage de dates de la livraison d'emails affectée, les groupes de clients dont les adresses ont pu être exposées, les catégories de messages transactionnels affectés, les tentatives de réinitialisation de mot de passe observées par DigitalOcean, les mesures prises pour les clients ayant fait l'objet de tentatives de compromission de compte et les contrôles de sécurité des comptes que les clients devraient vérifier. Le billet public de DigitalOcean couvre une grande partie de ce cadre à un niveau élevé.

La question de responsabilité restante est de savoir si les avis spécifiques aux clients ont donné suffisamment de détails pour une action proportionnée.

L'email transactionnel est également une dépendance que les conseils d'administration négligent souvent. Il n'est pas aussi visible que la capacité de calcul, la durabilité du stockage ou la disponibilité du réseau. Pourtant, lorsque la récupération de compte et les alertes en dépendent, il devient un élément de la continuité de service. Un incident fournisseur dans cette couche peut affecter l'accès des utilisateurs, la confiance dans les avis et la capacité de l'équipe anti-abus à communiquer avec les parties concernées.

Les tentatives de réinitialisation de mot de passe ont transformé l'exposition en travail de réponse

L'élément de réinitialisation de mot de passe est ce qui a rendu l'incident opérationnellement grave. Si une liste d'emails clients est exposée et qu'aucun flux de compte n'est touché, la réponse appropriée peut être une alerte, une mise en garde contre le phishing et un examen du fournisseur. Si les attaquants tentent des réinitialisations de mot de passe, la réponse doit inclure des preuves compte par compte. DigitalOcean a déclaré qu'un très petit nombre de clients avait subi des tentatives de compromission par réinitialisation de mot de passe. Cette phrase doit être lue attentivement.

Ce n'est pas une affirmation selon laquelle une population importante a perdu le contrôle de son compte. C'est une affirmation selon laquelle les informations exposées ont été utilisées de manière plausible dans des tentatives d'accès au compte.

Pour les clients concernés, les preuves nécessaires sont spécifiques. Un email de réinitialisation a-t-il été demandé? Le mot de passe a-t-il été modifié? Le compte a-t-il été consulté après la réinitialisation? La 2FA était-elle présente? Des droplets, bases de données, domaines, membres d'équipe, clés SSH, applications OAuth, jetons API, informations de facturation ou tickets d'assistance ont-ils été modifiés? L'activité provenait-elle d'une source unique ou multiple? DigitalOcean a-t-il forcé les réinitialisations ou révoqué les sessions pour ces clients?

A-t-il conservé des preuves pour les clients qui avaient besoin de leurs propres dossiers d'incident?

La déclaration publique de DigitalOcean indique que son équipe d'intervention a sécurisé les comptes et communiqué séparément avec ces clients. C'est la bonne distinction: un avis d'exposition large pour la population de la liste d'emails, une communication séparée pour la population des tentatives de compte. Un seul avis ne peut pas bien servir les deux groupes. Un client dont l'adresse email a été exposée a besoin d'une liste d'actions différente de celle d'un client dont le mot de passe a effectivement été réinitialisé. Le premier doit renforcer et surveiller.

Le second doit traiter le compte comme un incident actif jusqu'à ce que les preuves disent le contraire.

Les seconds facteurs sont ici essentiels. Les reportages publics ont noté que dans certains cas, l'authentification à deux facteurs a empêché l'accès après une réinitialisation du mot de passe. C'est la leçon de sécurité la plus claire du dossier, mais elle ne doit pas devenir un slogan. La 2FA ne réduit le risque que si elle est activée par les utilisateurs concernés, si les chemins de secours ne sont pas faibles, si le compte email est sécurisé, si les membres de l'équipe sont couverts et si les jetons API ou les autorisations OAuth ne contournent pas le chemin de connexion de l'utilisateur.

Le contrôle est puissant, mais il s'inscrit dans un système de gouvernance de compte plus large.

Le prisme de la responsabilité demande également ce que DigitalOcean pouvait contrôler avant l'incident. Il pouvait exiger ou fortement encourager la 2FA pour les comptes à risque plus élevé, faciliter la connexion sécurisée des équipes, fournir un examen de l'historique de sécurité, limiter la portée des jetons et concevoir des flux de réinitialisation de mot de passe résistant aux activités suspectes. Les clients contrôlaient l'utilisation ou non de ces contrôles. Mailchimp contrôlait la plateforme du fournisseur qui a exposé les adresses. La responsabilité est distribuée, mais pas vague.

L'examen de l'accès des fournisseurs est un contrôle du fournisseur cloud, pas une formalité d'achat

Le billet de DigitalOcean décrivait Mailchimp comme le fournisseur utilisé pour les emails transactionnels de la plateforme. Une fois que cette relation a affecté les confirmations de compte, les réinitialisations de mot de passe, les alertes et les avis de produits, l'examen du fournisseur devait couvrir les conséquences de sécurité, pas seulement la délivrabilité et la fonction marketing. Les questions pertinentes sont concrètes. Quelles données des clients de DigitalOcean étaient présentes dans Mailchimp? Quels employés, sous-traitants, systèmes et outils de support de Mailchimp pouvaient y accéder?

Quelle authentification et quelle approbation protégeaient cet accès? Quelles alertes DigitalOcean recevrait-il si son compte était consulté, exporté, suspendu ou modifié? Quel délai de notification contractuel s'appliquait? À quelle vitesse DigitalOcean pouvait-il migrer les messages critiques vers un autre fournisseur?

Les données publiques suggèrent une difficulté sur au moins l'une de ces questions. DigitalOcean a déclaré avoir initialement trouvé son compte Mailchimp suspendu sans accès et sans explication utile. Cela a laissé le fournisseur cloud enquêter sur l'impact sur les clients alors que le compte du fournisseur était indisponible. La suspension du compte fournisseur peut être une mesure défensive du point de vue de Mailchimp, mais pour DigitalOcean, elle a également interrompu les communications critiques et retardé la clarté.

Une conception de contrôle fournisseur doit gérer les deux: arrêter l'accès de l'attaquant et donner au client suffisamment d'informations pour protéger les utilisateurs en aval.

L'examen de l'accès des fournisseurs devrait également considérer les outils de support/administration comme à haut risque. Si un fournisseur dispose d'outils permettant de visualiser ou d'exporter des audiences, de suspendre des comptes ou de modifier les communications des clients, ces outils ne sont pas des commodités de back-office. Ce sont des systèmes privilégiés. Il en va de même pour les propres outils de support d'un fournisseur cloud. Les attaquants ciblent les chemins de support et d'administration des comptes parce que ces chemins peuvent contourner les identifiants ordinaires des clients ou exposer des données de ciblage.

Un fournisseur cloud qui s'appuie sur la couche de support/administration d'un fournisseur hérite d'une partie de ce risque.

Le déménagement de DigitalOcean hors de Mailchimp pour les services critiques était donc plus qu'un simple changement de fournisseur. C'était une décision de contrôle concernant la frontière entre les systèmes de communication et la confiance des comptes clients. Les données publiques ne nous disent pas toute l'architecture de remplacement. Elles montrent cependant le principe de responsabilité: un service de messagerie tiers utilisé pour des messages liés à la sécurité a besoin d'attentes en matière d'avis d'incident, de journalisation des accès, de contrôle des exportations et de migration qui correspondent à son rôle.

Ce n'est pas une demande pour que chaque fournisseur cloud construise lui-même chaque outil. Les fournisseurs de messagerie tiers peuvent être fiables, spécialisés et appropriés. L'exigence est de classer honnêtement la dépendance. Si un fournisseur touche aux réinitialisations de mot de passe et aux alertes de sécurité, il doit être gouverné comme faisant partie du système de sécurité des comptes.

Le risque de phishing est une charge de travail, pas seulement un slogan de sensibilisation

Le guide de phishing de la CISA et la technique de phishing de MITRE décrivent tous deux pourquoi les emails ciblés sont importants sur le plan opérationnel. Le phishing n'est pas seulement un message; c'est une séquence. Les attaquants identifient des cibles, élaborent un leurre plausible, l'envoient par un canal auquel la cible fait confiance et tentent d'obtenir des identifiants, des jetons, des approbations ou des actions. Les clients de DigitalOcean dont les adresses email ont été exposées n'ont pas tous été confrontés au même risque. Mais chaque adresse exposée a facilité un leurre spécifique à la plateforme.

La charge de travail immédiate pour le client était de faire confiance avec prudence. Un client pouvait recevoir des avis légitimes de DigitalOcean, des messages de réinitialisation de mot de passe générés par l'attaquant ou de fausses alertes de la plateforme.

Il pouvait avoir besoin de vérifier les URL manuellement, d'éviter les liens dans les messages non sollicités, de naviguer directement vers le panneau de contrôle, d'examiner l'historique de sécurité, d'activer la 2FA, d'exiger une connexion sécurisée pour l'équipe, de vérifier les jetons API et de contrôler si des tickets d'assistance ou des modifications de ressources avaient eu lieu. C'est du temps pris sur la gestion de l'infrastructure.

Le travail incombe également aux canaux d'abus et de support. Si les attaquants utilisaient des leurres à l'effigie de DigitalOcean ou hébergeaient une infrastructure de phishing sur des ressources cloud, les victimes ou les tiers signaleraient des abus. La page de signalement d'abus de DigitalOcean existe pour ce type de réception. L'économie des contacts d'abus est importante car les grandes plateformes reçoivent de nombreuses plaintes, qui ne sont pas toutes de qualité égale. Après l'exposition d'une liste de clients, le triage devrait pouvoir distinguer les signalements de phishing de routine des tentatives liées à l'incident.

De bons chemins de signalement, une capture rapide des preuves et une escalade spécifique au client peuvent réduire le coût de la confusion.

Le risque de phishing crée également un paradoxe de communication. Les clients ont besoin d'un avertissement, mais les avertissements eux-mêmes arrivent par email, le canal même que les attaquants peuvent imiter. Cela signifie que les avis du fournisseur doivent éviter les liens inutiles, indiquer clairement les actions requises, orienter les utilisateurs vers une connexion via des signets connus ou des URL saisies, et expliquer ce que DigitalOcean ne demandera jamais. Le billet public peut faire une partie de ce travail, mais les avis individuels et les interactions d'assistance portent l'essentiel du fardeau pratique.

Le point de responsabilité n'est pas que chaque tentative de phishing après août 2022 était de la responsabilité de DigitalOcean. C'est qu'un fournisseur ayant connaissance d'une exposition ciblée de liste de clients a le devoir de faciliter l'action du client et de rendre la tromperie de l'attaquant plus difficile. Ce devoir inclut le contenu, le calendrier, l'identité de l'expéditeur, la préparation du support et les preuves de contrôle du compte.

Ce que les clients contrôlaient après l'avis

Les clients n'étaient pas passifs dans ce dossier. Ils contrôlaient si leurs propres comptes DigitalOcean disposaient de la 2FA, si la connexion sécurisée de l'équipe était exigée, si l'appartenance à l'équipe était à jour, si les jetons API étaient délimités et examinés, si les autorisations OAuth étaient fiables, si les comptes email étaient protégés et si les journaux de modification des ressources étaient surveillés. Un fournisseur cloud peut offrir des contrôles, mais beaucoup de contrôles nécessitent l'adoption par les clients.

Cette responsabilité partagée ne doit pas être utilisée comme un bouclier par le fournisseur. Elle doit être utilisée comme une carte. DigitalOcean contrôlait les contrôles de la plateforme et les preuves de l'incident. Les clients contrôlaient la configuration et le suivi. Mailchimp contrôlait l'environnement du fournisseur qui a exposé les données. Une bonne réponse aux incidents aide chaque partie à faire la part que seule elle peut faire.

Le fournisseur peut dire: voici la catégorie d'exposition, voici la fenêtre temporelle, voici si votre compte a fait l'objet d'une tentative de réinitialisation de mot de passe, voici les contrôles à vérifier, voici les mesures que nous avons déjà prises. Le client peut alors agir sans conjectures.

Pour les équipes, la documentation sur la connexion sécurisée est particulièrement pertinente. Un seul compte propriétaire bien protégé ne suffit pas si d'autres membres de l'équipe peuvent accéder aux ressources avec une connexion plus faible. Un client doit examiner les membres de l'équipe, les rôles, les méthodes de connexion et l'historique de sécurité récent. Si un sous-traitant ou un ancien employé a encore accès, un attaquant qui sait que l'équipe utilise DigitalOcean peut cibler le membre le plus faible plutôt que le propriétaire.

La sécurité de l'équipe transforme une exposition de liste d'emails en un contrôle d'hygiène des appartenances.

Les jetons API méritent une attention distincte. Une réinitialisation de mot de passe peut ne pas révéler un jeton API, mais si un attaquant obtient l'accès au compte, les jetons et les applications déléguées peuvent devenir des chemins de contrôle durables. Les clients doivent examiner les noms, les portées, les dates de création et la dernière utilisation des jetons, si elle est disponible, et vérifier si l'automatisation peut être réémise avec des autorisations plus étroites. Les autorisations OAuth peuvent soulever des questions similaires.

L'événement de connexion au compte n'est qu'une porte d'entrée; l'automatisation de la plateforme peut avoir un pouvoir plus durable.

Les clients contrôlaient également la sécurité de leur propre compte email. Si la même adresse email utilisée pour DigitalOcean est mal protégée, les chemins de réinitialisation de mot de passe deviennent plus dangereux. La documentation 2FA de DigitalOcean explique que les codes de connexion pour un nouvel emplacement envoyés par email sont moins protecteurs qu'une 2FA complète. Cela est important dans ce cas car l'objet exposé était l'adresse email elle-même. Plus le compte email et le second facteur sont solides, moins l'adresse exposée a de valeur.

Ce que DigitalOcean contrôlait après l'avis

DigitalOcean contrôlait la réponse de la plateforme. Cela comprenait l'enquête sur les tentatives de réinitialisation de mot de passe, la sécurisation des comptes concernés, la communication avec les clients, le changement de la livraison des emails critiques hors de Mailchimp et l'explication de ce qui était connu. Il contrôlait également les fonctionnalités de défense des comptes, la visibilité de l'historique de sécurité, la documentation des jetons API, les contrôles de connexion de l'équipe et la réception des abus.

Ces contrôles ne sont pas tous spécifiques à l'incident, mais ils déterminent si l'incident pouvait être contenu avec des preuves.

Le devoir le plus important du fournisseur était le cadrage. Les clients devaient savoir s'ils faisaient partie du groupe large d'exposition des emails, du groupe restreint des tentatives de réinitialisation de mot de passe, ou d'aucun des deux. Chaque catégorie nécessitait une action différente. Des avertissements trop larges peuvent créer de la panique et une lassitude des alertes. Des avis trop étroits peuvent laisser les clients exposés.

Le billet public de DigitalOcean a indiqué que des notifications plus larges étaient envoyées aux clients concernés par l'exposition des emails et qu'une communication séparée était adressée aux clients impliqués dans les tentatives liées aux mots de passe. C'est la bonne structure si les données sous-jacentes étaient exactes et opportunes.

DigitalOcean contrôlait également les preuves qui pouvaient séparer l'attaque de compte de la compromission de l'infrastructure. Il pouvait examiner les enregistrements de connexion, l'activité de réinitialisation de mot de passe, les défis 2FA, les changements de session, la création de jetons, les changements d'appartenance à l'équipe, les actions sur les ressources, les événements de facturation, l'activité des tickets d'assistance et les adresses IP suspectes. Les clients ne pouvaient pas reconstituer tout cela de l'extérieur.

Ils pouvaient examiner leur propre côté, mais les journaux du fournisseur sont décisifs pour le cadrage au niveau de la plateforme. L'expression « nous avons sécurisé ces comptes » n'a de sens que si elle est étayée par un tel examen.

Un autre devoir du fournisseur était la restauration de la confiance. Le déménagement hors de Mailchimp pour les services critiques peut réduire le risque immédiat lié au fournisseur, mais les clients ont également besoin d'avoir confiance dans les communications futures. Cela peut nécessiter de publier des informations claires sur l'expéditeur, de réduire la dépendance aux liens dans les avis de sécurité, d'améliorer les conditions contractuelles de notification des fournisseurs et de tester les chemins de communication de secours.

Un fournisseur doit savoir comment il communiquera les événements de sécurité des comptes si son fournisseur de messagerie habituel est indisponible ou non fiable.

Enfin, DigitalOcean contrôlait les leçons qui devenaient durables. Une réponse ponctuelle à un incident a moins de valeur que des changements dans la classification des fournisseurs, la surveillance, la conception des avis aux clients et les paramètres de sécurité des comptes par défaut. Les données publiques ne révèlent pas tous les changements ultérieurs. Le test de responsabilité est de savoir si l'événement a changé la manière dont la plateforme traite les fournisseurs de communication qui touchent aux flux de travail de sécurité des clients.

Ce que Mailchimp contrôlait

Mailchimp contrôlait l'environnement du fournisseur sur lequel DigitalOcean s'appuyait. Cela comprenait l'accès au compte Mailchimp, la détection d'activité suspecte, les outils de support client ou d'administration de compte, la suspension du compte, la notification aux clients concernés et les preuves nécessaires pour déterminer quelles audiences de clients avaient été exposées.

Du point de vue de DigitalOcean, la suspension initiale du compte par Mailchimp sans explication claire a créé un problème pratique: les messages critiques des clients se sont arrêtés et le fournisseur cloud a dû enquêter tout en étant coupé du compte du fournisseur.

Le devoir du fournisseur ici n'est pas simplement d'empêcher toute attaque. C'est de concevoir des outils privilégiés et la communication avec les clients de manière à ce qu'un incident fournisseur ne devienne pas un angle mort pour les organisations en aval. Si un fournisseur désactive le compte d'un client pour des raisons défensives, il devrait pouvoir fournir un chemin sécurisé pour les informations sur l'incident. Si les données du compte ont pu être consultées, il devrait fournir la portée, la fenêtre temporelle, les catégories de données affectées et les actions recommandées pour les clients.

Si les outils de support client ou d'administration de compte sont impliqués, il devrait traiter ces outils comme des systèmes privilégiés nécessitant une authentification forte, une surveillance et des contrôles d'exportation.

La déclaration publique de Mailchimp a indiqué que l'attaque ciblait les utilisateurs de crypto-monnaies et que les contacts concernés avaient été notifiés. Le compte-rendu de DigitalOcean montre pourquoi cela peut ne pas être suffisant en aval. Un client de la plateforme dont les utilisateurs du cloud peuvent être ciblés a besoin de preuves plus granulaires qu'un billet général du fournisseur ne peut en fournir. Le fournisseur doit soutenir les propres devoirs de notification du client envers ses propres clients.

Cela signifie que la réponse aux incidents du fournisseur doit tenir compte des effets de second ordre: un client de Mailchimp peut avoir ses propres utilisateurs, des flux de récupération de compte et des obligations réglementaires.

Le cas illustre également un problème de concentration des fournisseurs pour les services de communication. De nombreuses entreprises utilisent une seule plateforme pour le courrier marketing, le courrier produit, les alertes et les flux de compte parce que c'est efficace. Cette efficacité peut estomper la criticité. Si le même compte fournisseur stocke les audiences et envoie des messages liés à la sécurité, une compromission du fournisseur peut à la fois exposer des cibles et perturber le canal utilisé pour les avertir.

La séparation des flux transactionnels à haut risque, l'utilisation de contrôles d'accès fournisseur plus stricts et le maintien de chemins de notification alternatifs peuvent réduire ce couplage.

Mailchimp n'était pas le fournisseur cloud. Il ne contrôlait pas la sécurité de la console DigitalOcean. Mais il contrôlait un système qui touchait les clients de DigitalOcean à la périphérie du compte. Cela suffit à créer un devoir de preuve partagé.

L'économie des contacts d'abus et le coût caché des listes ciblées

Le sujet manifeste « L'économie des contacts d'abus » convient à ce cas car les emails exposés des clients du cloud peuvent augmenter la charge sur les canaux de signalement. Lorsque les attaquants savent quels utilisateurs appartiennent à une plateforme cloud, ils peuvent élaborer de meilleurs leurres. Certains leurres peuvent être envoyés depuis une infrastructure compromise. Certains peuvent usurper l'identité du fournisseur cloud. Certains peuvent déclencher des plaintes de victimes, de fournisseurs de protection de marque ou d'autres fournisseurs.

Les équipes anti-abus doivent décider quels signalements sont exploitables, lesquels sont des doublons, lesquels impliquent du contenu hébergé et lesquels sont des signalements de sécurité de compte mal orientés vers la réception des abus.

Le chemin de signalement d'abus public de DigitalOcean est conçu pour les activités malveillantes impliquant la plateforme, telles que le phishing ou d'autres contenus nuisibles hébergés sur les ressources de DigitalOcean. Après un incident fournisseur qui expose les adresses des clients, la fonction anti-abus a un rôle connexe mais distinct. Elle peut recevoir des signalements de pages de phishing à l'effigie de DigitalOcean, de droplets malveillants ou de faux avis.

Elle peut également avoir besoin de se coordonner avec les équipes de sécurité des comptes lorsqu'un signalement inclut une cible cliente de DigitalOcean plutôt qu'une source hébergée par DigitalOcean. Plus les catégories de réception sont claires, moins il y a de frictions pour les déclarants et les intervenants.

Le coût d'un mauvais triage des abus est réel. Si les signalements sont ignorés ou retardés, l'infrastructure de phishing peut rester active plus longtemps. Si les signalements sont trop larges, des clients légitimes peuvent être interrompus. Si les victimes ne savent pas où signaler, les signaux se dispersent entre les tickets d'assistance, les médias sociaux, les contacts des bureaux d'enregistrement et les canaux d'application de la loi. Une exposition ciblée de liste de clients augmente la valeur d'une réception rapide et précise car les attaquants peuvent se concentrer sur une population connue.

Les fournisseurs cloud doivent également se prémunir contre le problème inverse: les attaquants peuvent utiliser de fausses plaintes pour abus comme leurres. Un client qui reçoit un message urgent affirmant que son droplet héberge du contenu de phishing peut cliquer sur un faux lien ou saisir ses identifiants dans un portail contrefait. Après cet incident, les clients de DigitalOcean avaient une raison rationnelle de se méfier de tout email invoquant une suspension, un abus, une facturation ou une réinitialisation de mot de passe.

Cette prudence est saine, mais elle crée plus de travail de support si les avis légitimes ne sont pas faciles à vérifier.

L'économie des contacts d'abus n'est donc pas une question secondaire. Elle fait partie de la restauration de la confiance. Le fournisseur a besoin de canaux de signalement qui fonctionnent en cas d'attaque, d'avis qui réduisent la tromperie et de contrôles de compte qui aident les clients à vérifier ce qui s'est réellement passé.

Les preuves qui sépareraient l'exposition d'emails de la compromission des ressources cloud

Les preuves les plus précieuses dans ce cas ne seraient pas une divulgation technique spectaculaire. Ce serait une carte des limites claire. Pour chaque catégorie de clients affectés, DigitalOcean pourrait montrer si l'email du client a été exposé, si une réinitialisation de mot de passe a été demandée, si une réinitialisation a réussi, si une session a été établie, si la 2FA a bloqué l'accès, si un changement d'équipe, de jeton, d'OAuth, de facturation, de support ou de ressource a suivi, et quelles mesures correctives ont été achevées. Tout cela ne relève pas d'un billet de blog public.

Une grande partie relève des avis spécifiques aux clients et des dossiers d'incident conservés.

La même carte devrait exister pour le côté fournisseur. Mailchimp devrait pouvoir dire quelles données du compte DigitalOcean ont été consultées, par quel type d'outil, dans quelle fenêtre temporelle, selon quel modèle d'accès non autorisé, et si une exportation d'audience ou une modification de campagne a eu lieu. Les déclarations publiques peuvent résumer des détails sensibles, mais les clients en aval ont besoin d'une spécificité suffisante pour agir. Sans preuves du côté du fournisseur, DigitalOcean doit déduire à partir de sa propre télémétrie de compte et des signalements des clients.

La norme de preuve devrait également inclure la preuve négative. Dire qu'il n'y a aucune preuve de compromission de l'infrastructure est plus solide lorsque le fournisseur explique quelles preuves ont été examinées. Les enregistrements de connexion, les journaux de réinitialisation de mot de passe, les défis 2FA échoués, la création de jetons, les modifications de ressources et les événements de l'historique de sécurité peuvent étayer cette conclusion. Les données publiques permettent une conclusion à haute confiance que cela n'a pas été publiquement établi comme une compromission généralisée de l'infrastructure.

Elles ne permettent pas à un observateur extérieur d'inspecter tous les journaux privés. Nommer cette limite protège le lecteur d'une fausse certitude.

Les clients devraient utiliser la même logique de preuve. Ils ne devraient pas supposer une compromission uniquement parce qu'une adresse email a été exposée. Ils ne devraient pas supposer la sécurité uniquement parce qu'aucune ressource n'est visiblement brisée. Ils devraient vérifier l'historique de sécurité du compte, l'appartenance à l'équipe, les jetons, les autorisations OAuth, les contacts de facturation, les paramètres de domaine, les clés SSH, les tickets d'assistance et les journaux d'infrastructure pour la fenêtre pertinente. Si rien n'a changé et que la 2FA était présente, la réponse peut être proportionnée.

Si une réinitialisation a réussi ou si un jeton a changé, la réponse doit s'intensifier.

C'est là que le langage des normes aide. Les fonctions identifier, protéger, détecter, répondre et récupérer du NIST ne sont pas des étiquettes décoratives. Elles décrivent la chaîne de preuves: connaître les actifs et les tiers qui comptent; protéger les comptes et les chemins de communication; détecter les activités de réinitialisation et de connexion suspectes; répondre par des avis cadrés et un confinement; récupérer la confiance dans la communication et les contrôles des comptes. Les contrôles CIS donnent des classes pratiques similaires autour de l'inventaire, des comptes, des accès et des journaux.

Le cas DigitalOcean-Mailchimp est un petit incident uniquement si ces classes fonctionnent.

Questions de gouvernance pour les fournisseurs cloud et les acheteurs

Pour un fournisseur cloud, la question au niveau du conseil d'administration est de savoir si les fournisseurs de communication sont classés en fonction de l'impact sur le contrôle du client. Si un fournisseur envoie ou stocke des confirmations de compte, des réinitialisations de mot de passe, des alertes de sécurité, des avis de produits ou des messages d'abus, il ne devrait pas être examiné comme une infrastructure marketing ordinaire.

Il devrait avoir des contrôles d'accès plus stricts, une surveillance des exportations, des conditions de notification d'incident, des plans de livraison alternatifs et des manuels de communication client répétés. Le fournisseur devrait savoir à quelle vitesse il peut désactiver, migrer ou remplacer le fournisseur sans perdre la confiance des clients.

La deuxième question pour le fournisseur est de savoir si les paramètres de sécurité des comptes par défaut reflètent la valeur des ressources cloud. La plateforme exige-t-elle une authentification plus forte pour les équipes, les propriétaires ou les actions à haut risque? Les clients peuvent-ils voir clairement l'historique de sécurité? Les jetons API sont-ils délimités et vérifiables? Les autorisations OAuth sont-elles visibles et révocables? Les anomalies de réinitialisation de mot de passe sont-elles détectées rapidement? Les équipes de support sont-elles prêtes à aider les clients qui craignent un phishing ciblé?

L'incident Mailchimp n'a pas eu besoin de violer le plan de contrôle cloud pour tester ces contrôles.

Pour les acheteurs, les questions sont tout aussi pratiques. Quelles adresses email contrôlent les comptes cloud? S'agit-il de boîtes aux lettres partagées, d'adresses personnelles ou d'identités gérées? La 2FA est-elle exigée pour chaque membre de l'équipe? L'organisation connaît-elle toutes les équipes, tous les jetons et toutes les autorisations OAuth de DigitalOcean? Peut-elle désactiver rapidement l'accès d'un fournisseur ou d'un sous-traitant? Conserve-t-elle suffisamment de journaux pour examiner les modifications de ressources après un avis du fournisseur?

A-t-elle formé les administrateurs à naviguer directement vers le panneau de contrôle plutôt que de cliquer sur des liens urgents dans les emails?

Il ne faut pas s'attendre à ce que les petites organisations gèrent des programmes de risque fournisseur de niveau entreprise. Mais elles peuvent toujours adopter une courte routine de contrôle: activer la 2FA basée sur une application, exiger une connexion sécurisée pour les équipes, supprimer les membres inactifs, examiner les jetons, utiliser des contacts de facturation et de sécurité distincts lorsque c'est possible, protéger le compte email lui-même et vérifier les messages suspects par des canaux connus. L'intérêt de cette routine est qu'elle transforme un incident fournisseur vague en actions concrètes.

Les régulateurs et les auditeurs peuvent également tirer des leçons du cas. Une catégorie de données telle que « adresse email » doit être évaluée dans son contexte. Une adresse email liée à un administrateur cloud est plus sensible qu'une adresse de newsletter ordinaire car elle peut soutenir une attaque de compte. Les examens de sécurité devraient demander ce que l'adresse identifie et quels flux de travail elle peut déclencher. La classification par le seul nom de champ passe à côté du risque.

La conclusion en matière de responsabilité

L'incident Mailchimp de DigitalOcean n'était pas, selon les données publiques, une histoire d'attaquants prenant le contrôle de l'infrastructure des clients à grande échelle. C'était une histoire sur la manière dont des emails clients exposés et des messages transactionnels perturbés peuvent déplacer le risque vers les comptes cloud. Cela en fait un test de responsabilité utile. Le risque ne résidait pas seulement dans l'environnement de Mailchimp, ni seulement dans le panneau de contrôle de DigitalOcean, ni seulement dans l'hygiène des clients. Il résidait dans les liens entre eux.

DigitalOcean avait un contrôle concret sur la communication avec les clients, la télémétrie des comptes, les fonctionnalités de sécurité, le cadrage de l'incident et les avis aux clients. Mailchimp avait un contrôle concret sur la plateforme du fournisseur, l'accès à l'administration des comptes, la détection d'activité suspecte, la suspension des comptes clients et les preuves du côté du fournisseur. Les clients avaient un contrôle concret sur les seconds facteurs, la sécurité des emails, l'appartenance aux équipes, l'hygiène des jetons et les actions de réponse. La responsabilité suit ces contrôles.

La leçon publique la plus forte est que la pile de communication d'un fournisseur cloud fait partie de la confiance de production chaque fois qu'elle transporte la récupération de compte, les alertes et les avis de sécurité client. Elle n'exécute peut-être pas de charges de travail, mais elle détermine si les utilisateurs gardent le contrôle des charges de travail. Un fournisseur qui expose l'audience de ces messages n'a pas simplement divulgué une liste de contacts; il a exposé une carte de ciblage. Un fournisseur qui perturbe ces messages n'a pas simplement interrompu le marketing; il a affaibli la récupération et la notification.

La réponse correcte n'est pas de traiter toute exposition d'email comme une compromission catastrophique. C'est d'exiger des preuves qui séparent la liste exposée, la tentative de réinitialisation, l'accès réussi au compte et le changement de ressource. Ces catégories permettent aux clients d'agir de manière proportionnée. Elles permettent également aux fournisseurs d'améliorer les contrôles sans inventer de faits.

Le billet public de DigitalOcean est précieux car il a donné un calendrier, nommé Mailchimp, décrit l'exposition d'emails clients, reconnu les tentatives de réinitialisation de mot de passe, séparé les avis aux clients plus larges et plus étroits et décrit le déménagement des services critiques. Les questions publiques non résolues sont celles qui demeurent souvent dans les incidents de sécurité: la population exacte affectée, les preuves privées des clients, les détails d'accès du côté du fournisseur et les changements de contrôle à long terme. Ces lacunes n'effacent pas la leçon.

Elles définissent la norme de responsabilité pour le prochain fournisseur qui découvre qu'un incident fournisseur hors production est devenu un problème de confiance de production.