Résumé

  • Dossier sur la violation de données clients d'Adobe en 2013, le stockage des mots de passe, l'exposition du code source, la réinitialisation des comptes clients et la responsabilité identitaire à long terme.
  • La violation de données clients d'Adobe en 2013 a exposé des enregistrements de comptes et un risque lié au code source, tout en forçant une prise de conscience publique sur la protection des mots de passe, la notification et la réutilisation à long terme des identifiants.
  • Qui avait le contrôle effectif sur la conception du stockage des mots de passe, la protection du code source, l'avis de violation, la réinitialisation des comptes clients, la minimisation des champs exposés, les preuves de règlement et la preuve que les systèmes de comptes hérités n'ont pas continué à transférer le risque après la date de divulgation?
  • Le problème de responsabilité est que les décisions de stockage des mots de passe prises avant une violation peuvent continuer à imposer des coûts après que l'entreprise a réinitialisé les comptes et détourné l'attention publique.
  • Les clients, les développeurs, les acheteurs de logiciels, les équipes de gestion des risques d'identité, les régulateurs, les entités aux recours collectifs et les ingénieurs en sécurité avaient besoin de preuves que la réparation du système de compte a traité les risques persistants liés aux identifiants et au code source.

Pourquoi ce cas appartient à un dossier de risque et de responsabilité

Adobe a fait de la preuve du stockage des mots de passe un test de responsabilité identitaire à long terme, car la violation de 2013 n'était pas seulement un événement de divulgation. Elle est devenue une leçon publique sur la manière dont les anciens systèmes de comptes, les choix de stockage des mots de passe, la notification des clients, la garde du code source des logiciels et la dépendance identitaire à l'ère des abonnements peuvent continuer à transférer le risque après qu'une entreprise ait demandé à ses clients de réinitialiser leurs mots de passe.

La question centrale de responsabilité n'est pas de savoir si Adobe a finalement reconnu plus de comptes affectés que le premier chiffre public. Il s'agit de savoir si le dossier public a permis aux clients et aux acheteurs de logiciels de comprendre les conséquences durables de la conception du stockage et de la réparation.

Ce cas est assez ancien pour être confondu avec une simple histoire. C'est dangereux. L'ancienne annonce de sécurité client d'Adobe à l'adressehttp://blogs.adobe.com/conversations/2013/10/important-customer-security-announcement.htmlet l'annonce sur le code source à l'adressehttp://blogs.adobe.com/asset/2013/10/illegal-access-to-adobe-source-code.htmlont été les premiers enregistrements publics de la compromission des données clients et du code source des produits. Des rapports ultérieurs, y compris la couverture de la BBC à l'adressehttps://www.bbc.com/news/technology-24740873, ont décrit l'extension du nombre initial de 2,9 millions de clients affectés à environ 38 millions d'utilisateurs actifs et ont noté l'exposition du code source impliquant Photoshop ainsi que des références antérieures à Acrobat et ColdFusion. Les chiffres comptent, mais la leçon de conception compte davantage.

Le stockage des mots de passe est une décision antérieure à la violation qui ne devient publique qu'après un échec. Si une entreprise stocke les mots de passe sous une forme qui aide les attaquants à faire des suppositions, la réinitialisation n'efface pas le préjudice. Les attaquants n'ont peut-être plus besoin du service d'origine.

Ils peuvent tester les mêmes identifiants ou des identifiants similaires ailleurs, utiliser des indices de mots de passe pour déduire des schémas, combiner des adresses e-mail avec d'autres données exposées et continuer à profiter d'une conception de stockage faible longtemps après la réparation du site principal. C'est pourquoi l'article traite la violation comme un enregistrement d'identité à long terme plutôt que comme un titre de sécurité momentané.

L'exposition du code source ajoute un deuxième horizon temporel. La FAQ du SANS Internet Storm Center à l'adressehttps://isc.sans.edu/diary/The+Adobe+Breach+FAQ/16727a discuté des données clients, du code source et du contexte de ColdFusion peu après la divulgation. La couverture de sécurité de Krebs à l'adressehttp://krebsonsecurity.com/2013/10/adobe-to-announce-source-code-customer-data-breach/et d'Ars Technica à l'adressehttp://arstechnica.com/security/2013/10/adobe-source-code-and-customer-data-stolen-in-sustained-network-hack/ont également présenté l'événement comme une compromission à la fois des données clients et du code source. Le code source ne crée pas le même risque qu'une table de mots de passe, mais il peut modifier l'économie des attaquants en révélant des détails d'implémentation, des hypothèses de produit et des chemins de vulnérabilité potentiels.

Cet article ne traite pas chaque allégation secondaire comme un fait interne prouvé. Il distingue les déclarations d'Adobe, les reportages contemporains, les analyses techniques et les normes actuelles. Les pages actuelles du Trust Center d'Adobe, telles quehttps://www.adobe.com/trust.htmlethttps://www.adobe.com/trust/security.html, sont utilisées pour le vocabulaire actuel du programme de sécurité, et non comme preuve des contrôles de 2013. Les documents OWASP et NIST sont utilisés pour les principes de mots de passe et d'identité, et non comme des conclusions juridiques rétroactives. Cette discipline des sources est importante car la responsabilité à long terme dépend de la distinction entre ce qui était connu, ce qui a été rapporté plus tard et ce qui reste encore en dehors du dossier public.

