Zendesk: les anciennes données de support, un test de responsabilité pour la confiance des clients

Résumé

• La FAQ mise à jour de Zendesk indique qu'elle a été alertée en 2019 d'un problème de sécurité concernant les comptes clients Support et Chat activés avant novembre 2016, et que les informations de ces comptes clients avaient été consultées sans autorisation avant cette date.
• La question centrale de responsabilité est la suivante: qui avait le contrôle pratique de la conservation des bases de données de support, de l'exposition des identifiants et des jetons, du calendrier de notification des clients, de la segmentation des locataires, de la reconstruction de l'audit et de la preuve que le contenu des tickets était délimité?
• Les premiers rapports publics décrivaient un ensemble d'environ 10 000 comptes Support et Chat affectés; la FAQ ultérieure de Zendesk identifie environ 15 000 comptes et indique que certaines informations d'authentification ont été consultées pour un ensemble d'environ 7 000 comptes clients.
• Les clients utilisant Zendesk pour le support, le chat, les centres d'aide, les intégrations et les opérations clients ont dû déterminer si d'anciennes métadonnées de support pouvaient encore exposer des agents, des utilisateurs finaux, des intégrations, des certificats ou la confiance des clients en aval.
• Le dossier permet de conclure avec une haute confiance à une responsabilité concernant la conservation, l'authentification, la notification et les limites des preuves. Il ne permet pas d'inventer des faits privés sur chaque locataire, chaque ticket, chaque identifiant d'application, chaque clé TLS ou chaque décision client en aval.

Dossier des preuves et utilisation

Cet article traite le dossier public comme une preuve stratifiée plutôt que comme un compte rendu unique complet. Les enregistrements de l'entreprise sont utilisés pour ce que Zendesk a déclaré publiquement. Les rapports de sécurité, la documentation développeur, les documents juridiques, les conseils en matière de confidentialité, les références aux techniques de vulnérabilité et les normes sont utilisés pour cadrer la chronologie, les devoirs de contrôle et les implications pour les parties concernées. L'analyse ne traite pas les rapports secondaires comme une preuve de faits privés que le dossier public ne montre pas.

Le cadre de responsabilité est plus étroit que le blâme et plus large qu'une ancienne base de données

Zendesk a transformé d'anciennes données de support en test de responsabilité pour la confiance des clients, car l'incident n'était pas simplement un avis de violation historique. Le dossier public montre un problème de sécurité impliquant des comptes activés avant novembre 2016, découvert et communiqué en 2019, avec des mises à jour ultérieures de la FAQ de Zendesk qui ont identifié des informations personnelles, des mots de passe hachés et salés, certains matériels d'authentification, paramètres de configuration d'applications et un petit nombre d'éléments de certificats TLS.

La même FAQ indique que Zendesk n'a trouvé aucune preuve que des données de tickets aient été consultées en lien avec l'incident. Cette combinaison a créé une question pratique: qu'est-ce qui restait exactement de valeur dans les anciens systèmes de support des années après la création initiale des comptes, essais, applications et certificats concernés?

Le blâme est trop brutal pour cette question. La responsabilité demande qui avait l'autorité, les preuves, les outils, et le devoir de réduire le risque à chaque étape. Zendesk contrôlait les bases de données des comptes Support et Chat, les choix de conservation hérités, les enregistrements de configuration des applications, la gestion des certificats téléchargés, le plan de rotation des mots de passe, la notification des clients et la FAQ publique.

Les clients contrôlaient leurs propres agents, utilisateurs finaux, applications installées, identifiants d'intégration, remplacement des certificats TLS, analyse réglementaire et règles locales de conservation des tickets. Les fournisseurs d'applications tierces contrôlaient des parties de leurs propres flux d'authentification. Les régulateurs contrôlaient toute détermination formelle en vertu du droit local. Chaque partie avait un rôle, mais seul Zendesk pouvait rendre visible la limite de la violation du côté service.

Cette limite est le cœur de l'affaire. Une plateforme de support se trouve à proximité de la relation entre une entreprise et ses propres clients. Même lorsqu'une violation affecte la couche des comptes de la plateforme de support plutôt que les corps des tickets, le client doit encore se demander si des agents, utilisateurs finaux, applications, certificats ou la confiance dans le centre d'aide sont en danger. Le devoir du fournisseur est de rendre cette réponse utilisable plutôt que vague.

Ce que le dossier public établit

La FAQ mise à jour de Zendesk établit plusieurs points fermes. L'entreprise a déclaré avoir été alertée par un tiers concernant un problème de sécurité qui aurait pu affecter les produits Support et Chat et les comptes clients activés avant novembre 2016. Elle a indiqué que les équipes de sécurité de Zendesk et des experts extérieurs en forensique ont enquêté. Elle a dit que des informations appartenant à un faible pourcentage de clients avaient été consultées avant novembre 2016.

La FAQ actuelle identifie environ 15 000 comptes Support et Chat, y compris des comptes d'essai expirés et des comptes qui ne sont plus actifs, dont les informations de compte ont été consultées sans autorisation. Elle indique également que les bases de données exposées comprenaient des adresses e-mail, identifiants, numéros de téléphone d'agents et d'utilisateurs finaux, ainsi que des mots de passe hachés et salés pour les agents et utilisateurs finaux, sans preuve que ces mots de passe aient été utilisés pour accéder aux services Zendesk en lien avec l'incident.

