Zendesk a fait des anciennes données de support un test de responsabilité de la confiance des clients

Résumé

• Le FAQ mis à 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 des comptes clients avaient été consultées sans autorisation avant cette date.
• La question centrale de responsabilité est celle-ci: qui avait le contrôle effectif sur la conservation des bases de données de support, l'exposition des identifiants et des jetons, le calendrier de notification aux clients, la segmentation des locataires, la reconstruction des audits, et la preuve que le contenu des tickets était délimité?
• Les premiers reportages publics décrivaient l'ensemble affecté comme environ 10 000 comptes Support et Chat; le FAQ ultérieur 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 client ont dû déterminer si les anciennes métadonnées de support pouvaient encore exposer les agents, les utilisateurs finaux, les intégrations, les certificats ou la confiance des clients en aval.
• Le dossier soutient une conclusion de responsabilité à haute confiance concernant la conservation, l'authentification, les notifications et les limites des preuves. Il ne soutient pas l'invention de faits privés sur chaque locataire, chaque ticket, chaque identifiant d'application, chaque clé TLS ou chaque décision de client en aval.

Registre des preuves et comment il est utilisé

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

Le cadre de responsabilité est plus étroit que la culpabilité et plus large qu'une ancienne base de données

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

Le même FAQ indique que Zendesk n'a trouvé aucune preuve que les données de ticket 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 des comptes, essais, applications et certificats concernés?

La culpabilité est trop grossière pour cette question. La responsabilité demande qui avait l'autorité, les preuves, les outils et le devoir de réduire les risques à chaque étape. Zendesk contrôlait les bases de données des comptes de 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 aux clients et le FAQ public.

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 toutes les déterminations formelles en vertu de la loi locale. Chaque partie avait un rôle, mais seul Zendesk pouvait rendre visible la limite de la violation du côté du service.

Cette limite est au cœur du cas. Une plateforme de support est proche 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 le contenu des tickets, le client doit encore se demander si les agents, les utilisateurs finaux, les applications, les certificats ou la confiance du centre d'aide sont en jeu. Le devoir du fournisseur est de rendre cette réponse utilisable plutôt que vague.

Ce que le dossier public établit

Le FAQ mis à jour de Zendesk établit plusieurs points fermes. L'entreprise a indiqué avoir été alertée par un tiers concernant un problème de sécurité qui pourrait avoir affecté les produits Support et Chat et les comptes clients activés avant novembre 2016. Elle a déclaré que les équipes de sécurité de Zendesk et des experts en criminalistique externes ont enquêté. Elle a indiqué que des informations appartenant à un faible pourcentage de clients avaient été consultées avant novembre 2016.

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

Le FAQ ajoute également une deuxième couche. Zendesk a indiqué que certaines informations d'authentification ont été consultées pour environ 7 000 comptes clients, y compris des comptes d'essai expirés et des comptes inactifs. Il a listé des clés de chiffrement TLS fournies par le client et des paramètres de configuration d'application provenant d'applications du marché ou privées, incluant possiblement 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'application, de remplacer les certificats téléchargés encore valides, et d'envisager de faire tourner d'autres matériels d'authentification utilisés avant novembre 2016. Il a également indiqué n'avoir trouvé aucune preuve que les données de ticket aient été consultées en lien avec cet incident.

Les reportages 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 nombre n'est pas une raison pour choisir un enregistrement et rejeter l'autre. C'est une raison pour lire l'incident comme étant par étapes. La compréhension publique est passée d'un cadre initial de 10 000 comptes à un FAQ ultérieur avec des détails supplémentaires sur les comptes et le matériel d'authentification.

Le décalage du nombre public est lui-même une preuve de responsabilité

Le manifeste de cet article utilise le dossier public selon lequel Zendesk a indiqué en 2019 avoir identifié un accès non autorisé associé à environ 10 000 comptes Support et Chat issus d'un incident de 2016. C'était le cadre public initial. Le FAQ actuel de Zendesk parle d'environ 15 000 comptes et identifie également environ 7 000 comptes clients avec certaines informations d'authentification dans le périmètre. Les deux faits importent. Le premier nombre montre ce avec quoi les clients et les journalistes ont d'abord dû travailler. Le nombre mis à jour montre que le dossier public est devenu plus détaillé et plus compliqué par la suite.