Le stockage des mots de passe peut transférer des coûts après la réinitialisation

La réponse ordinaire à une base de données de mots de passe compromise est une réinitialisation. Une réinitialisation est nécessaire, mais elle ne répond pas à l'ensemble du risque. Si le stockage original des mots de passe permettait des tentatives de devinette hors ligne significatives, les attaquants peuvent apprendre les habitudes de mot de passe de l'utilisateur même après que le compte Adobe ne puisse plus être consulté avec l'ancien secret. Si le même mot de passe ou un mot de passe apparenté a été réutilisé ailleurs, les autres comptes de l'utilisateur peuvent rester exposés.

Si des indices de mot de passe étaient disponibles en clair ou sous une forme devinable, ils peuvent continuer à aider les attaquants. Le coût à long terme incombe à l'utilisateur, et non seulement à l'entreprise compromise.

L'analyse d'Ars Technica axée sur les mots de passe à l'adressehttp://arstechnica.com/security/2013/11/how-an-epic-blunder-by-adobe-could-strengthen-hand-of-password-crackers/est devenue influente parce qu'elle expliquait pourquoi la forme de la protection des mots de passe est importante. L'article ne doit pas être réduit à une réprimande technique. Il a soulevé un principe de responsabilité: la conception du stockage détermine la valeur que les attaquants peuvent extraire après l'exfiltration. Un système solide suppose que le vol de la base de données est possible et stocke les vérificateurs de mots de passe de manière à rendre le vol moins utile. Un système hérité plus faible peut transformer la base de données en un ensemble d'apprentissage pour les craqueurs de mots de passe.

La fiche OWASP sur le stockage des mots de passe à l'adressehttps://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.htmlfournit un vocabulaire moderne pour ce problème: hachage lent des mots de passe, salage, facteurs de travail, poivrage le cas échéant, et migration loin des schémas faibles. Ces concepts ne sont pas des ornements après coup. Ils définissent les preuves dont les utilisateurs et les auditeurs ont besoin. Lorsqu'une entreprise dit que les mots de passe ont été réinitialisés, le dossier public devrait encore demander quelle conception de stockage a été retirée, quelle nouvelle conception l'a remplacée, comment les anciens enregistrements ont été migrés, si les enregistrements inactifs ont été conservés et si les indices de mots de passe ou les artefacts de récupération de compte associés ont été minimisés.

Les directives actuelles du NIST sur l'identité numérique à l'adressehttps://pages.nist.gov/800-63-4/sp800-63b.htmlrenforcent le point selon lequel l'authentification est un cycle de vie. Elle comprend l'émission, la maintenance, l'invalidation, les contrôles de session et la réparation. Une réinitialisation de mot de passe est un événement dans ce cycle de vie. La récupération de compte, les options MFA, le filtrage des secrets compromis, la réauthentification et la réparation des problèmes d'authentification comptent tous après une violation. Pour Adobe, le problème à long terme est de savoir si les clients ont reçu suffisamment de preuves pour savoir jusqu'où le risque lié à leurs identifiants pourrait se propager au-delà du compte Adobe.

Le dossier public montre pourquoi "chiffré" peut être un mot insuffisant pour l'utilisateur. Le chiffrement, le hachage, le salage et les indices de mots de passe ont des conséquences différentes, mais de nombreux avis compressent ces distinctions en une large réassurance. Les utilisateurs n'ont pas besoin de cours de cryptographie, mais ils ont besoin du résultat pratique. Les attaquants peuvent-ils inverser ou deviner efficacement les anciens mots de passe? Les indices ont-ils été exposés? Les comptes inactifs ont-ils été inclus?

Les identifiants clients, les adresses e-mail, les enregistrements de paiement ou d'autres attributs étaient-ils liés au même fichier? L'avis devrait répondre à la question de risque de l'utilisateur, pas seulement à la catégorie de divulgation de l'entreprise.

L'exposition du code source transforme une violation en un problème de cycle de vie logiciel

L'événement de 2013 d'Adobe appartient également à cette série car l'exposition du code source s'étend au-delà de l'identité du client. L'ancienne annonce d'Adobe sur le code source, la FAQ du SANS, le reportage de Krebs, la couverture de la BBC et la couverture d'Ars Technica ont tous traité l'incident comme impliquant du code source pour des produits ou composants majeurs d'Adobe. Les rapports publics faisaient référence à Acrobat, ColdFusion, ColdFusion Builder, et plus tard à Photoshop.

La question de responsabilité n'est pas de savoir si l'exposition du code source crée automatiquement un exploit connu. Il s'agit de savoir si l'entreprise peut prouver que l'examen de la sécurité des produits, la réponse aux vulnérabilités et les conseils aux clients ont changé pour correspondre au nouveau risque.