La FAQ ajoute également une deuxième couche. Zendesk a déclaré que certaines informations d'authentification avaient été consultées pour environ 7 000 comptes clients, y compris des comptes d'essai expirés et inactifs. Elle a listé des clés de chiffrement TLS fournies par les clients et des paramètres de configuration d'applications de marketplace ou privées, pouvant inclure des clés d'intégration utilisées par ces applications pour s'authentifier auprès de services tiers.

Zendesk a conseillé à certains clients de faire tourner les identifiants d'applications, de remplacer les certificats encore valides téléchargés et d'envisager de faire tourner d'autres matériels d'authentification utilisés avant novembre 2016. Elle a également déclaré n'avoir trouvé aucune preuve que des données de tickets aient été consultées en lien avec cet incident.

Les rapports secondaires capturent la première forme publique de l'incident. CyberScoop, SecurityWeek et BleepingComputer ont rapporté en octobre 2019 que Zendesk avait divulgué une ancienne violation affectant environ 10 000 comptes. Cette différence de décompte n'est pas une raison de choisir un enregistrement et de rejeter l'autre. C'est une raison de lire l'incident en plusieurs étapes. La compréhension publique est passée d'un cadrage initial de 10 000 comptes à une FAQ ultérieure avec des détails supplémentaires sur les comptes et le matériel d'authentification.

La discordance des décomptes publics constitue elle-même une preuve de responsabilité

Le manifeste de cet article utilise le dossier public selon lequel Zendesk a déclaré en 2019 avoir identifié un accès non autorisé associé à environ 10 000 comptes Support et Chat provenant d'un incident de 2016. C'était le cadrage public initial. La FAQ actuelle de Zendesk parle d'environ 15 000 comptes et identifie également environ 7 000 comptes clients avec certaines informations d'authentification concernées. Les deux faits comptent. Le premier chiffre montre ce avec quoi les clients et les journalistes ont d'abord dû travailler. Le chiffre mis à jour montre que le dossier public est devenu par la suite plus détaillé et plus complexe.

Les enregistrements de violation échelonnés ne sont pas intrinsèquement suspects. Les enquêtes modifient souvent les décomptes lorsque les journaux sont examinés, les comptes dormants rapprochés, les doublons supprimés et les catégories de données séparées. La question de responsabilité est de savoir si les clients peuvent comprendre la différence. Un décompte de comptes Support et Chat n'est pas la même chose qu'un décompte de clients avec du matériel d'authentification. Un compte d'essai n'est pas la même chose qu'un locataire d'entreprise actif. Un hachage de mot de passe n'est pas la même chose qu'un jeton OAuth.

Une clé TLS n'est pas la même chose que le contenu d'un ticket. Si un dossier public utilise un chiffre pour décrire toutes ces surfaces, les clients prendront de mauvaises décisions.

La FAQ de Zendesk aide en séparant les informations de compte, les informations d'authentification, la rotation des mots de passe, la rotation des identifiants d'applications, le remplacement de certificats, l'impact sur les produits et les preuves relatives aux données de tickets. Le dossier serait encore plus solide si chaque décompte et classe de données étaient plus faciles à rapprocher dans une chronologie publique unique. La leçon n'est pas que chaque décompte précoce doit être définitif. La leçon est que la raison de chaque décompte doit être claire.

L'objet de confiance était la relation de support

L'objet de confiance dans cette affaire était la relation de support. Zendesk n'est pas seulement une page de connexion. C'est un environnement de support client où les agents, utilisateurs finaux, tickets, chats, centres d'aide, applications et intégrations aident les entreprises à gérer les relations clients. Le système de support peut contenir des noms, adresses e-mail, numéros de téléphone, problèmes de produits, identifiants de compte, détails de dépannage, pièces jointes, et l'état opérationnel de la relation d'un client avec une entreprise.

Même lorsque le contenu des tickets n'est pas prouvé avoir été consulté, les données environnantes des comptes de support peuvent encore.

C'est pourquoi l'incident avait plus de poids qu'une ancienne table d'utilisateurs. Les noms et coordonnées des agents peuvent aider à cibler le personnel de support. Les noms et coordonnées des utilisateurs finaux peuvent aider à cibler les clients des clients de Zendesk. Les mots de passe hachés et salés peuvent créer des devoirs de réinitialisation et des préoccupations de réutilisation. Les paramètres de configuration d'applications et les clés d'intégration peuvent connecter le système de support à d'autres systèmes. Le matériel de certificat TLS peut affecter les centres d'aide personnalisés des clients.

Chaque élément touche une différente partie de la relation de support.

L'objet de confiance explique également pourquoi les clients avaient besoin de la preuve que les données de tickets étaient délimitées. Si les données de tickets n'ont pas été consultées, la charge de travail du client reste sérieuse mais plus étroite: identifiants, applications, certificats, contacts et analyse de notification. Si les corps des tickets ont été consultés, la charge de travail pourrait s'étendre à la notification des utilisateurs finaux, la confidentialité des produits, les pièces jointes, les historiques de service et les données réglementées.

La déclaration publique de Zendesk selon laquelle elle n'a trouvé aucune preuve d'accès aux données de tickets était donc une revendication de limite matérielle.

La conservation héritée a rendu les anciens comptes opérationnellement actuels

L'âge de l'incident est le point. Les comptes activés avant novembre 2016 étaient encore pertinents en 2019 car d'anciens enregistrements peuvent conserver une signification opérationnelle. La FAQ de Zendesk mentionne explicitement les comptes d'essai expirés et les comptes qui n'étaient plus actifs. Ces catégories importent car un client pourrait supposer que les enregistrements inactifs ou d'essai ont peu de valeur. Dans une plateforme de support, d'anciens enregistrements peuvent encore contenir des identifiants, adresses e-mail, numéros de téléphone, mots de passe hachés, paramètres d'applications ou matériel de certificat.