Les enregistrements de violations par étapes ne sont pas intrinsèquement suspects. Les enquêtes changent souvent les nombres à mesure que les journaux sont examinés, les comptes dormants sont rapprochés, les doublons sont supprimés et les catégories de données sont séparées. Le problème de responsabilité est de savoir si les clients peuvent comprendre la différence. Un nombre de comptes Support et Chat n'est pas la même chose qu'un nombre 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 nombre pour décrire toutes ces surfaces, les clients prendront de mauvaises décisions.

Le 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'application, le remplacement des certificats, l'impact sur les produits et les preuves de données de ticket. Le dossier serait encore plus solide si chaque nombre et classe de données étaient plus faciles à concilier dans une chronologie publique unique. La leçon n'est pas que chaque premier nombre doit être définitif. La leçon est que la raison de chaque nombre doit être claire.

L'objet de confiance était la relation de support

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

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

C'est pourquoi l'incident avait plus de poids qu'une ancienne table d'utilisateurs. Les noms d'agents et les informations de contact peuvent aider à cibler le personnel de support. Les noms d'utilisateurs finaux et les informations de contact 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'application 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 par les clients.

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

L'objet de confiance explique également pourquoi les clients avaient besoin de preuve que les données de ticket étaient délimitées. Si les données de ticket n'ont pas été consultées, la charge de travail du client reste sérieuse mais plus étroite: identifiants, applications, certificats, contacts et analyse des notifications. Si le contenu des tickets a été consulté, la charge de travail pourrait s'étendre à la notification des utilisateurs finaux, à la confidentialité des produits, aux pièces jointes, aux historiques de service et aux 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 ticket é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 toujours pertinents en 2019 car les anciens enregistrements peuvent conserver une signification opérationnelle. Le 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, les anciens enregistrements peuvent toujours contenir des noms d'utilisateur, des e-mails, des numéros de téléphone, des mots de passe hachés, des paramètres d'application ou du 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 du client. Si les 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 désidentifiés, et ce que les clients doivent faire s'ils sont consultés. Le vocabulaire de minimisation des données et de limitation de conservation de l'article 5 du RGPD est utile ici car il encadre 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établissement.

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

Les hachages de mots de passe nécessitaient un plan d'action client

Le FAQ de Zendesk indique que les mots de passe des agents et des 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. C'est mieux 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 toujours être attaqués hors ligne en fonction de la méthode de hachage, du facteur de travail, de la qualité du mot de passe de l'utilisateur et des 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 si Zendesk lui-même ne voit aucun accès lié.

Le plan de rotation des mots de passe de Zendesk a traité cette classe de risque. Le FAQ indique que la rotation s'appliquait à certains agents et utilisateurs finaux créés avant le 1er novembre 2016, pour lesquels Zendesk ne pouvait pas identifier que l'utilisateur avait changé le mot de passe depuis cette date et où l'utilisateur n'utilisait pas l'authentification unique. La rotation a également affecté 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.

Le guide d'identité numérique du NIST et l'aide-mémoire de stockage de mots de passe OWASP sont utilisés ici pour encadrer 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 que le 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 ceux qui utilisent l'authentification unique.

Le matériel d'authentification a rendu le cas plus large que les réinitialisations de mots de passe

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

Les identifiants d'application 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 lors de la prochaine connexion. Un identifiant d'application peut connecter Zendesk au CRM, à la facturation, à l'entrepôt de données, aux systèmes de messagerie, de workflow ou d'identité. Une clé privée TLS peut affecter un centre d'aide personnalisé par le client ou le mappage 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 qui avaient installé des applications du marché ou privées avant le 1er novembre 2016, et enregistré des identifiants d'authentification lors de l'installation, de faire tourner les identifiants pour les applications concernées. Il a également conseillé aux clients qui avaient 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 avec la seule rotation des mots de passe de compte.

Les applications et intégrations ont transformé le support en un 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 provenant de ces points d'extrémité sont enregistrées dans le journal d'audit pour le compte Support concerné. La documentation des requêtes d'application 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 des services tiers. La documentation de sécurité 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 de consulter 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 add-on 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 a besoin de savoir quelles applications, quels identifiants, quelles dates, quelles destinations, et si une rotation est nécessaire en dehors de Zendesk.

C'est un problème récurrent des services cloud. Les clients achètent une plateforme, puis 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 de temps, 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é. Le FAQ de Zendesk indique avoir identifié un petit groupe de clients dont les certificats TLS ont été consultés, presque tous expirés au moment du FAQ. Il a conseillé aux clients ayant des certificats téléchargés encore valides datant 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 préparer un certificat à télécharger explique que les clients peuvent avoir besoin d'identifier les fichiers de certificat, 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 des options de certificat géré 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 client pour une 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 séparé, une règle de conservation et un chemin de notification. Il ne devrait pas être enterré à l'intérieur d'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