Le cycle de vie des logiciels et l'enfermement sont au cœur de la surface de responsabilité d'Adobe. De nombreux clients dépendent des outils Adobe pour la production créative, les flux de travail documentaires, les formulaires du secteur public, le marketing d'entreprise et la gestion des PDF. Ils ne peuvent pas migrer instantanément après un événement de code source. Cette dépendance impose au fournisseur le devoir de fournir des preuves claires de sécurité des produits: quels produits ont été affectés, quelles branches ont été examinées, quels correctifs ou mesures de renforcement étaient importants, et comment les clients pouvaient surveiller les avis ultérieurs. L'index actuel des bulletins de sécurité d'Adobe à l'adressehttps://helpx.adobe.com/security/security-bulletin.htmlmontre le vocabulaire continu des avis et des correctifs, mais le public a besoin du pont entre un événement de code source et l'assurance ultérieure de la sécurité des produits.

La garde du code source est également un problème de gouvernance. Elle implique l'accès aux dépôts, la segmentation, la gestion des secrets, les contrôles de construction, la revue de code, la journalisation, la surveillance des accès internes et externes, et la réponse aux incidents. Les pages de sécurité actuelles d'Adobe, telles quehttps://www.adobe.com/trust/security/product-security.htmlethttps://www.adobe.com/trust/security/incident-response.html, décrivent les concepts actuels du programme de sécurité, y compris le cycle de vie sécurisé des produits et la réponse aux incidents. Elles sont utiles car elles montrent ce qu'un lecteur moderne devrait s'attendre à voir dans un dossier de preuves, même si elles ne peuvent pas prouver exactement comment les systèmes de 2013 fonctionnaient.

Le risque à long terme n'est pas que les attaquants détiennent le code source pour toujours de manière simple. C'est que les défenseurs ont besoin de l'assurance que le code exposé a été examiné sous un angle différent. Si les attaquants pouvaient inspecter les détails d'implémentation, les équipes produit devraient se demander si l'obscurité avait été traitée comme un contrôle caché, si les composants partagés nécessitaient un examen, si les directives de renforcement destinées aux clients devaient changer, et si les vulnérabilités historiques devaient être réexaminées.

La continuité du secteur public entre dans le dossier car les outils documentaires et les plates-formes d'applications web largement déployés peuvent devenir des dépendances institutionnelles. Un événement de sécurité des produits à cette échelle n'est pas un inconvénient privé.

C'est pourquoi le dossier de preuves doit relier les données clients et le code source plutôt que de les traiter comme des titres séparés. L'exposition des mots de passe affecte les utilisateurs et les équipes d'identité. L'exposition du code source affecte les développeurs, les entreprises et les acheteurs de logiciels. La même réponse à une violation a besoin de pistes distinctes, mais ces pistes devraient partager une chronologie et un propriétaire de gouvernance.

Si l'entreprise dit que les clients doivent réinitialiser les mots de passe tandis que les équipes produit examinent discrètement le code source, les observateurs extérieurs ne peuvent pas juger si l'événement a été contenu. La responsabilité exige que les deux pistes soient suffisamment visibles pour que les organisations dépendantes puissent planifier.

La qualité de l'avis détermine si les utilisateurs peuvent protéger d'autres comptes

Le problème de l'avis d'Adobe n'était pas seulement le nombre initial d'utilisateurs affectés. C'était la question pratique de ce que les utilisateurs devaient faire au-delà d'Adobe. La couverture de la BBC à l'adressehttps://www.bbc.com/news/technology-24740873a rapporté qu'Adobe avait réinitialisé les mots de passe et que les identifiants réutilisés sur d'autres services restaient un risque. C'est le cœur de la responsabilité identitaire à long terme. L'entreprise peut désactiver l'ancien mot de passe Adobe. Elle ne peut pas réinitialiser tous les autres comptes où le client l'a réutilisé. L'avis doit donc en dire suffisamment sur le risque lié aux identifiants pour inciter à une action proportionnée ailleurs.

Un avis efficace distinguerait plusieurs choses: les comptes actifs, les comptes inactifs, les identifiants clients, les adresses e-mail, les mots de passe chiffrés, les indices de mots de passe, les données de carte de paiement, l'exposition du code source et l'état de la réinitialisation. Il expliquerait également ce que l'entreprise ne pouvait pas encore valider. Dans un incident en évolution rapide, les chiffres peuvent changer. Cela ne rend pas la divulgation précoce inutile. Cela signifie que la divulgation précoce doit être explicite quant à l'incertitude. Un utilisateur peut comprendre qu'un nombre peut augmenter.

L'utilisateur ne peut pas bien agir si un avis réduit toute incertitude à une déclaration confiante mais incomplète.

Les directives de la FTC sur la réponse aux violations à l'adressehttps://www.ftc.gov/business-guidance/resources/data-breach-response-guide-businesssont utiles car elles traitent l'avis comme faisant partie de la réponse, et non des relations publiques. Le guide de la FTC sur les informations personnelles à l'adressehttps://www.ftc.gov/business-guidance/resources/protecting-personal-information-guide-businesssouligne également la minimisation et les mesures de protection avant l'incident. Pour Adobe, le problème pour les utilisateurs est de savoir si l'avis a traduit les faits techniques en étapes: réinitialiser le mot de passe Adobe, changer les mots de passe réutilisés ailleurs, surveiller les comptes de paiement, faire attention aux tentatives de phishing et comprendre ce que l'exposition du code source signifiait ou non pour les utilisateurs des produits.