La dormance réduit certains risques, mais elle n'efface pas les données.

La responsabilité de conservation n'est pas seulement un problème de confidentialité. C'est un problème de sécurité et de charge de travail client. Si d'anciens comptes restent dans une base de données, le fournisseur doit savoir pourquoi ils sont conservés, comment ils sont protégés, quand ils sont supprimés ou anonymisés, et ce que les clients doivent faire s'ils sont consultés. Le vocabulaire de minimisation et de limitation de conservation de l'article 5 du RGPD est utile ici car il cadre la conservation comme un devoir de contrôle, pas seulement comme une habitude de stockage.

Le cadre de cybersécurité du NIST ajoute la discipline plus large d'identification, protection, détection, réponse et récupération.

Le dossier public ne montre pas chaque règle de conservation de Zendesk en 2016 ni chaque changement ultérieur. Zendesk a déclaré avoir fait des investissements après 2016, y compris une protection renforcée des données personnelles sensibles et un alignement sur le RGPD pour la conservation des journaux et des données. Cette déclaration est utile, mais les clients avaient encore besoin de preuves spécifiques à l'incident: quels anciens enregistrements restaient, lesquels étaient actifs, lesquels étaient inactifs, lesquels contenaient du matériel d'authentification et quelle rotation ou remplacement était requis.

Les hachages de mots de passe exigeaient un plan d'action client

La FAQ de Zendesk indique que les mots de passe des agents et utilisateurs finaux étaient hachés et salés et que Zendesk n'a trouvé aucune preuve que ces mots de passe aient été utilisés pour accéder aux services Zendesk en lien avec l'incident. Cela est meilleur qu'un enregistrement de vol de mots de passe en texte clair, mais ce n'est pas un enregistrement sans action. Les mots de passe hachés et salés peuvent encore être attaqués hors ligne selon la méthode de hachage, le facteur de travail, la qualité du mot de passe de l'utilisateur et les ressources de l'attaquant.

Si les utilisateurs ont réutilisé des mots de passe en dehors de Zendesk, un vérificateur copié peut créer un risque en aval même lorsque Zendesk lui-même ne voit pas d'accès lié.

Le plan de rotation des mots de passe de Zendesk a traité cette classe de risque. La FAQ indique que la rotation s'appliquait à certains agents et utilisateurs finaux créés avant le 1er novembre 2016, lorsque Zendesk ne pouvait pas identifier que l'utilisateur avait changé le mot de passe depuis cette date et lorsque l'utilisateur n'utilisait pas de connexion unique. La rotation affectait également les produits partageant l'authentification avec Support, y compris Guide, Talk et Explore. C'est un détail de responsabilité car il indique aux clients qui devait agir et pourquoi.

Les guides d'identité numérique du NIST et de stockage des mots de passe de l'OWASP sont utilisés ici pour cadrer la classe de contrôle. L'architecture exacte des mots de passe privés n'est pas visible dans le dossier public, et cet article ne l'invente pas. Le point pertinent est qu'un fournisseur détenant des vérificateurs de mots de passe doit supposer qu'un vol est possible, protéger les vérificateurs contre les attaques hors ligne et exécuter un plan de réinitialisation ou de rotation qui atteint les bons utilisateurs sans confondre les clients qui utilisent la connexion unique.

Le matériel d'authentification a élargi l'affaire au-delà des réinitialisations de mots de passe

La mise à jour la plus conséquente de la FAQ de Zendesk est la couche du matériel d'authentification. La FAQ indique que certaines informations d'authentification ont été consultées pour environ 7 000 comptes clients. Les éléments listés comprennent des clés de chiffrement TLS fournies par les clients et des paramètres de configuration d'applications de marketplace ou privées, pouvant inclure des clés d'intégration utilisées par ces applications pour s'authentifier auprès de services tiers. Ce langage déplace l'affaire au-delà de la rotation ordinaire des mots de passe.

Les identifiants d'applications et le matériel TLS créent un devoir client différent. Une réinitialisation de mot de passe peut souvent être gérée par chaque utilisateur à la prochaine connexion. Un identifiant d'application peut connecter Zendesk à des systèmes de CRM, facturation, entrepôt de données, messagerie, workflow ou identité. Une clé privée TLS peut affecter un centre d'aide personnalisé du client ou une correspondance d'hôte. Les personnes qui possèdent ces devoirs peuvent ne pas être les mêmes agents qui utilisent Zendesk quotidiennement.

Il peut s'agir d'ingénieurs de sécurité, de propriétaires d'applications, d'administrateurs web ou d'équipes de gestion des fournisseurs.

Zendesk a conseillé aux clients ayant installé des applications de marketplace ou privées avant le 1er novembre 2016, et ayant enregistré des identifiants d'authentification lors de l'installation, de faire tourner les identifiants pour les applications concernées. Elle a également conseillé aux clients ayant téléchargé un certificat TLS encore valide avant cette date de le remplacer et de révoquer l'ancien certificat. Ces instructions étaient concrètes, et elles montrent pourquoi l'incident ne pouvait pas être clos par la seule rotation des mots de passe des comptes.

Les applications et intégrations ont transformé le support en système connecté