Le FAQ de Zendesk indique n'avoir trouvé aucune preuve que les données de ticket aient été consultées en lien avec l' incident. Il 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 du compte, des problèmes de produit, 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 preuve: quels journaux ont été examinés, quelles tables de base de données étaient séparées, si les pièces jointes étaient dans le périmètre, si les transcriptions de chat différaient des tickets de support, et comment les comptes inactifs étaient mappés aux locataires actifs. Le FAQ public donne la conclusion et indique que des experts en criminalistique externes ont été engagés.

Il ne montre pas le chemin probatoire complet, et il ne peut raisonnablement pas publier chaque détail sensible.

La norme de responsabilité est de fournir suffisamment de structure pour que les clients puissent prendre leurs propres décisions juridiques et opérationnelles. Si les données de ticket sont délimitées, les clients peuvent éviter des notifications inutiles aux utilisateurs finaux. Si les données de ticket 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 changé la charge de notification

Le FAQ de Zendesk encadre expressément les clients comme responsables du traitement des données de service et Zendesk comme sous-traitant de données 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 obligations de notification à l'autorité de contrôle lorsqu'une violation de données à caractère personnel atteint le seuil légal.

Le FAQ de Zendesk a indiqué aux clients qu'il mettrait à disposition les informations dont il disposait pour les aider à faire cette détermination.

Ceci 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 les utilisateurs finaux sans savoir quelles catégories de données ont été affectées, si les données de service ont été consultées, quels agents et utilisateurs finaux étaient dans le périmètre, et si le matériel d'authentification pourrait affecter d'autres systèmes. Si le fournisseur détient ces faits et les publie lentement ou de manière ambiguë, les clients portent une incertitude juridique sans les preuves nécessaires pour la résoudre.

L'accord de traitement des données de Zendesk et les documents RGPD fournissent le contexte juridique général. 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 de preuves n'est pas une courtoisie. Cela 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. Le 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 ont été déterminées comme compromises ont été spécifiquement notifiés. Il 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é les 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 inclut plus que la séparation des bases de données. Elle inclut les limites de produit, les domaines d'authentification, les paramètres d'application, les certificats téléchargés par le client, 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 forte et bien documentée, le fournisseur peut dire aux clients pourquoi leurs données de ticket n'étaient pas dans le périmètre même si les métadonnées de compte l'étaient.

Si la segmentation est faible, les anciens enregistrements peuvent créer un rayon de souffrance inattendu.

Le dossier public n'expose pas l'architecture complète des locataires de Zendesk. C'est normal. Mais l' entreprise devait encore fournir des conclusions orientées client suffisamment spécifiques pour agir: dates des comptes affectés, noms de 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 ticket et communications spécifiques aux clients. Ce sont les sorties publiques de preuves de segmentation privées.

La reconstruction d'audit faisait partie du rétablissement, pas du travail de fond

Zendesk a indiqué avoir engagé des experts en criminalistique externes, activé son équipe de réponse à la sécurité des données, 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 ce cas, 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 en arrière à travers les journaux, les états de compte, les enregistrements de base de données, les dates d'installation d'application, les dates de téléchargement de certificat, l'historique des changements de mot de passe, les limites de produit et le statut du client.

Cette reconstruction est plus difficile que le confinement en direct. Les journaux peuvent avoir vieilli. Les comptes peuvent être inactifs. Les comptes d'essai peuvent ne plus avoir de propriétaires actifs. Les identifiants d'application peuvent avoir été remplacés, ou ils peuvent encore être utilisés silencieusement par un processus métier. Les certificats TLS peuvent avoir expiré, été renouvelés, ou 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établissement, pas comme un détail criminalistique de fond. Les clients avaient besoin de savoir quelles dates limites importaient, quelles dates d'installation déclenchaient une action, quelles classes d'identifiants nécessitaient une rotation, et quels enregistrements Zendesk avait suffisamment confiance pour exclure. Un dossier de reconstruction solide empêche à la fois une sous-réaction et une 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 d'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'application. Ces enregistrements sont utiles car ils montrent le vocabulaire de contrôle que les clients utilisent lors de l'évaluation de 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 de jetons API actuelle ne prouve pas quels jetons ou paramètres étaient présents en 2016. Une page d'aide sur les certificats actuelle ne prouve pas chaque détail de gestion des clés téléchargées par le client 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 empêche deux erreurs courantes. La première consiste à ignorer les documents actuels de l'entreprise qui nomment de véritables surfaces de confiance. La seconde consiste à traiter le langage de confiance actuel comme une réponse complète à une violation plus ancienne. La lecture mature utilise le 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é cracké. Il ne prouve pas que les identifiants d'application ont été utilisés contre des services tiers. Il ne prouve pas que les clés TLS ont été utilisées abusivement. Il ne prouve pas que les données de ticket ont été consultées.