La même logique s'applique aux entités aux recours collectifs et aux régulateurs. Les processus juridiques se concentrent souvent sur la qualité pour agir, les dommages, le règlement et les preuves procédurales. Ces enregistrements comptent, mais ils ne remplacent pas les preuves techniques. Les clients devaient comprendre le risque continu pour leurs identités et leurs comptes. Les régulateurs devaient comprendre si la conception du stockage, les enregistrements inactifs, les indices de mots de passe et les pratiques de notification correspondaient à des attentes de sécurité raisonnables.

Les acheteurs de logiciels devaient comprendre si l'examen de la sécurité des produits avait atteint le code affecté. Un seul canal de divulgation sert rarement tous ces publics à moins qu'il ne soit délibérément structuré.

La norme de notification devrait donc être mesurée par les décisions en aval. Un client pouvait-il déterminer s'il devait changer les mots de passe sur d'autres services? Une équipe d'identité d'entreprise pouvait-elle décider de rechercher la réutilisation des mots de passe Adobe dans les comptes d'entreprise? Un développeur pouvait-il décider de surveiller les avis Adobe de plus près? Un acheteur du secteur public pouvait-il poser les bonnes questions sur les achats et les correctifs? Si l'avis ne soutenait pas ces décisions, il laissait le risque à long terme en dehors du cadre de responsabilité de l'entreprise.

Les enregistrements inactifs font des systèmes hérités une partie du préjudice

Les enregistrements inactifs sont un problème récurrent dans les violations d'anciens comptes. Les rapports de la BBC indiquaient qu'Adobe croyait que les attaquants avaient accédé à des détails de comptes inutilisés depuis deux ans ou plus en plus des utilisateurs actifs. Ce fait est important car les comptes inactifs reçoivent souvent moins d'attention de la part des entreprises et des utilisateurs.

Un utilisateur peut ne pas se souvenir d'un ancien identifiant Adobe, ne pas surveiller son adresse e-mail, avoir réutilisé le mot de passe il y a des années et ne pas comprendre pourquoi un ancien compte de logiciel créatif crée un risque d'identité actuel. Les choix de conservation et de migration de l'entreprise façonnent donc l'exposition actuelle de l'utilisateur.

Les systèmes de comptes hérités compliquent également la réparation. Si un ancien système de stockage de mots de passe était prévu pour le retrait ou ne faisait pas partie du chemin d'authentification actuel, l'entreprise doit encore prouver que les enregistrements de ce système ne peuvent pas continuer à fuir de la valeur. Mettre un système à la retraite après une violation ne suffit pas si des copies héritées, des sauvegardes, des journaux, des indices ou des comptes inactifs subsistent.

Le dossier public devrait indiquer comment les anciens magasins ont été inventoriés, comment ils ont été protégés, comment ils ont été supprimés ou migrés, et comment l'entreprise a vérifié qu'aucun enregistrement de justificatif d'identité parallèle ne continuait à présenter un risque.

La souveraineté et la localisation des données apparaissent ici comme des préoccupations pratiques de gouvernance des enregistrements. Adobe servait des clients à l'échelle mondiale, et les enregistrements d'identité peuvent traverser les frontières des produits, des abonnements, du support, des paiements et des régions. Un client dans une juridiction peut avoir des droits de notification différents de ceux d'une autre, mais le risque technique d'un indice de mot de passe ou d'un mot de passe réutilisable ne respecte pas cette frontière.

Un dossier de responsabilité à long terme devrait expliquer les catégories de données de manière à ce qu'elles voyagent. Il ne devrait pas exiger que chaque juridiction, client ou acheteur reconstruise la conception du stockage à partir de fragments.

Le cadre de cybersécurité du NIST à l'adressehttps://www.nist.gov/cyberframeworket les contrôles CIS à l'adressehttps://www.cisecurity.org/controlsoffrent une façon de réfléchir à cela sans faire d'affirmations non étayées sur les systèmes internes d'Adobe. L'inventaire, la gestion des identités, la protection des données, la journalisation, la réponse aux incidents et la récupération sont tous pertinents. Un examen du conseil d'administration devrait demander si l'entreprise peut énumérer les anciens magasins de comptes, identifier ceux qui contiennent du matériel d'authentification, nommer les propriétaires, documenter la raison de la conservation et prouver que les magasins obsolètes ont été éliminés ou renforcés.

Le cas Adobe reste utile car il montre comment une violation peut révéler l'archéologie d'un système de comptes. Les entreprises modernisent souvent les portes d'entrée tandis que les anciens magasins d'enregistrements restent au sous-sol. Les clients ne peuvent pas voir ce sous-sol. Ils n'en apprennent l'existence que lorsqu'un incident l'expose. Cette asymétrie est la raison pour laquelle les systèmes hérités ont besoin d'une responsabilité publique lorsqu'ils créent un risque actuel.

Les normes ne sont pas un verdict, mais elles définissent les preuves de réparation