La documentation développeur de Zendesk montre pourquoi la configuration des applications importe. L'API Apps peut gérer et interagir avec les applications Zendesk, et la documentation note que les actions de ces points de terminaison sont enregistrées dans le journal d'audit du compte Support concerné. La documentation des requêtes d'applications explique que les applications peuvent effectuer des appels API REST et d'autres requêtes HTTP et peuvent gérer des jetons d'accès OAuth pour les services tiers. La documentation de sécurité des API identifie les jetons API et les jetons OAuth comme des moyens d'autoriser les requêtes.

La documentation des jetons OAuth donne aux administrateurs un moyen d'examiner les propriétés des jetons.

Ces documents actuels ne sont pas une preuve de chaque configuration d'application de 2016. Ils sont utilisés pour identifier la surface de contrôle. Une application Zendesk n'est pas simplement un module visuel. Elle peut connecter l'espace de travail de support à d'autres systèmes et détenir ou utiliser du matériel d'authentification. Si d'anciens paramètres d'application ont été consultés, le client doit savoir quelles applications, quels identifiants, quelles dates, quelles destinations, et si une rotation est nécessaire en dehors de Zendesk.

Il s'agit d'un problème récurrent des services cloud. Les clients achètent une plateforme, puis y attachent des intégrations jusqu'à ce que la plateforme devienne un hub opérationnel. Lorsqu'une violation affecte ce hub, le fournisseur doit aider les clients à cartographier les systèmes connectés. Sans cette carte, le client doit inspecter application par application sous pression temporelle, souvent des années après l'installation.

Le matériel de certificat TLS a créé une charge de preuve distincte

Le matériel de certificat TLS n'est pas une donnée de compte ordinaire. Si un client a téléchargé un certificat et une clé privée pour soutenir un centre d'aide personnalisé, l'accès à ce matériel pourrait affecter la capacité du client à prouver le contrôle d'un domaine ou à protéger le trafic chiffré. La FAQ de Zendesk indique qu'elle a identifié un petit groupe de clients dont les certificats TLS ont été consultés, presque tous expirés au moment de la FAQ. Elle a conseillé aux clients ayant des certificats téléchargés encore valides d'avant le 1er novembre 2016 de télécharger un nouveau certificat et de révoquer l'ancien.

Le guide de support de Zendesk pour la préparation d'un certificat au téléchargement explique que les clients peuvent avoir besoin d'identifier les fichiers de certificats, de créer un bundle et d'obtenir un fichier de clé. Cette documentation montre pourquoi la gestion des certificats est sensible: les processus de téléchargement peuvent impliquer du matériel de clé privée. L'incident devait donc distinguer les métadonnées de certificat des secrets de certificat, les certificats expirés des certificats valides, et les clients qui utilisaient les options de certificats gérés par Zendesk des clients qui téléchargeaient leur propre matériel.

Le dossier public ne prouve pas l'utilisation abusive des clés TLS. Il établit un devoir d'action pour un classe spécifique de clients. La leçon de responsabilité est que le matériel cryptographique téléchargé par le client nécessite un inventaire, une règle de conservation et un chemin de notification distincts. Il ne devrait pas être enfoui dans un message général de violation de compte de support.

Le contenu des tickets était la limite dont les clients avaient le plus besoin

La FAQ de Zendesk indique qu'elle n'a trouvé aucune preuve que des données de tickets aient été consultées en lien avec l'incident. Elle indique également que si Zendesk déterminait que les données de service d'un client, y compris les informations personnelles, étaient compromises, Zendesk communiquait spécifiquement cette détermination au client. Pour les clients de Zendesk, cette limite était centrale.

Le contenu des tickets peut inclure des plaintes, l'historique de compte, des problèmes de produits, des pièces jointes, des détails de dépannage, des signalements de fraude, des références de santé, des dossiers d'étudiants, des questions RH, des problèmes de paiement ou des informations d'identité selon le client.

Parce que le contenu des tickets peut être si sensible, une déclaration d'absence de preuve est utile mais pas la réponse complète. Les clients avaient besoin de comprendre la classe de preuves: quels journaux ont été examinés, quelles tables de base de données ont été séparées, si les pièces jointes étaient concernées, si les transcriptions de Chat différaient des tickets Support, et comment les comptes inactifs étaient mappés aux locataires actifs. La FAQ publique donne la conclusion et dit que des forensiques extérieurs ont été engagés.

Elle ne montre pas le chemin complet des preuves, et elle ne peut raisonnablement pas publier chaque détail sensible.

La norme responsable est de fournir suffisamment de structure pour que les clients prennent leurs propres décisions juridiques et opérationnelles. Si les données de tickets sont délimitées, les clients peuvent éviter des notifications inutiles aux utilisateurs finaux. Si les données de tickets sont incertaines, ils peuvent avoir besoin d'évaluer les seuils réglementaires. Un fournisseur de plateforme de support doit réduire cette incertitude rapidement car le client, et non le fournisseur, peut être le responsable du traitement des données de service.

Les rôles de responsable du traitement et de sous-traitant ont modifié la charge de notification

La FAQ de Zendesk cadre expressément les clients comme responsables du traitement des données de service et Zendesk comme sous-traitant lors de l'exécution du service Zendesk. Cette distinction importe car elle explique pourquoi les clients ne pouvaient pas simplement attendre que Zendesk prenne chaque décision réglementaire. En vertu de l'article 33 du RGPD, un responsable du traitement peut avoir des devoirs de notification à l'autorité de contrôle lorsqu'une violation de données personnelles atteint le seuil légal.