Il ne montre pas chaque contrôle de sécurité ultérieur ou chaque interaction avec un régulateur.

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 de la législation sur la confidentialité, et si le contenu des tickets était délimité. Zendesk était mieux positionné que n'importe quel client individuel pour réduire l'incertitude sur les faits du côté du service.

La conclusion la plus forte est donc délimitée. Zendesk a dû gérer un ancien incident de compte de support, une rotation de mots de passe, une révision des identifiants d'application, un remplacement de certificat, une notification spécifique au client et une assurance de limite de ticket. Le dossier public soutient ces devoirs. Il ne soutient pas l'élargissement de l'incident à un vol non étayé de contenu de ticket ou à un compromis non étayé de tiers.

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

Un dossier public plus solide placerait les surfaces principales 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'application et des clés TLS. Il séparerait la rotation des mots de passe utilisateur de la rotation des identifiants d'application et ·du remplacement des certificats. Il séparerait les données de ticket 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 les utilisateurs finaux ont besoin de conseils sur les mots de passe. Les administrateurs Zendesk ont besoin de conseils sur les comptes et produits affectés. 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 de preuves de responsable du traitement et de sous-traitant. Les équipes de sécurité ont besoin de conseils sur l'audit, les jetons et la révision des accès.

Les dirigeants ont besoin d'une déclaration concise du risque résiduel et de l'impact client. Ces publics 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 limite de preuve. Si votre compte utilisait l'authentification 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 ticket n'étaient pas dans le périmètre, voici la classe de preuve derrière cette affirmation.

Les acheteurs devraient se renseigner sur les anciennes données de support avant le renouvellement

Les clients et acheteurs de Zendesk ne devraient pas attendre un incident pour se renseigner sur les anciennes données de support. Une plateforme de support peut accumuler silencieusement des agents, des utilisateurs finaux, des tickets, des champs personnalisés, des macros, des applications, des webhooks, des certificats, des jetons API, des clients OAuth et des enregistrements d'essai. Une partie de ces données peut être nécessaire pour l'audit, le service client ou la défense juridique. Certaines peuvent simplement subsister parce que la suppression est difficile.

Le moment du renouvellement est celui où les clients ont un 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 désidentifiés? Que se passe-t-il avec les 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 consulter les jetons OAuth et les jetons API? Comment les clés TLS téléchargées par le client 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 conflictuelles. Elles améliorent les deux côtés 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 les anciens enregistrements de support peuvent créer un nouveau travail.

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'identifiants, 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 les notifications. Quelles plateformes de support contiennent les données clients? Quelles applications ont des secrets? Quels certificats ou domaines personnalisés sont hébergés là-bas? Quels utilisateurs ont des rôles privilégiés? Quels enregistrements sont plus anciens que le besoin actuel de l'entreprise? Quelles notifications du fournisseur déclencheraient une analyse réglementaire? Quelles équipes sont responsables de la rotation des mots de passe, de la rotation des identifiants d'application et du remplacement des certificats?

Le fournisseur a également des devoirs au niveau du conseil. Il doit savoir quels anciens enregistrements subsistent, si la conservation sert un but réel, si les identifiants sont séparés, si les clés téléchargées par le client sont suivies, si les paramètres d'application sont audibles, et si les notifications 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 de violation génériques 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 aborder la protection des vérificateurs de mots de passe, le statut d'authentification unique, les comptes actifs et inactifs, et la rotation des mots de passe. Si le fournisseur héberge des tickets de support, le contrat devrait aborder les données de ticket, les pièces jointes, les champs personnalisés, la conservation, la suppression et la notification spécifique au client.

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