Les normes modernes de stockage des mots de passe ne doivent pas être utilisées paresseusement comme un verdict rétroactif sur un système de 2013. La technologie change, les modèles de menace changent et les directives publiques évoluent. Mais les normes restent nécessaires car elles définissent à quoi devraient ressembler les preuves de réparation maintenant. Les directives d'OWASP sur les mots de passe à l'adressehttps://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html, les directives du NIST sur l'identité à l'adressehttps://pages.nist.gov/800-63-4/sp800-63b.html, les directives de la CISA sur la sécurité dès la conception à l'adressehttps://www.cisa.gov/securebydesignet les pages actuelles du programme de sécurité d'Adobe montrent ensemble le vocabulaire d'un dossier de réparation plus solide.

Les preuves de réparation devraient répondre à plusieurs questions. Quel schéma de stockage des mots de passe était impliqué? Était-il à sens unique, salé, lent et réglé pour résister aux attaques hors ligne? Les indices de mots de passe étaient-ils stockés, et si oui, pourquoi? Les comptes inactifs étaient-ils conservés avec les mêmes données que les comptes actifs? Les anciens systèmes ont-ils été mis hors service ou simplement cachés des chemins de connexion ordinaires? La réinitialisation a-t-elle invalidé les sessions et les jetons? Les utilisateurs ont-ils été invités à changer les mots de passe réutilisés ailleurs?

Les administrateurs d'entreprise ont-ils reçu des indicateurs pour rechercher l'exposition? Les équipes de sécurité des produits ont-elles reçu des exigences d'examen du code source?

Ces questions sont des questions de preuves, pas des accusations. Une entreprise peut y répondre de manière à protéger les détails d'implémentation sensibles. Elle peut décrire des classes de systèmes, des étapes de correction, des jalons de migration et une assurance externe sans publier de recettes d'exploitation. Ce qu'elle ne devrait pas faire, c'est demander aux clients d'accepter "nous avons réinitialisé les mots de passe" comme la réparation complète. Une réinitialisation est visible.

La migration du stockage, la minimisation des indices, le nettoyage des comptes inactifs et l'examen du code source sont moins visibles. C'est précisément pourquoi ils ont besoin de preuves responsables.

Le dossier public devrait également distinguer les documents de normes des obligations légales. Les guides de la FTC sont des conseils aux entreprises. Les documents du NIST et de la CISA sont des normes ou des directives publiques. OWASP est un guide de sécurité communautaire. Le Trust Center d'Adobe est rédigé par l'entreprise. Aucune de ces sources n'est à elle seule une conclusion judiciaire.

Mais leur chevauchement est utile: l'authentification forte, le stockage solide des mots de passe, la minimisation, la réponse aux incidents, la sécurité des produits et la réparation apparaissent tous comme des thèmes de contrôle durables. Un article sur la responsabilité à long terme utilise ce chevauchement pour définir le dossier de réparation que les clients méritaient.

Cette approche évite une erreur courante dans l'écriture rétrospective sur les violations. Elle ne dit pas: "Voici une liste de contrôle moderne, donc l'ancienne entreprise a échoué sur chaque point." Elle dit: "Voici les preuves qui seraient maintenant nécessaires pour montrer que le risque a cessé de se transférer." La distinction est importante. La responsabilité n'est pas seulement un jugement moral sur le passé. C'est une demande de preuve que les anciens choix de conception ne nuisent plus aux personnes qui ne peuvent pas inspecter le système elles-mêmes.

La confiance dans les produits et la confiance dans l'identité ont évolué ensemble

La violation d'Adobe était importante parce que la confiance dans les produits et la confiance dans l'identité ont évolué ensemble. Les clients utilisaient les comptes Adobe pour l'accès aux logiciels, la gestion des abonnements, les paiements, les mises à jour, le support et l'identité. Les développeurs et les entreprises dépendaient des produits Adobe pour les flux de travail documentaires et créatifs. Les organisations du secteur public dépendaient des formats et des outils Adobe à travers les formulaires, les enregistrements et la communication.

Lorsque les données clients et le code source sont apparus dans le même cadre d'incident public, l'entreprise a dû protéger à la fois la couche identité et la couche produit.

Cette double surface de confiance est visible dans les pages actuelles d'Adobe. Le Trust Center à l'adressehttps://www.adobe.com/trust.htmlmet l'accent sur la sécurité, la confidentialité, la disponibilité, la conformité et les ressources produit. L'aperçu de la sécurité à l'adressehttps://www.adobe.com/trust/security.htmltraite du cycle de vie sécurisé des produits, de la sécurité opérationnelle, de la réponse aux incidents et des bulletins de sécurité. La page de réponse aux incidents à l'adressehttps://www.adobe.com/trust/security/incident-response.htmldécrit l'approche actuelle de la surveillance et de la résolution des incidents. La page de sécurité des produits à l'adressehttps://www.adobe.com/trust/security/product-security.htmldécrit des processus de développement reproductibles. Ces pages sont actuelles, et non des preuves de 2013. Elles montrent néanmoins la structure de preuve intégrée à laquelle un acheteur de logiciel moderne devrait s'attendre.