La FAQ de Zendesk a indiqué aux clients qu'elle mettrait à disposition les informations qu'elle avait pour les aider à prendre cette détermination.

C'est une description équitable des rôles juridiques partagés, mais cela crée également une charge de preuve élevée pour le sous-traitant. Les clients ne peuvent pas décider de notifier un régulateur ou des utilisateurs finaux sans connaître les catégories de données affectées, si des données de service ont été consultées, quels agents et utilisateurs finaux étaient concernés, et si le matériel d'authentification pourrait affecter d'autres systèmes. Si le fournisseur détient ces faits et les divulgue lentement ou de manière ambiguë, les clients portent l'incertitude juridique sans les preuves nécessaires pour la résoudre.

L'accord de traitement des données de Zendesk et ses documents RGPD fournissent le contexte juridique général. Le dossier de l'incident de 2016 montre la version opérationnelle de ce contexte. Un client peut être juridiquement responsable des décisions concernant ses données de service, mais il dépend du dossier d'enquête de Zendesk pour prendre ces décisions. C'est pourquoi le partage des preuves n'est pas une courtoisie. Il fait partie de la fonction de responsabilité du sous-traitant.

La segmentation des locataires était la couche d'assurance invisible

La segmentation des locataires détermine si une violation de plateforme reste délimitée. La FAQ de Zendesk indique que les comptes affectés représentaient un faible pourcentage de clients et que les clients dont les données de service étaient déterminées comme compromises étaient spécifiquement notifiés. Elle indique également qu'il n'y avait aucune preuve que des produits autres que Support et Chat aient été affectés, bien que la rotation des mots de passe ait touché des produits partageant l'authentification avec Support. Ces déclarations reposent sur des preuves de segmentation que les clients ne pouvaient pas examiner indépendamment.

La segmentation dans une plateforme de support comprend plus que la séparation des bases de données. Elle inclut les frontières de produits, les domaines d'authentification, les paramètres d'applications, les certificats téléchargés par les clients, les magasins de tickets, les essais expirés, les comptes inactifs, les services partagés, les journaux et les outils de support utilisés par le personnel de Zendesk. Si la segmentation est solide et bien documentée, le fournisseur peut dire aux clients pourquoi leurs données de tickets n'étaient pas concernées même si les métadonnées de compte l'étaient.

Si la segmentation est faible, d'anciens enregistrements peuvent créer un rayon d'effet inattendu.

Le dossier public n'expose pas l'architecture complète des locataires de Zendesk. C'est normal. Mais l'entreprise devait néanmoins fournir des conclusions orientées client suffisamment spécifiques pour agir: dates des comptes affectés, noms des produits affectés, catégories de données, conditions de rotation des mots de passe, catégories de matériel d'authentification, limite des données de tickets et communications spécifiques aux clients. Ce sont les résultats publics des preuves privées de segmentation.

La reconstruction d'audit faisait partie de la récupération, pas du travail de fond

Zendesk a déclaré avoir engagé des experts forensiques extérieurs, activé son équipe de réponse aux incidents de sécurité, informé les forces de l'ordre et les régulateurs mondiaux appropriés, et poursuivi l'enquête. Ce sont des actions standard de réponse aux incidents, mais dans cette affaire, elles ont servi une fonction spéciale: reconstruire un ancien événement.

Lorsqu'un incident de 2016 est divulgué publiquement en 2019, l'entreprise doit travailler à rebours à travers les journaux, les états des comptes, les enregistrements de base de données, les dates d'installation des applications, les dates de téléchargement des certificats, l'historique des changements de mots de passe, les frontières des produits et le statut des clients.

Cette reconstruction est plus difficile que le confinement en direct. Les journaux peuvent avoir atteint leur limite de rétention. Les comptes peuvent être inactifs. Les comptes d'essai peuvent ne plus avoir de propriétaires actifs. Les identifiants d'applications peuvent avoir été remplacés, ou ils peuvent encore être tranquillement utilisés par un processus métier. Les certificats TLS peuvent avoir expiré, renouvelé, ou été remplacés. Les employés qui ont installé des applications peuvent être partis. Les clients peuvent avoir changé de contacts juridiques. Ces faits ordinaires rendent l'ancienne violation opérationnellement actuelle.

Le dossier devrait donc traiter la reconstruction d'audit comme une preuve de récupération, pas comme un détail forensique de fond. Les clients avaient besoin de savoir quelles dates limites importaient, quelles dates d'installation déclenchaient une action, quelles classes d'identifiants exigeaient une rotation et quels enregistrements Zendesk avait suffisamment de confiance pour exclure. Un dossier de reconstruction solide empêche à la fois la sous-réaction et la surréaction inutile.

Les enregistrements de confiance actuels sont un contexte utile, pas une preuve rétroactive

Le Centre de confiance de Zendesk décrit les pratiques actuelles de sécurité, conformité, chiffrement, centre de données et assurance. L'accord de traitement des données décrit le cadre juridique actuel pour les données de service et les garanties. La documentation développeur décrit l'authentification API actuelle, la gestion des applications, la visibilité des jetons OAuth et les modèles de requêtes d'applications. Ces enregistrements sont utiles car ils montrent le vocabulaire de contrôle que les clients utilisent lorsqu'ils évaluent Zendesk aujourd'hui.