Le contrat devrait également spécifier les catégories de preuves après un incident. Les clients ont besoin des plages de dates affectées, des noms de produits affectés, des classes de données, des classes d'identifiants, des actions client, des surfaces exclues et des méthodes de révision. Ils ont besoin de contacts administrateur distincts des notifications utilisateur 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é les anciens comptes, le matériel d'authentification, les certificats, les paramètres d'application, la rotation des mots de passe et l'assurance de limite de ticket. Un contrat qui ne mentionne que les données personnelles peut manquer les secrets d'application. Un contrat qui ne mentionne que la disponibilité de l'application peut manquer la conservation historique. La responsabilité suit la surface qui a échoué.

Les indicateurs opérationnels rendraient les futures réclamations 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, les nombres de comptes actifs par rapport aux inactifs, les catégories agents par rapport aux utilisateurs finaux, le statut de changement de mot de passe, les exclusions d'authentification unique et le statut de rotation.

Pour le matériel d'authentification, il peut indiquer les plages de dates d'installation d'application, les types d'identifiants, les options de révision des jetons OAuth et API, les conseils pour les propriétaires d'application et les recommandations de rotation tierce. Pour le matériel TLS, il peut indiquer si les certificats sont expirés ou valides, si les clés privées étaient dans le périmètre, et comment les clients devraient les remplacer et les révoquer. Pour les données de ticket, il 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 individuelles de l'utilisateur des étapes de l'administrateur. Les utilisateurs peuvent avoir besoin de réinitialiser les mots de passe. Les administrateurs peuvent avoir besoin de lister les applications, de faire tourner les secrets, de réviser les jetons, de remplacer les certificats et de documenter l'analyse de confidentialité. Les équipes de confidentialité peuvent avoir besoin de décider si l'article 33 ou d'autres obligations de notification s'appliquent. Les équipes de sécurité peuvent avoir besoin d'inspecter les journaux pour un 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. Le FAQ de Zendesk contient de nombreuses catégories appropriées: date limite, produits affectés, règles de rotation des mots de passe, matériel d'authentification, identifiants d'application, clés TLS, limite des données de ticket, rôles de responsable du traitement et de sous-traitant, et communications spécifiques aux clients. Un dossier plus solide rendrait la chronologie et la conciliation des nombres encore plus faciles à suivre.

La question de récurrence est plus large que Zendesk

La question de 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 de longue durée d'identités, de contexte opérationnel, d'enregistrements de contact client, 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 plus large de responsabilité 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 qui sont faciles à oublier après l'installation. La dépendance au cloud donne aux fournisseurs le contrôle sur les preuves dont les clients ont besoin pour les décisions juridiques et opérationnelles.

La localisation et la souveraineté des données ajoutent une autre couche, car les clients dans différentes régions peuvent avoir des obligations de notification différentes 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 conserver que ce qui a un but. Protéger les identifiants comme si les enregistrements copiés seront attaqués. Faciliter l'inventaire des applications et des jetons. Garder les données de ticket segmentées des métadonnées de compte. Préparer des chemins de notification spécifiques aux clients avant une violation. Rendre les anciens enregistrements plus faciles à expliquer lorsque le cycle d'actualité est passé mais que le devoir du client ne l'est pas.

Le résultat net en matière de responsabilité

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

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

La conclusion de responsabilité la plus forte n'est pas que chaque dommage redouté s'est produit. La conclusion la plus forte est que les anciens enregistrements de support peuvent conserver suffisamment de valeur pour créer un nouveau travail pour le client des années plus tard. Le dossier public soutient des devoirs autour de la conservation, de la rotation des mots de passe, des identifiants d'application, du matériel TLS, de la notification aux clients et de la preuve de limite de ticket. Il soutient également la retenue autour des 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, c'est de traiter les systèmes de support comme une infrastructure de confiance client. Pour les régulateurs, c'est d'examiner si les anciens enregistrements ont été conservés, protégés et expliqués d'une manière qui permette aux responsables du traitement de prendre leurs propres décisions. Pour les clients, c'est de maintenir un inventaire des applications, certificats, jetons et rôles d'administrateur de la plateforme de support avant l'arrivée du prochain ancien incident.

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'application, des identifiants d'intégration et du matériel TLS avaient été consultés des années plus tôt, 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 ticket, la notification spécifique au client et le soutien à la décision réglementaire sans forcer chaque client à deviner à partir d'enregistrements épars?

Si la réponse est non, le dossier Zendesk reste actuel en tant que leçon de responsabilité.

La norme équitable n'est pas l'exposition publique de chaque détail technique sensible. La norme équitable est une preuve publique disciplinée. 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 évoluait. 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 n'importe quel nombre de comptes.