Un acheteur devrait pouvoir demander: si les mots de passe des clients ont été exposés, qu'est-ce qui a changé dans les systèmes d'identité? Si le code source du produit a été consulté, qu'est-ce qui a changé dans l'examen de la sécurité des produits? Si les anciens systèmes contenaient du matériel de mot de passe, qu'est-ce qui a changé dans la gestion du cycle de vie? Si les clients ont dû réinitialiser leurs identifiants, quels conseils les ont aidés à gérer la réutilisation ailleurs?

Si l'ancien code ou les anciens magasins de comptes ont créé un risque après la date de divulgation, quelles preuves ont clos la traîne? La confiance dans les produits et la confiance dans l'identité ne peuvent pas être séparées lorsque le même compte déverrouille les logiciels, les paiements, le support, les mises à jour et l'administration d'entreprise.

C'est également là que le cycle de vie des logiciels et l'enfermement deviennent des sujets de responsabilité plutôt que des abstractions commerciales. Les clients ne peuvent souvent pas quitter rapidement un fournisseur de logiciels de base. Leurs fichiers, flux de travail, formation du personnel, intégrations et calendriers d'approvisionnement les maintiennent dépendants. Cet enfermement accroît le devoir du fournisseur de fournir des preuves utilisables après une violation. Un client qui ne peut pas facilement partir doit savoir comment continuer à utiliser le produit en toute sécurité.

Un avis vague rend l'enfermement plus coûteux car il laisse le client dépendant inventer son propre plan d'assurance.

Le cas Adobe reste donc pertinent pour les logiciels en nuage et par abonnement aujourd'hui. Les systèmes de comptes accumulent d'anciennes données. Les dépôts de code source et les systèmes de construction deviennent des cibles de grande valeur. Les clients s'appuient sur des couches d'identité contrôlées par le fournisseur. Les utilisateurs du secteur public dépendent des formats de fichiers et des canaux de mise à jour.

Une violation qui expose le matériel de compte et le code source du produit devient un test de la capacité du fournisseur à convertir la réparation privée en assurance publique sans exposer de nouveaux détails sensibles.

La longue traîne est l'endroit où la responsabilité est généralement perdue

Le risque d'identité à long terme est difficile à gouverner car il survit au calendrier des incidents. L'entreprise peut terminer une réinitialisation, clore une enquête, mettre à jour une page de sécurité des produits et publier de nouveaux avis, tandis que les clients continuent de porter des habitudes d'identifiants apprises par les attaquants à partir de l'ancien ensemble de données. C'est pourquoi le cas Adobe reste précieux. Il montre que l'unité de responsabilité n'est pas seulement la base de données compromise.

C'est la chaîne de décisions ultérieures que les clients, les entreprises et les équipes de sécurité doivent prendre avec une connaissance partielle de ce que la base de données a révélé.

La longue traîne modifie également le sens du préjudice. Un utilisateur peut ne pas perdre d'argent à cause du compte Adobe lui-même. L'utilisateur peut plutôt recevoir du phishing ciblé, découvrir qu'un ancien mot de passe a été réutilisé dans un service non lié, passer du temps à examiner les enregistrements de paiement ou faire partie d'un corpus de craquage de mots de passe qui améliore les attaques contre d'autres personnes. Ces coûts sont diffus et difficiles à quantifier, mais ils ne sont pas imaginaires.

Ils découlent du fait que le matériel de mot de passe, les adresses e-mail, les indices et l'historique des comptes peuvent être recombinés après le verrouillage du compte d'origine.

Les entreprises sont confrontées à un problème parallèle. Une équipe d'identité d'entreprise peut avoir des employés qui ont utilisé des adresses e-mail professionnelles pour des comptes Adobe ou réutilisé des mots de passe apparentés. L'équipe doit savoir s'il faut rechercher des secrets compromis, forcer les réinitialisations, vérifier les exceptions d'authentification unique, avertir le personnel ou surveiller les campagnes de phishing. Cette décision dépend de la qualité des preuves publiques.

Si l'avis d'un fournisseur explique seulement que les mots de passe ont été réinitialisés, il laisse les équipes d'entreprise déduire le reste. Si l'avis explique la conception du stockage, les populations affectées, les enregistrements inactifs et les actions recommandées pour les entreprises, il devient une entrée de contrôle utilisable.

Les acheteurs du secteur public ont une autre dépendance. Les outils Adobe sont souvent intégrés dans les flux de travail documentaires, le traitement des formulaires, la production créative, les dossiers d'approvisionnement et les communications publiques. Un événement de code source peut ne pas obliger chaque agence à cesser d'utiliser le produit, mais il devrait déclencher des questions sur les avis, la cadence des mises à jour, les contrôles compensatoires et l'assurance du fournisseur. Le fournisseur responsable n'a pas à publier de détails sensibles sur le code.

Il doit donner aux clients une base raisonnée pour continuer leurs opérations en toute sécurité.

La longue traîne est l'endroit où la responsabilité est généralement perdue parce que tout le monde est fatigué à ce moment-là. La presse est passée à autre chose, le dossier juridique est lent, les utilisateurs ont réinitialisé les mots de passe et les équipes produit sont retournées au travail prévu. Mais les attaquants ne se soucient pas du calendrier des incidents. Ils se soucient des secrets réutilisables, de la connaissance du code et des contrôles de suivi faibles.