Ils ne doivent pas être lus comme une preuve rétroactive de chaque contrôle de 2016. Un Centre de confiance actuel ne prouve pas quels enregistrements existaient dans les bases de données héritées. Une page actuelle de jetons API ne prouve pas quels jetons ou paramètres étaient présents en 2016. Une page d'aide actuelle sur les certificats ne prouve pas chaque détail de gestion des clés téléchargées par les clients de la période de l'incident. L'utilisation correcte est plus étroite et plus disciplinée: les documents actuels identifient les types de contrôles et de responsabilités client qui rendent l'incident de 2016/2019 significatif.

Cette distinction évite deux erreurs courantes. La première est d'ignorer les enregistrements actuels de l'entreprise qui nomment de véritables surfaces de confiance. La seconde est de traiter le langage de confiance actuel comme une réponse complète à une ancienne violation. La lecture mature utilise la FAQ de l'incident pour l'événement et utilise les documents actuels pour comprendre les classes de contrôle que les clients devraient examiner.

Ce que le dossier public ne prouve pas

Un article prudent devrait nommer ce qu'il ne sait pas. Le dossier public ne montre pas le chemin technique initial exact utilisé en 2016. Il ne révèle pas chaque table affectée, chaque entrée de journal, chaque locataire, chaque installation d'application, chaque certificat ou chaque communication client. Il ne prouve pas que chaque mot de passe haché a été cassé. Il ne prouve pas que les identifiants d'applications ont été utilisés contre des services tiers. Il ne prouve pas que les clés TLS ont été utilisées de manière abusive. Il ne prouve pas que les données de tickets ont été consultées.

Il ne montre pas chaque contrôle de sécurité ultérieur ni chaque interaction avec les régulateurs.

Ces limites ne sont pas une faiblesse de l'analyse. Elles sont la surface de responsabilité. Les clients avaient besoin de suffisamment de preuves pour décider quoi faire tourner, quoi remplacer, quoi dire aux agents et aux utilisateurs finaux, quoi évaluer en vertu des lois sur la vie privée, et si le contenu des tickets était délimité. Zendesk était mieux positionné que tout client individuel pour réduire l'incertitude sur les faits côté service.

Le constat le plus fort est donc délimité. Zendesk devait gérer un ancien incident de compte de support, la rotation des mots de passe, l'examen des identifiants d'applications, le remplacement des certificats, la notification spécifique aux clients et l'assurance de la limite des tickets. Le dossier public soutient ces devoirs. Il ne soutient pas l'élargissement de l'incident à un vol non étayé de contenu de tickets ou à une compromission non étayée de tiers.

Un dossier public plus solide séparerait chaque surface affectée

Un dossier public plus solide placerait les principales surfaces dans une carte d'action unique. Il séparerait les informations de compte Support et Chat du matériel d'authentification. Il séparerait les clients actifs des essais expirés et des comptes inactifs. Il séparerait les mots de passe hachés des identifiants d'applications et les clés TLS. Il séparerait la rotation des mots de passe utilisateur de la rotation des identifiants d'applications et du remplacement de certificats. Il séparerait les données de tickets des métadonnées de compte et expliquerait la base de cette limite au niveau de la classe.

La carte décrirait également les rôles des clients. Les agents et utilisateurs finaux ont besoin de conseils sur les mots de passe. Les administrateurs Zendesk ont besoin de conseils sur les comptes affectés et les produits. Les propriétaires d'applications ont besoin de conseils sur les identifiants d'intégration. Les administrateurs web ont besoin de conseils sur les certificats. Les équipes de confidentialité ont besoin des preuves de responsable du traitement et de sous-traitant. Les équipes de sécurité ont besoin de conseils sur l'audit, les jetons et l'examen des accès.

Les dirigeants ont besoin d'une déclaration concise du risque résiduel et de l'impact client. Ces audiences ne sont pas interchangeables.

Cela ne nécessite pas de publier des détails sensibles. Cela nécessite un arbre de décision. Si votre compte a été créé après la date limite, voici la frontière des preuves. Si votre compte utilisait la connexion unique, voici ce qui change et ce qui ne change pas. Si vous avez installé une application avant la date limite et stocké des secrets, faites-les tourner. Si vous avez téléchargé un certificat qui est encore valide, remplacez-le et révoquez l'ancien. Si les données de tickets n'étaient pas concernées, voici la classe de preuves derrière cette affirmation.

Les acheteurs devraient poser des questions sur les anciennes données de support avant le renouvellement

Les clients et acheteurs de Zendesk ne devraient pas attendre un incident pour poser des questions sur les anciennes données de support. Une plateforme de support peut tranquillement accumuler des agents, utilisateurs finaux, tickets, champs personnalisés, macros, applications, webhooks, certificats, jetons API, clients OAuth et enregistrements d'essai. Certaines de ces données peuvent être nécessaires pour l'audit, le service client ou la défense juridique. Certaines peuvent simplement rester parce que la suppression est difficile. Le moment du renouvellement est celui où les clients ont le levier pour demander ce qui est quoi.

Les questions utiles sont pratiques. Combien de temps les comptes inactifs sont-ils conservés? Comment les essais expirés sont-ils supprimés ou anonymisés? Qu'arrive-t-il aux anciens enregistrements d'agents et d'utilisateurs finaux? Comment les vérificateurs de mots de passe sont-ils protégés? Comment les clients peuvent-ils lister les applications installées et leurs dates d'installation? Les administrateurs peuvent-ils examiner les jetons OAuth et les jetons API? Comment les clés TLS téléchargées par les clients sont-elles stockées et retirées? Comment les magasins de tickets sont-ils segmentés des métadonnées de compte?