Un dossier de réparation mature a donc besoin d'une phase de maintenance: des conseils actualisés pour les clients, des notes pour les administrateurs d'entreprise, un suivi de la sécurité des produits et la confirmation que les anciens magasins ont été nettoyés plutôt que simplement oubliés.

Les preuves devraient voyager des équipes de sécurité aux clients

Une autre leçon du cas Adobe est que le travail de sécurité privé doit être traduit sans être vidé de sa substance. Les équipes de sécurité peuvent savoir quels magasins ont été exposés, quel schéma cryptographique a été utilisé, quels dépôts de code ont été atteints, quels groupes de clients ont été notifiés et quels systèmes ont été mis hors service. Les clients n'ont pas besoin des détails internes bruts, mais ils ont besoin d'une version publique précise de ces faits. Si la traduction supprime les distinctions qui comptent, l'avis devient moins utile que les preuves privées qui l'ont produit.

La traduction devrait être délibérément stratifiée. La première couche est destinée aux utilisateurs individuels: réinitialiser le mot de passe Adobe, changer les mots de passe réutilisés ailleurs, être attentif au phishing, surveiller les instruments de paiement si pertinent et comprendre si les données de carte de paiement étaient impliquées. La deuxième couche est destinée aux administrateurs d'entreprise: identifier les domaines de messagerie d'entreprise affectés, évaluer la réutilisation des identifiants, surveiller les échecs de connexion, communiquer avec le personnel et suivre les avis du fournisseur.

La troisième couche est destinée aux acheteurs de logiciels: poser des questions sur l'examen du code source, les changements de développement sécurisé, la cadence des bulletins et les engagements de support. La quatrième couche est destinée aux régulateurs et aux tribunaux: conserver les dates, les chiffres, les catégories de données, les enregistrements de notification et les preuves de remédiation.

Chaque couche devrait conserver les mêmes faits avec différents niveaux de détails techniques. C'est la meilleure façon d'éviter les contradictions. Si les utilisateurs sont simplement invités à réinitialiser les mots de passe tandis que les administrateurs sont informés que le code source a été exposé, le dossier public semble fragmenté. Si les avocats décrivent le matériel de mot de passe comme chiffré tandis que les analystes de sécurité expliquent pourquoi la conception a tout de même facilité le craquage, le public peut entendre à la fois réassurance et alarme.

Un dossier de responsabilité solide rend ces déclarations compatibles en expliquant la conséquence pratique de chaque terme.

Le langage actuel du Trust Center d'Adobe est pertinent car il montre que les entreprises comprennent désormais l'assurance comme un produit public. Les descriptions du programme de sécurité, les pages de réponse aux incidents, les pages de sécurité des produits et les index de bulletins font partie de la manière dont les acheteurs jugent la confiance. La leçon de 2013 est que ces systèmes d'assurance publics devraient être prêts avant qu'une violation ne les oblige à porter une histoire complexe. Une page de confiance qui n'existe que pour les ventes ne peut pas faire le travail.

Une page de confiance liée aux preuves, aux avis et aux propriétaires responsables le peut.

Le dossier de réparation devrait donc être conçu comme un pipeline de preuves. Les constatations internes de l'investigation deviennent des catégories de clients. Les catégories de clients deviennent des avis et des conseils pour les administrateurs. Les constatations de sécurité des produits deviennent des avis et des changements de cycle de vie. Les enregistrements juridiques deviennent une responsabilité procédurale sans remplacer le dossier technique. Les normes deviennent des références pour l'assurance future.

Lorsque ce pipeline est manquant, chaque public construit sa propre interprétation et l'entreprise perd le contrôle de la signification publique de sa réparation.

Un dossier de réparation complet d'Adobe préserverait la traîne

Un dossier de réparation complet commencerait par une chronologie validée. Il énumérerait quand l'intrusion a été détectée, quand l'exposition des données clients a été confirmée, quand l'accès au code source a été confirmé, quand les chiffres des personnes affectées ont changé, quand les réinitialisations de mots de passe ont eu lieu, quand les avis aux clients ont été émis, quand les enregistrements inactifs ont été évalués et quand les examens de sécurité des produits ou les avis ont suivi. Chaque date devrait identifier les preuves disponibles à ce moment-là. Le but n'est pas de punir l'incertitude précoce.

C'est d'empêcher les résumés ultérieurs d'effacer l'incertitude qui a façonné les décisions des clients.

La deuxième partie serait un enregistrement de la conception du stockage. Il expliquerait le système de stockage des mots de passe impliqué, le traitement des sels, les facteurs de travail, le chiffrement ou le hachage, les indices de mots de passe, les enregistrements inactifs et la migration vers un stockage plus solide. Il décrirait également quels magasins hérités ont été mis hors service, quelles sauvegardes ont été conservées et comment l'ancien matériel de justificatif d'identité a été rendu moins utile. Les clients n'ont pas besoin des détails secrets de mise en œuvre.

Ils ont besoin d'avoir confiance que l'ancienne conception a cessé de transférer le risque.

La troisième partie serait un enregistrement des actions pour les clients. Il séparerait les réinitialisations de compte Adobe du risque de réutilisation de mots de passe ailleurs. Il donnerait aux administrateurs d'entreprise des conseils pour rechercher l'exposition des identifiants d'entreprise. Il donnerait aux clients individuels des conseils clairs sur le changement des mots de passe réutilisés, la surveillance des comptes de paiement et la résistance au phishing basé sur la violation. Il expliquerait si la surveillance du crédit ou l'aide contre le vol d'identité s'appliquait à des populations spécifiques.

Il préserverait les différences entre l'exposition des cartes de paiement, l'exposition des identifiants de compte, l'exposition des mots de passe et l'exposition du code source.

La quatrième partie serait un enregistrement de la sécurité des produits. Il expliquerait quels dépôts de code source de produits ont été impliqués, quelles gammes de produits ont été examinées, quels avis ou correctifs étaient liés le cas échéant, et comment les clients devraient surveiller les futurs bulletins. Il expliquerait également ce qui n'était pas connu. L'exposition du code source n'est pas la même qu'une vulnérabilité confirmée dans chaque produit. Mais cela change la charge de l'assurance.

Un fournisseur de logiciels devrait être en mesure de montrer qu'il a examiné le code et le pipeline de développement en tenant compte de l'exposition.

Enfin, le dossier de réparation devrait avoir une norme de clôture. La clôture ne devrait pas signifier que l'attention du public s'est déplacée ou que la première réinitialisation de mot de passe est terminée. La clôture devrait signifier que les anciens magasins de comptes ont été inventoriés, que la conception du stockage a été renforcée, que les enregistrements inactifs ont été traités, que l'exposition du code source du produit a été examinée, que des conseils aux clients ont été fournis et que l'incertitude restante a été nommée.

Pour Adobe, la leçon à long terme est que les preuves de stockage des mots de passe doivent survivre au cycle de l'actualité.

Dossier de preuves pour le lecteur

L'article utilise les sources publiques suivantes comme dossier de lecture pour la violation de données clients d'Adobe en 2013, le stockage des mots de passe, l'exposition du code source, la réinitialisation des comptes clients et l'enregistrement de la responsabilité identitaire à long terme. Les annonces de l'entreprise sont traitées comme des preuves de ce qu'Adobe a déclaré publiquement à l'époque. Les actualités et les analyses de sécurité sont utilisées pour la chronologie et le contexte technique.

Les pages actuelles de confiance de l'entreprise et les directives des normes sont utilisées pour définir les preuves de réparation modernes plutôt que pour prouver les contrôles internes de 2013.

Ce dossier de preuves est délibérément plus large qu'une seule annonce car le problème de la longue traîne englobe le stockage des mots de passe, les enregistrements inactifs, la garde du code source, la réinitialisation des comptes, l'assurance produit et la dépendance des acheteurs de logiciels. Le dossier public devrait permettre aux lecteurs de séparer la réparation de l'identité client de la réparation de la sécurité des produits sans prétendre que ces tâches ne sont pas liées.

Questions pour l'examen du conseil d'administration

Un examen du conseil d'administration devrait demander qui était propriétaire des magasins de comptes hérités, qui était propriétaire de la migration du stockage des mots de passe, qui était propriétaire de l'avis aux clients, qui était propriétaire de l'accès aux dépôts de code source, qui était propriétaire de l'examen de la sécurité des produits, qui était propriétaire des conseils aux entreprises clientes et qui était propriétaire de la clôture. La réponse devrait être une carte de contrôle, pas un récit d'efforts.

Les cartes de contrôle rendent plus difficile pour les anciens systèmes de rester le risque de tous et le devoir de personne.

L'examen devrait également exiger des preuves que les enregistrements inactifs sont gouvernés. Les anciens comptes, les anciennes sauvegardes, les anciens indices et les anciens magasins d'authentification devraient avoir des propriétaires, des raisons de conservation, des normes de protection et des dates de suppression. Si un passage de produit à l'abonnement augmente la valeur de l'identité du compte, l'entreprise devrait revisiter les anciens magasins avant que les attaquants ne le fassent. Hérité ne signifie pas inoffensif.

Le conseil d'administration devrait exiger un manuel de réponse à l'exposition du code source. Il devrait définir l'isolement des dépôts, la rotation des identifiants et des secrets, les déclencheurs de revue de code, les règles d'avis aux clients, l'examen du renforcement des produits et les preuves pour les clients dépendants. Un événement de code source peut ne pas nécessiter de détails publics sur chaque dépôt interne, mais il nécessite une assurance suffisante pour les clients qui doivent continuer à utiliser le logiciel.

Pour ce cas spécifique, un examen du conseil d'administration devrait demander si qui avait le contrôle effectif sur la conception du stockage des mots de passe, la protection du code source, l'avis de violation, la réinitialisation des clients, la minimisation des champs exposés, les preuves de règlement et la preuve que les systèmes de comptes hérités n'ont pas continué à transférer le risque après la date de divulgation?

La réponse devrait inclure des preuves datées, des propriétaires nommés, une preuve de migration du stockage des mots de passe, un nettoyage des enregistrements inactifs, un examen de la sécurité des produits, des conseils d'action pour les clients et une incertitude résiduelle qui n'a pas disparu lorsque la première réinitialisation a été terminée.