Quelles preuves le fournisseur partagera-t-il si un ancien incident est découvert?

Ces questions ne sont pas antagonistes. Elles rendent les deux parties meilleures en cas d'échec. Le fournisseur sait quelles preuves préserver et divulguer. Le client sait quels propriétaires locaux doivent agir. L'incident Zendesk reste utile car il montre comment d'anciens enregistrements de support peuvent créer du travail frais.

Les conseils d'administration devraient traiter les systèmes de support comme une infrastructure de confiance client

Les conseils d'administration traitent souvent les systèmes de support comme des outils opérationnels plutôt que comme une infrastructure de confiance client. Le dossier Zendesk montre pourquoi c'est trop étroit. Un système de support peut contenir des données de contact, du matériel d'identification, des intégrations, des certificats, du contenu de tickets et des historiques de support. Il peut se situer entre une entreprise et ses clients les plus frustrés ou vulnérables. Il peut également se connecter à de nombreux autres systèmes via des applications et des API.

Si cette plateforme a une violation héritée, l'entreprise qui l'utilise doit répondre aux questions de ses propres clients, pas seulement de son équipe de gestion des fournisseurs.

Les questions du conseil d'administration devraient donc inclure la conservation, l'accès, l'intégration et la notification. Quelles plateformes de support détiennent des données client? Quelles applications ont des secrets? Quels certificats ou domaines personnalisés y sont- hébergés? Quels utilisateurs ont des rôles privilégiés? Quels enregistrements sont plus anciens que le besoin métier actuel? Quels avis du fournisseur déclencheraient une analyse réglementaire? Quelles équipes sont propriétaires de la rotation des mots de passe, de la rotation des identifiants d'applications et du remplacement des certificats?

Le fournisseur a également des devoirs au niveau du conseil d'administration. Il doit savoir quels anciens enregistrements restent, si la conservation sert un objectif réel, si les identifiants sont séparés, si les clés téléchargées par les clients sont suivies, si les paramètres d'applications sont auditables et si les avis d'incident donnent aux clients suffisamment de preuves pour agir. Ce sont des questions de gouvernance, même lorsque les preuves se trouvent dans les journaux d'ingénierie.

Le langage contractuel devrait suivre les surfaces de la plateforme de support

Les clauses génériques de violation sont trop minces pour une plateforme de support. Le langage contractuel devrait suivre les surfaces qui importent. Si le fournisseur détient des données de compte, le contrat devrait traiter de la protection des vérificateurs de mots de passe, du statut de connexion unique, des comptes actifs et inactifs et de la rotation des mots de passe. Si le fournisseur héberge des tickets de support, le contrat devrait traiter des données de tickets, des pièces jointes, des champs personnalisés, de la conservation, de la suppression et de la notification spécifique au client.

Si le fournisseur prend en charge des applications et des API, le contrat devrait traiter des identifiants d'intégration, de l'examen des jetons, de l'inventaire des applications et des journaux d'audit. Si le fournisseur stocke du matériel TLS téléchargé par le client, le contrat devrait traiter de la gestion des clés, de l'expiration, du remplacement et des conseils de révocation.

Le contrat devrait également spécifier les catégories de preuves après un incident. Les clients ont besoin de plages de dates affectées, de noms de produits affectés, de classes de données, de classes d'identifiants, d'actions client, de surfaces exclues et de méthodes d'examen. Ils ont besoin de contacts administrateur distincts des avis aux utilisateurs ordinaires. Ils ont besoin de suffisamment d'informations pour décider si une notification réglementaire est requise lorsqu'ils sont responsables du traitement des données de service.

Le dossier Zendesk est un bon exemple car l'incident public a touché d'anciens comptes, du matériel d'authentification, des certificats, des paramètres d'applications, la rotation des mots de passe et l'assurance sur la limite des tickets. Un contrat qui ne mentionne que les données personnelles peut manquer les secrets d'applications. Un contrat qui ne mentionne que la disponibilité des applications peut manquer la conservation historique. La responsabilité suit la surface qui a échoué.

Des indicateurs opérationnels rendraient les futures affirmations testables

Plusieurs indicateurs rendraient un futur incident de plateforme de support plus facile à tester. Pour les données de compte, le fournisseur peut indiquer les dates de création des comptes affectés, le nombre de comptes actifs par rapport aux comptes inactifs, les catégories d'agents par rapport aux utilisateurs finaux, le statut de changement de mot de passe, les exclusions de connexion unique et le statut de rotation.

Pour le matériel d'authentification, le fournisseur peut indiquer les plages de dates d'installation des applications, les types d'identifiants, les options d'examen des jetons OAuth et API, les conseils aux propriétaires d'applications et les recommandations de rotation pour les tiers. Pour le matériel TLS, le fournisseur peut indiquer si les certificats sont expirés ou valides, si les clés privées étaient concernées et comment les clients devraient les remplacer et les révoquer. Pour les données de tickets, le fournisseur peut indiquer quels magasins ont été examinés et quelles preuves soutiennent l'exclusion.

Pour l'action client, le fournisseur peut séparer les étapes des utilisateurs individuels des étapes des administrateurs. Les utilisateurs peuvent avoir besoin de réinitialiser les mots de passe. Les administrateurs peuvent avoir besoin de lister les applications, faire tourner les secrets, examiner les jetons, remplacer les certificats et documenter l'analyse de confidentialité. Les équipes de confidentialité peuvent avoir besoin de décider si l'article 33 ou d'autres devoirs de notification s'appliquent. Les équipes de sécurité peuvent avoir besoin d'inspecter les journaux pour tout accès suspect lié.

Les responsables du support peuvent avoir besoin d'avertir les agents et de préparer des réponses pour les utilisateurs finaux.

Ces indicateurs ne nécessitent pas de journaux bruts. Ils rendent les affirmations publiques utilisables. La FAQ de Zendesk contient plusieurs catégories appropriées: date limite, produits affectés, règles de rotation des mots de passe, matériel d'authentification, identifiants d'applications, clés TLS, limite des données de tickets, rôles de responsable du traitement et de sous-traitant, et communications spécifiques aux clients. Un dossier plus solide rendrait la chronologie et le rapprochement des décomptes encore plus faciles à suivre.

La question de la récurrence est plus large que Zendesk

La question de la récurrence n'est pas de savoir si Zendesk répète le même événement. La question est de savoir si les plateformes de support, les outils CRM, les systèmes de chat et les hubs de workflow ont appris la leçon des anciennes données. Un système de support peut devenir un magasin à long terme d'identités, de contexte opérationnel, d'enregistrements de contacts clients, de matériel d'authentification et de secrets d'intégration. Une violation découverte des années plus tard peut rendre les anciennes données à nouveau actuelles car les clients doivent encore décider quoi faire tourner, remplacer, notifier ou surveiller.

Le dossier Zendesk appartient à un catalogue de responsabilité plus large pour la dépendance aux services cloud et l'automatisation des logiciels d'entreprise. L'automatisation concentre les enregistrements et les identifiants dans des endroits faciles à oublier après l'installation. La dépendance au cloud donne aux fournisseurs le contrôle des preuves dont les clients ont besoin pour leurs décisions juridiques et opérationnelles.

La localisation des données et la souveraineté ajoutent une autre couche, car les clients de différentes régions peuvent avoir des devoirs de notification différents même lorsque le même incident de plateforme les affecte.

La leçon constructive est de concevoir les plateformes de support comme des systèmes de données responsables dès le début. Ne conservez que ce qui a un but. Protégez les identifiants comme si les enregistrements copiés allaient être attaqués. Rendez l'inventaire des applications et des jetons facile. Gardez les données de tickets segmentées des métadonnées de compte. Préparez des chemins de notification spécifiques aux clients avant une violation. Rendez les anciens enregistrements plus faciles à expliquer lorsque le cycle d'actualité a évolué mais que le devoir du client n'a pas changé.

Le résultat final pour la responsabilité

Le résultat final est que Zendesk contrôlait les preuves côté service héritées dont les clients avaient besoin. Les utilisateurs pouvaient changer les mots de passe, les administrateurs pouvaient faire tourner les identifiants d'applications, les équipes web pouvaient remplacer les certificats, et les équipes de confidentialité pouvaient évaluer les devoirs de notification. Mais aucune de ces parties ne pouvait vérifier indépendamment la limite de la base de données de support, la portée du matériel d'authentification, l'exclusion des données de tickets ou les preuves de segmentation des locataires.

Cela a fait de la FAQ publique de Zendesk et de ses communications spécifiques aux clients les principaux outils de prise de décision pour les clients.

Le constat de responsabilité le plus fort n'est pas que chaque préjudice redouté s'est produit. Le constat le plus fort est que d'anciens enregistrements de support peuvent conserver suffisamment de valeur pour créer un nouveau travail client des années plus tard. Le dossier public soutient les devoirs concernant la conservation, la rotation des mots de passe, les identifiants d'applications, le matériel TLS, la notification des clients et la preuve de la limite des tickets. Il soutient également la retenue concernant les affirmations que les preuves publiques n'établissent pas.

Pour les acheteurs, la leçon est de demander des catégories de preuves avant le renouvellement. Pour les conseils d'administration, il s'agit de traiter les systèmes de support comme une infrastructure de confiance client. Pour les régulateurs, il s'agit d'examiner si les anciens enregistrements étaient conservés, protégés et expliqués de manière à permettre aux responsables du traitement de prendre leurs propres décisions. Pour les clients, il s'agit de maintenir un inventaire des applications, certificats, jetons et rôles d'administrateur de la plateforme de support avant que le prochain ancien incident n'arrive.

La décision du lecteur

Un lecteur devrait repartir avec une question pratique.

Si une plateforme de support divulguait aujourd'hui que d'anciens comptes, des hachages de mots de passe, des paramètres d'applications, des identifiants d'intégration et du matériel TLS avaient été consultés des années auparavant, le fournisseur pourrait-il montrer la plage de dates affectée, les classes de comptes actifs et inactifs, les preuves de jetons et d'applications, le chemin de remplacement des certificats, la limite des données de tickets, la notification spécifique au client et le soutien à la décision réglementaire sans forcer chaque client à deviner à partir d'enregistrements éparpillés?

Si la réponse est non, le dossier Zendesk reste actuel comme une leçon de responsabilité.

La norme équitable n'est pas l'exposition publique de chaque détail technique sensible. La norme équitable est des preuves publiques disciplinées. Dites ce qui s'est passé. Dites ce qui est connu. Dites quels enregistrements ont été affectés. Dites quels enregistrements n'ont pas été affectés et pourquoi. Dites qui doit agir. Dites ce qui a changé à mesure que l'enquête a évolué. Dites comment les clients peuvent vérifier leur propre état. Dans le dossier Zendesk, ces devoirs définissent la surface de confiance client plus clairement que tout décompte de compte unique ne le fait.