Adobe a fait des codes source et des données clients un test commun de responsabilité des identifiants

Résumé

• Adobe a déclaré publiquement en octobre 2013 que des attaquants avaient accédé aux identifiants clients d'Adobe, aux mots de passe chiffrés, à certains champs de commande et de carte de paiement, ainsi qu'au code source de plusieurs produits.
• La question centrale de responsabilité est la suivante: qui avait le contrôle effectif sur le hachage des mots de passe, le périmètre des données de paiement, l'accès au référentiel de code source, les directives de réinitialisation des clients, le calendrier des notifications de brèche et la preuve que le code volé n'élargissait pas le risque pour les clients?
• Les informations publiques se sont ensuite élargies au-delà du premier décompte de clients d'Adobe, KrebsOnSecurity rapportant la confirmation par Adobe d'environ 38 millions d'utilisateurs actifs avec des mots de passe chiffrés valides concernés, et Have I Been Pwned listant 152,4 millions de comptes affectés dans son corpus de brèches.
• Les clients, développeurs, administrateurs d'entreprise, équipes de réponse aux cartes de paiement et réviseurs de sécurité des produits ont dû agir sans voir les journaux internes du référentiel d'Adobe, la conception du stockage des mots de passe, les preuves du système de paiement ou la cartographie d'exposition client par client.
• Les éléments disponibles soutiennent une conclusion de responsabilité à haute confiance concernant les devoirs de contrôle et les lacunes probantes. Ils ne permettent pas d'inventer des faits privés sur chaque système interne, chaque étape de l'attaque, chaque version de produit, chaque perte client ou chaque modification de référentiel.

Enregistrement des preuves et leur utilisation

Cet article traite les informations publiques comme des preuves stratifiées plutôt que comme un récit unique complet. Les documents d'entreprise et gouvernementaux sont utilisés pour ce qu'Adobe Inc. ou les autorités publiques ont déclaré. Les documents de règlement des régulateurs, les recherches en sécurité, les index publics de brèches, les normes de paiement, les directives de sécurité logicielle et les directives de stockage des mots de passe sont utilisés pour encadrer les devoirs de contrôle, la chronologie et les implications pour les parties affectées.

L'analyse ne traite pas les rapports secondaires comme une preuve de faits privés que les informations publiques ne montrent pas.

Le cadre de responsabilité est plus étroit que le blâme et plus large que l'avis de brèche

Adobe a fait du code source et des enregistrements clients un test commun de responsabilité des identifiants, car le cas ne se situait pas dans une seule catégorie. Ce n'était pas seulement une brèche de comptes, pas seulement un événement de carte de paiement, et pas seulement un incident de code source. Dans son avis, Adobe a déclaré que des attaquants avaient accédé aux identifiants clients et aux mots de passe chiffrés, avaient supprimé certains champs clients et de carte de paiement pour 2,9 millions de clients, et avaient accédé au code source de plusieurs produits.

La CISA a répété la préoccupation concernant les informations clients et le code source dans une alerte publique. Des rapports publics ultérieurs et des enregistrements d'index de brèches ont rendu l'image des données de comptes plus large que le premier nombre. Cette séquence est importante car la responsabilité dans un service cloud ne se mesure pas seulement à la première déclaration. Elle se mesure à la capacité de l'opérateur à réduire les incertitudes au fur et à mesure que les clients, les banques, les développeurs, les administrateurs et les régulateurs prennent des décisions.

Le blâme est généralement trop grossier pour cet enregistrement. Une analyse utile de la responsabilité demande qui avait l'autorité, les preuves, les outils et le devoir de réduire le risque à chaque étape. Adobe contrôlait le système d'identité, l'avis client, la campagne de réinitialisation des mots de passe, la révision du code source et la déclaration publique sur le chiffrement des cartes de paiement. Les processeurs de paiement et les banques contrôlaient une partie de la surveillance des cartes et de la protection des clients.

Les clients contrôlaient la réutilisation des mots de passe, les réinitialisations de comptes et leur propre suivi de sécurité local. Les chercheurs et les journalistes ont fourni des preuves externes qui ont modifié la compréhension publique de l'événement. Les régulateurs ont ensuite testé si des mesures raisonnables existaient avant et pendant l'attaque.

Le point central est le contrôle pratique. Les clients ne pouvaient pas inspecter la conception du stockage des mots de passe d'Adobe, les journaux du référentiel ou le réseau de traitement des paiements. Ils ne pouvaient que répondre aux instructions et aux preuves qu'Adobe a mises dans le domaine public. Lorsqu'un fournisseur détient les faits et que les clients détiennent une grande partie du travail, le fournisseur a le devoir de rendre les informations claires, structurées et vérifiables.

Ce que les informations publiques établissent

Les informations publiques établissent plusieurs points solides. Dans son propre avis, Adobe a déclaré que son équipe de sécurité avait découvert des attaques impliquant un accès illégal à des informations clients et au code source. Il a indiqué que des attaquants avaient accédé aux identifiants clients et aux mots de passe chiffrés.

Il a indiqué que l'entreprise pensait que des attaquants avaient supprimé les noms, les numéros de carte de crédit ou de débit chiffrés, les dates d'expiration et les informations relatives aux commandes pour 2,9 millions de clients, mais qu'Adobe ne croyait pas que des numéros de carte déchiffrés aient quitté ses systèmes. Adobe a annoncé qu'il réinitialisait les mots de passe des clients concernés, informait les clients dont les informations de carte étaient présumées impliquées, offrait une surveillance du crédit là où c'était disponible, informait les banques de paiement et collaborait avec les forces de l'ordre.

Adobe a également déclaré qu'à sa connaissance, sur la base des conclusions alors disponibles, il n'y avait pas de risque accru spécifique pour les clients résultant de l'accès au code source.

Les autorités publiques et les enregistrements externes ajoutent d'autres couches. La CISA a averti les clients de surveiller les activités frauduleuses sur leurs comptes. Le rapport initial de KrebsOnSecurity a décrit un trésor de code source et a rapporté des déclarations d'Adobe lors d'entretiens sur l'enquête, l'ensemble de produits potentiel et l'examen de l'intégrité des produits.

KrebsOnSecurity a ensuite rapporté la confirmation par Adobe que des attaquants avaient obtenu l'accès aux identifiants Adobe et aux mots de passe chiffrés valides d'environ 38 millions d'utilisateurs actifs, avec des données supplémentaires de comptes inactifs, invalides et de test encore en cours d'examen. Have I Been Pwned a ensuite listé la brèche Adobe comme 152,4 millions de comptes affectés et a identifié les e-mails, noms d'utilisateur, mots de passe et indices de mots de passe. Les procureurs généraux des États ont ensuite annoncé un règlement multi-états résolvant les réclamations découlant de la brèche de 2013.

Ces points sont suffisamment solides pour analyser les devoirs. Ils ne suffisent pas pour affirmer des faits privés qui restent en dehors des informations publiques. Les informations publiques ne montrent pas chaque base de données affectée, chaque chemin d'accès interne, chaque événement de référentiel, chaque détail de contrôle des mots de passe ou chaque résultat client. Cette incertitude n'est pas une raison pour ignorer le cas. C'est la raison pour se concentrer sur ce qu'une partie dépendante avait besoin qu'Adobe prouve.

Pourquoi l'objet de confiance est important

L'objet de confiance dans ce cas n'était pas un seul fichier. C'était un ensemble d'identité de compte Adobe, de gestion des données de paiement et de gestion des sources logicielles. Les clients faisaient confiance aux identifiants Adobe pour protéger l'accès à leurs relations créatives, documentaires, de développement, commerciales et de support. Les banques et les réseaux de cartes faisaient confiance à Adobe pour savoir si les numéros de carte étaient chiffrés, si les numéros de carte déchiffrés étaient exclus et quels processeurs devaient être avertis.

Les développeurs et les acheteurs d'entreprise faisaient confiance à Adobe pour savoir si le code source volé des produits modifiait la probabilité de futures exploitations ou de versions falsifiées. Cet ensemble d'objets de confiance est plus large qu'une base de données clients.

L'objet de confiance large explique pourquoi l'événement a eu une persistance. Une brèche de comptes peut être traitée avec des réinitialisations de mots de passe, une surveillance de la fraude et des avertissements de réutilisation. Un événement de carte de paiement appelle une coordination avec les banques et les réseaux de cartes, des preuves du périmètre des données et un avis client. L'accès au code source pose une question différente: les attaquants pouvaient-ils étudier les détails d'implémentation, les contrôles de sécurité, la logique de construction ou les secrets intégrés d'une manière qui modifie le risque futur?

Adobe n'avait pas besoin de publier des détails sensibles de criminalistique pour satisfaire tous les clients, mais il devait expliquer les limites de ces objets de confiance suffisamment bien pour que d'autres puissent agir.

C'est là qu'un test commun de responsabilité des identifiants devient visible. Le mot identifiant ne doit pas être lu seulement comme un mot de passe. Les identifiants peuvent inclure les mots de passe, les indices de mots de passe, la gestion des jetons de paiement, l'accès au référentiel de code source, les secrets de service, les contrôles de signature ou de construction, et les assurances qui permettent à un administrateur d'entreprise de continuer à faire confiance à un fournisseur de logiciels. Les informations publiques montrent clairement les côtés mot de passe et code source. Elles laissent de nombreux détails de preuve privés.

Le stockage des mots de passe a fait de l'identité client la première charge de travail pratique

La première action d'Adobe orientée client a été une campagne de réinitialisation de mots de passe pour les comptes concernés. C'était le bon type de protection immédiate des clients, mais cela a également exposé une question plus profonde: pourquoi le magasin d'identifiants était-il un objet de risque réutilisable après le vol? Adobe a qualifié les mots de passe de chiffrés dans son annonce. Une analyse publique ultérieure s'est concentrée sur le risque créé par l'approche de stockage des mots de passe et les indices de mots de passe en texte clair.

Have I Been Pwned décrit un corpus ultérieur contenant des identifiants d'enregistrements clients, des noms d'utilisateur, des adresses e-mail, des mots de passe chiffrés et des indices, avec une cryptographie de mot de passe faible qui a rendu de nombreux mots de passe plus faciles à résoudre. L'analyse publique de l'ensemble de données par Troy Hunt a souligné que les indices peuvent révéler le secret même que le mécanisme de mot de passe est censé protéger.

La question de responsabilité n'est pas seulement de savoir si les mots de passe ont été réinitialisés. La réinitialisation est une réponse. Le stockage des identifiants est une prévention. Les clients n'avaient aucun moyen pratique de choisir la méthode de hachage d'Adobe, l'utilisation du sel, le facteur de travail, la conception des indices, la pratique de conservation ou le système de vérificateur. Ils ne pouvaient qu'éviter la réutilisation des mots de passe, répondre aux avis de réinitialisation et changer les mots de passe ailleurs. Cela signifie que le devoir de contrôle d'Adobe se situait en amont de l'utilisateur.

Une bonne pratique de stockage des mots de passe traite la base de données volée comme un scénario à prévoir, et non comme un cas limite à gérer après coup.

Les directives modernes du NIST et de l'OWASP aident à expliquer la classe de contrôle. Un fournisseur détenant des vérificateurs de comptes doit les protéger avec des conceptions destinées à résister aux attaques hors ligne et doit éviter les modèles de récupération de compte qui révèlent les secrets de l'utilisateur. Le cas Adobe de 2013 reste utile car il montre le coût de traiter les enregistrements d'identifiants comme des données de compte ordinaires. Une fois copié, l'ensemble de données devient une aide à l'attaque à long terme sur plusieurs services, surtout là où les utilisateurs ont réutilisé des mots de passe.

Le périmètre des cartes de paiement nécessitait des preuves, pas seulement des assurances

L'avis initial d'Adobe a séparé les données de carte chiffrées des données de carte déchiffrées. Cette distinction était centrale. L'entreprise a déclaré que des attaquants avaient supprimé les numéros de carte de crédit ou de débit chiffrés, les dates d'expiration et les informations de commande pour 2,9 millions de clients, mais qu'Adobe ne croyait pas que des numéros de carte déchiffrés aient été supprimés. Adobe a également indiqué avoir informé les banques qui traitaient les paiements clients afin qu'elles puissent travailler avec les sociétés de cartes et les banques émettrices.

Les informations publiques ont donc placé le risque de paiement dans une case plus étroite que le risque des données de comptes, mais cette case nécessitait toujours des preuves.

La responsabilité des données de paiement ne s'arrête pas au mot chiffré. Les questions de responsabilité sont: quels systèmes détenaient les données de carte, quels champs étaient stockés, comment les clés de chiffrement étaient protégées, si les attaquants pouvaient tenter un déchiffrement, si les processeurs et les acquéreurs ont reçu suffisamment de détails, et à quels clients on a dit de surveiller les abus.

L'annonce du règlement du procureur général de l'Ohio a ensuite décrit une conclusion selon laquelle Adobe avait appris qu'un attaquant tentait de décoder les numéros de carte de paiement clients chiffrés et que l'attaquant avait compromis un serveur web et l'avait utilisé pour accéder à d'autres serveurs. Ce récit réglementaire public a rendu l'histoire du contrôle des paiements plus concrète que le seul premier avis.

Les documents PCI DSS sont utiles ici non pas parce qu'ils décident de la responsabilité d'Adobe dans cet article, mais parce qu'ils nomment l'écosystème. Les entités qui stockent, traitent, transmettent ou peuvent affecter les données des titulaires de carte se trouvent dans un réseau de commerçants, processeurs, acquéreurs, émetteurs et prestataires de services. Dans ce réseau, les preuves de paiement d'un fournisseur de logiciels cloud ne sont pas seulement pour son dossier juridique. Elles sont la base de la surveillance en aval, des avis clients, des décisions de remplacement de carte et de la réponse à la fraude.

Le code source était un risque de confiance produit, pas seulement une propriété intellectuelle

Le vol de code source est souvent présenté comme un vol de propriété d'entreprise. Dans ce cas, la question du risque client était plus large. Les produits d'Adobe incluaient des logiciels largement déployés dans les domaines créatif, documentaire, serveur et d'application web. KrebsOnSecurity a rapporté que le matériel de code source exposé semblait inclure ColdFusion et Acrobat, avec des rapports ultérieurs suggérant que le code source de Photoshop était également concerné. HKCERT a averti que l'accès illégal au code source pouvait aider les attaquants à étudier les produits et à trouver des vulnérabilités sur une plus longue période.

Dans son avis, Adobe a déclaré qu'à sa connaissance, il n'y avait pas de risque accru spécifique pour les clients résultant de l'incident de code source, sur la base des conclusions alors disponibles.

L'écart entre ces déclarations est l'espace de responsabilité. Il est possible que du code source soit volé sans prouver de versions falsifiées, d'exploits zero-day ou de compromission de clients. Il est également possible que du code source volé augmente le risque futur en donnant aux attaquants une meilleure connaissance des détails d'implémentation, des hypothèses de sécurité et des éléments internes des produits. Un enregistrement public responsable n'a pas besoin de publier les détails sensibles du code source.

Il doit dire comment l'entreprise a vérifié l'intégrité des constructions, l'accès au référentiel, les validations anormales, les secrets intégrés et l'historique des versions du produit.

Le cadre de développement sécurisé de logiciels du NIST aide à nommer les devoirs du producteur. Protéger les logiciels inclut la protection des environnements de développement et des artefacts logiciels contre la falsification et l'accès non autorisé. Répondre aux vulnérabilités inclut l'identification des faiblesses résiduelles et la communication avec les consommateurs. Les pages ultérieures d'Adobe PSIRT et de bulletins de sécurité montrent la structure continue par laquelle les clients reçoivent des informations de sécurité produit.

La question de 2013 était de savoir si les preuves du code source derrière cette confiance étaient suffisamment solides pour les clients dépendants.

L'horloge de notification a changé ce que les clients pouvaient faire

La chronologie des notifications est importante car la divulgation transfère le travail. La première annonce publique d'Adobe est intervenue le 3 octobre 2013. L'alerte de la CISA le même jour a poussé la sensibilisation publique vers les clients. Le premier avis donnait un premier nombre de clients et décrivait les réinitialisations de mots de passe, les notifications aux banques de paiement et la révision du code source.

Plus tard en octobre, KrebsOnSecurity a rapporté la confirmation par Adobe qu'environ 38 millions d'utilisateurs actifs avec des mots de passe chiffrés valides étaient concernés, ainsi que des données de comptes inactifs, invalides et de test encore en cours d'enquête. Have I Been Pwned a ensuite reflété un corpus de brèches publiques beaucoup plus large.

Cet élargissement ne signifie pas automatiquement que le premier avis était mauvais. Les premiers avis sont souvent progressifs car les entreprises ne connaissent pas encore toute l'étendue. Mais une notification progressive a un devoir de clarté. Les clients ont besoin de savoir quels faits sont confirmés, lesquels sont encore en cours de mesure et quelles actions doivent être entreprises avant même que le nombre final ne soit connu. Le premier avis d'Adobe avertissait correctement les clients de changer les mots de passe réutilisés ailleurs.

Ce conseil était particulièrement important car les informations publiques ultérieures ont mis en évidence un large corpus d'identifiants et des indices de mots de passe.

La norme de responsabilité n'est pas la perfection instantanée. C'est une communication opportune qui se met à jour au fur et à mesure que les preuves se consolident. Un client essayant de protéger un identifiant Adobe, un mot de passe réutilisé ou un parc logiciel d'entreprise avait besoin de savoir s'il devait traiter l'événement comme un problème étroit de carte de paiement, un problème large d'identité, un problème de source produit, ou les trois. La réponse est devenue les trois, avec différents niveaux de preuve pour chaque partie.

Les directives de réinitialisation des clients étaient nécessaires mais incomplètes par conception

Les réinitialisations de mots de passe sont l'une des rares actions client qu'un fournisseur peut prendre immédiatement. Adobe a réinitialisé les mots de passe des clients concernés et a demandé aux utilisateurs de changer les mots de passe sur d'autres sites web où le même identifiant et mot de passe avaient été utilisés. Ces directives abordaient le préjudice aval le plus prévisible: la réutilisation des identifiants. Les directives révèlent également l'asymétrie d'une brèche de compte cloud. Adobe détenait le magasin d'identités. Les utilisateurs portaient la charge de changer les mots de passe réutilisés sur l'ensemble d'Internet.

Les directives de réinitialisation sont nécessaires car elles transforment un avis abstrait en action. Elles sont incomplètes par conception car elles ne peuvent pas dire à chaque client où il a réutilisé un mot de passe, si un indice a exposé un autre secret, si un ancien compte était toujours significatif, ou si un administrateur d'identité d'entreprise avait des comptes dormants liés à l'approvisionnement, aux licences ou au support. Pour les consommateurs, le travail était une hygiène de sécurité personnelle.

Pour les organisations, le travail pouvait inclure un inventaire des comptes, une révision par l'administrateur, des vérifications du fournisseur d'identité, une communication avec le service d'assistance et une éducation des utilisateurs.

La qualité des directives de réinitialisation doit être jugée sur le fait qu'elles disent aux gens quoi faire maintenant, quoi surveiller plus tard et quelle incertitude demeure. L'avis d'Adobe comprenait des instructions de réinitialisation immédiates, des avertissements de réutilisation et un contexte de surveillance des paiements.

Les enregistrements publics ultérieurs montrent pourquoi un enregistrement de sécurité de compte plus solide aurait aidé: les clients avaient besoin de comprendre les indices de mots de passe, les catégories de comptes, les enregistrements actifs par rapport aux inactifs, et la différence entre la première population de cartes affectées et le corpus plus large de données de comptes.

Les administrateurs d'entreprise avaient un problème différent de celui des clients individuels

Un client individuel pouvait changer un mot de passe Adobe et surveiller un compte de carte. Un administrateur d'entreprise devait poser un ensemble différent de questions. Quels identifiants Adobe étaient liés aux licences logicielles, à l'approvisionnement, au support, au stockage cloud, aux flux de travail de publication, à la collaboration créative ou aux comptes de développeur? Des comptes d'administrateur étaient-ils concernés? La réutilisation de mot de passe reliait-elle les comptes Adobe aux e-mails d'entreprise, aux chemins de récupération d'authentification unique ou aux portails fournisseurs?

Les équipes de support étaient-elles préparées au phishing faisant référence à la brèche? Les employés étaient-ils formés pour éviter les faux liens de réinitialisation?

Les informations publiques ne fournissaient pas une carte administrative par locataire, et elles ne pouvaient pas le faire dans un avis général. Mais l'incident montre pourquoi les clients d'entreprise ont besoin d'avis de fournisseurs qui séparent les conseils de niveau consommateur des preuves de niveau administrateur. Les réinitialisations de mots de passe sont importantes, mais les entreprises ont également besoin d'inventaires de comptes, d'exposition basée sur les rôles, de changements d'authentification, de notification de domaine et d'un moyen de confirmer si les comptes privilégiés étaient concernés.

Ces besoins étaient particulièrement aigus car Adobe n'était pas simplement un site web occasionnel. C'était un fournisseur de logiciels avec des comptes cloud, des outils créatifs, des outils documentaires et des dépendances de sécurité produit.

La question de responsabilité est donc partagée mais inégale. Adobe détenait les faits sur la brèche. Les clients d'entreprise détenaient les faits sur leur propre utilisation de compte. Un enregistrement partagé plus solide relierait les deux: critères de comptes affectés, conseils aux administrateurs, schémas de phishing suspectés et déclarations claires sur ce qu'Adobe pouvait et ne pouvait pas vérifier. Sans cela, les clients doivent traduire un avis général en leur propre plan de contrôle.

La souveraineté et la localisation des données sont apparues à travers le réseau de notifications

L'enregistrement Adobe était mondial, même si une grande partie de l'enregistrement public d'application de la loi était nord-américain. Adobe avait des clients dans toutes les régions, gammes de produits et lignes de service. La CISA a publié une alerte américaine. HKCERT a publié un avis à Hong Kong avertissant les utilisateurs du même événement, y compris le risque de phishing et le risque à long terme posé par le vol de code source. Les procureurs généraux des États ont ensuite résolu les réclamations de protection des consommateurs et de vie privée dans un règlement multi-états.

Le résultat est un exemple utile de la façon dont une brèche de service cloud traverse les systèmes de responsabilité locaux.

La souveraineté des données dans ce cas ne concerne pas seulement l'endroit où les octets se trouvaient. Elle concerne l'autorité publique qui avait la capacité d'avertir les personnes affectées, les lois qui régissaient la notification, les clients qui ont reçu une surveillance du crédit, les banques ou réseaux de cartes qui ont agi, et les organismes de sécurité régionaux qui ont traduit l'événement en conseils. Le client voit un seul compte Adobe. L'enregistrement de responsabilité passe par l'avis de l'entreprise, l'alerte cyber fédérale, l'action du régulateur étatique, les reportages indépendants et les conseils du CSIRT régional.

Ce schéma est important pour tout service cloud mondial. L'architecture interne d'un fournisseur peut être centralisée, distribuée ou externalisée, mais les parties affectées reçoivent le risque par des canaux locaux. Elles ont besoin d'un avis qui survive à travers ces canaux. Si une entreprise déclare que les données de carte sont chiffrées, les régulateurs locaux et les banques ont encore besoin de suffisamment de preuves pour décider comment agir.

Si une entreprise déclare que le code source n'a pas créé de risque accru spécifique, les organismes de sécurité régionaux ont encore besoin de suffisamment de contexte pour avertir les utilisateurs sans créer une certitude erronée.

Les reportages secondaires ont modifié l'enregistrement utile

Le rôle de KrebsOnSecurity dans l'enregistrement Adobe est important car la compréhension publique de la brèche n'a pas été construite uniquement à partir de l'annonce d'Adobe. Le rapport initial de Krebs décrivait la découverte d'un important trésor de code source et rapportait des déclarations d'Adobe lors d'entretiens sur l'enquête. Le suivi ultérieur de Krebs rapportait qu'Adobe avait confirmé qu'environ 38 millions d'utilisateurs actifs avec des mots de passe chiffrés valides étaient concernés et qu'il enquêtait encore sur les données de comptes inactifs, invalides et de test.

Have I Been Pwned et Troy Hunt ont ensuite donné au public une vue durable des données de comptes et des indices de mots de passe.

Cela ne fait pas des sources secondaires un substitut aux propres preuves d'Adobe. Cela montre pourquoi les reportages indépendants et les index de brèches peuvent être essentiels dans un incident à forte asymétrie. Les clients apprennent souvent la forme d'un événement à travers un mélange de déclarations de l'entreprise, de conclusions de journalistes, de données publiques de brèches et d'alertes gouvernementales. Lorsque ces sources divergent, le fournisseur devrait les réconcilier d'une manière compréhensible pour les parties affectées.

Si le premier nombre de clients est de 2,9 millions pour les enregistrements liés aux paiements et qu'un nombre ultérieur d'utilisateurs actifs est beaucoup plus grand pour les identifiants de comptes, la différence devrait être expliquée en termes simples.

Le cas Adobe est donc aussi un cas de communication. Un fournisseur doit s'attendre à ce que des preuves externes contestent ou affinent sa première déclaration. La bonne réponse n'est pas la défensive. C'est une carte plus précise des catégories de données, du statut des comptes, de la validité des mots de passe, du périmètre des cartes de paiement, du périmètre du code source et des inconnues restantes.

La charge de la preuve du code source est différente de celle des identifiants

La preuve des identifiants est souvent concrète. Un fournisseur peut dire quels comptes avaient des vérificateurs de mots de passe valides, quels mots de passe ont été réinitialisés, quels indices étaient présents et quels clients ont été notifiés. La preuve du code source est plus difficile. Les preuves pertinentes peuvent inclure les journaux d'accès au référentiel, les instantanés de code source, les systèmes de construction, la signature des versions, l'examen des validations anormales, l'analyse des secrets, les tests de sécurité des produits et la recherche de vulnérabilités. Une grande partie de ces preuves est sensible.

Pourtant, la décision de risque du client dépend de la conclusion.

La première déclaration d'Adobe indiquait qu'à sa connaissance, il n'y avait pas de risque accru spécifique pour les clients résultant de l'accès au code source. KrebsOnSecurity rapportait qu'Adobe examinait le code ColdFusion livré et recherchait une activité anormale dans le référentiel. HKCERT notait la déclaration d'Adobe selon laquelle les produits ColdFusion publiés après l'incident n'avaient pas été contaminés et qu'Adobe n'avait pas connaissance d'exploits zero-day ciblant les produits Adobe à partir de la fuite de code source. Ces déclarations publiques sont utiles, mais ce sont encore des conclusions.

Les clients ne pouvaient pas voir indépendamment les vérifications sous-jacentes.

La voie responsable consiste à divulguer les classes de preuves sans exposer la preuve elle-même. Un producteur de logiciels peut dire si les sorties de construction ont été comparées, si les clés de signature ont été rotées, si les identifiants du référentiel ont été invalidés, si les secrets ont été analysés, si les branches affectées ont été examinées et si les produits vulnérables ont reçu des tests supplémentaires. Ce type de déclaration donne aux acheteurs un moyen de juger la conclusion sans transformer l'avis en manuel pour attaquant.

L'action du régulateur a maintenu le cas en vie après le cycle médiatique

Le règlement multi-états annoncé en 2016 montre que l'événement Adobe ne s'est pas terminé lorsque les réinitialisations de mots de passe ont été envoyées. Les régulateurs ont examiné si des mesures raisonnables protégeaient les systèmes contre l'attaque et si l'attaque avait été détectée assez rapidement.

L'annonce du procureur général de l'Ohio indiquait que le règlement résolvait les réclamations de quinze États et exigeait qu'Adobe mette en œuvre de nouvelles politiques et pratiques, évalue régulièrement les pratiques de sauvegarde, se conforme aux lois étatiques de consommation et verse un total d'un million de dollars aux procureurs généraux entités.

Les documents réglementaires ont une fonction différente de celle des avis de brèche. Un avis de brèche dit aux clients quoi faire pendant l'incident. Un règlement teste l'environnement de contrôle antérieur et le dossier de remédiation ultérieur. Cette différence est centrale pour la responsabilité. Une entreprise peut gérer un avis compétemment et encore faire face à des questions sur la question de savoir si la brèche aurait dû être empêchée ou détectée plus tôt. Une entreprise peut également faire face à des conclusions réglementaires sans que chaque préjudice allégué ne soit prouvé comme une perte client.

Pour les clients et les conseils d'administration, la vie après le régulateur donne une deuxième couche de preuves. Elle confirme que les autorités publiques ont considéré l'événement comme une question de gouvernance et de protection des consommateurs, et non seulement une intrusion technique. Elle montre également pourquoi une analyse fondée sur des sources ne devrait pas figer le cas au premier avis.

Le dossier complet de responsabilité comprend la première déclaration, les mises à jour ultérieures du périmètre, les preuves indépendantes de brèche, les conseils aux clients, les alertes publiques et les résultats d'application de la loi ultérieurs.

Ce que les informations publiques ne prouvent pas

Un article soigneux devrait nommer ce qu'il ne sait pas. Les informations publiques ne prouvent pas chaque étape de l'attaquant à l'intérieur du réseau d'Adobe. Elles ne prouvent pas le vecteur initial exact. Elles n'exposent pas chaque base de données, référentiel, identifiant, serveur ou enregistrement client. Elles ne montrent pas le plan complet de migration du stockage des mots de passe après l'incident. Elles ne montrent pas chaque artefact de révision de code source ou chaque vérification d'intégrité de construction. Elles ne prouvent pas que le code source volé a produit une exploitation spécifique ultérieure.

Elles ne prouvent pas que chaque client a subi un préjudice.

Ces limites sont importantes car l'écriture sur les brèches oscille souvent entre réassurance et spéculation. La position la plus utile est plus étroite: les informations publiques sont suffisantes pour identifier les devoirs de contrôle et les lacunes probantes, mais pas suffisantes pour inventer des faits privés. Les propres déclarations d'Adobe peuvent être utilisées comme des assertions publiques. KrebsOnSecurity peut être utilisé comme un reportage indépendant et une chronologie. HIBP peut être utilisé comme une référence de corpus de brèches. Les avis de règlement d'État peuvent être utilisés comme des documents réglementaires.

Les normes peuvent être utilisées pour définir des classes de contrôle raisonnables. Aucune de ces sources ne doit être étirée au-delà de ce qu'elle peut montrer.

Cette discipline est particulièrement nécessaire lorsque du code source est impliqué. Une brèche de code source peut sembler catastrophique même lorsqu'aucune version falsifiée n'est montrée. Elle peut aussi être matériellement risquée même lorsque la première déclaration de l'entreprise indique qu'aucun risque accru spécifique n'est connu. La réponse responsable n'est pas de choisir un extrême. C'est d'exiger des preuves sur la limite.

La récupération nécessitait plus que la restauration des comptes

La récupération de cet événement avait au moins quatre pistes. La première était la récupération d'identité: réinitialiser les mots de passe, avertir de la réutilisation, supprimer ou neutraliser les artefacts de récupération de compte faibles, et communiquer avec les titulaires de comptes actifs et inactifs. La deuxième était la récupération des paiements: définir le périmètre des données de carte, contacter les banques de paiement, coordonner avec les sociétés de cartes et les émetteurs, offrir une surveillance là où c'était disponible, et soutenir l'avis client.

La troisième était la récupération logicielle: examiner l'accès au code source, vérifier le code livré et l'intégrité des constructions, enquêter sur l'activité anormale du référentiel, et communiquer les conclusions sur le risque produit. La quatrième était la récupération de gouvernance: documenter ce qui a échoué, améliorer les contrôles, satisfaire les régulateurs, et créer un dossier que les conseils et les clients pouvaient tester ultérieurement.

Les informations publiques montrent des preuves des quatre pistes mais pas tous les détails. Adobe a décrit les réinitialisations de mots de passe, les notifications aux banques de paiement, l'avis client, le contact avec les forces de l'ordre, la surveillance du crédit et la révision du code source. Les reportages ultérieurs et les documents réglementaires montrent que les pistes des données de comptes et de la gouvernance se sont poursuivies.

Les pages actuelles PSIRT et d'avis d'Adobe montrent l'infrastructure continue par laquelle les mises à jour de sécurité produit sont communiquées, bien que ces pages ne prouvent pas par elles-mêmes la remédiation interne de 2013.

Le dossier de récupération le plus solide est falsifiable. Les clients devraient pouvoir vérifier que leur mot de passe a été réinitialisé, que les critères d'avis de carte ont été appliqués, que les mises à jour de produit ont été publiées, que des conseils aux administrateurs étaient disponibles, et que le fournisseur avait une base raisonnée pour dire que le vol de code source avait ou non affecté le risque client. La récupération n'est pas seulement le retour de l'entreprise à la normale. C'est le client sachant ce que la normale signifie désormais.

Un dossier public plus solide aurait séparé chaque surface affectée

Un dossier public plus solide aurait rendu les surfaces de données plus faciles à séparer. Il distinguerait les clients de cartes de paiement des détenteurs d'Adobe ID. Il distinguerait les comptes actifs, inactifs, invalides et les données de comptes de test. Il distinguerait les mots de passe chiffrés des indices de mots de passe et expliquerait le risque client créé par chaque catégorie. Il identifierait quels produits ont eu un accès au code source à un niveau de classe et quels contrôles ont été effectués pour évaluer la falsification ou le risque d'exploitation future.

Il séparerait les faits confirmés des faits encore en cours d'examen.

Le dossier aurait également bénéficié de conseils par rôle client. Les consommateurs ont besoin de conseils sur les mots de passe et les cartes. Les administrateurs d'entreprise ont besoin de conseils sur l'inventaire des comptes et les rôles privilégiés. Les développeurs et les équipes de sécurité ont besoin de conseils sur les mises à jour de produit et le contexte d'assurance du code source. Les partenaires de paiement ont besoin du périmètre des données, des fenêtres de temps et des preuves soutenant les exclusions de cartes déchiffrées.

Les organismes régionaux ont besoin d'un compte concis qu'ils peuvent traduire en avertissements locaux. Un avis unique peut commencer le processus, mais il ne devrait pas être l'ensemble du processus.

Ce n'est pas une demande de divulgation illimitée. C'est une demande de structure utilisable. Les fournisseurs de logiciels à haute confiance peuvent divulguer les catégories, les chronologies, les méthodes de révision, les actions clients, les exclusions et l'incertitude sans exposer les détails sensibles. Plus le fournisseur est central dans les flux de travail des clients, plus cette structure doit être solide.

Leçons pour la dépendance aux services cloud

Le cas Adobe est un cas de dépendance aux services cloud car un compte chez un fournisseur de logiciels peut devenir une dépendance d'identité, une dépendance de paiement, une dépendance de support et une dépendance de confiance produit à la fois. Les clients n'avaient pas besoin d'héberger la base de données de comptes d'Adobe pour hériter du travail de la brèche. Les développeurs n'avaient pas besoin de gérer les référentiels de code source d'Adobe pour hériter des questions d'assurance du code source. Les banques n'avaient pas besoin d'exécuter les systèmes commerciaux d'Adobe pour hériter des tâches de surveillance.

C'est le point de la dépendance cloud: l'opérateur centralise le contrôle, et les parties affectées reçoivent ensuite les conséquences.

La responsabilité partagée devrait donc être spécifique. Les clients sont responsables des mots de passe uniques, de l'authentification multi-facteurs là où elle est disponible, de l'inventaire des identités et de la surveillance locale. Adobe était responsable de la conception des vérificateurs de mots de passe, de la minimisation des données, du contrôle d'accès au référentiel, de la protection des données de paiement, d'un avis clair et des limites de preuve. Les partenaires de paiement étaient responsables des devoirs de réponse aux cartes qu'ils contrôlaient.

Les régulateurs étaient responsables de tester si les normes de protection des consommateurs avaient été respectées. Traiter tout cela comme un vague modèle de responsabilité partagée obscurcit qui pouvait réellement faire quoi.

La leçon d'achat est claire. Un client de service cloud ne devrait pas seulement demander si un fournisseur a une page de sécurité. Le client devrait demander comment le fournisseur gère le stockage des identifiants, la définition du périmètre des brèches, l'avis aux administrateurs, la protection du code source, l'assurance des mises à jour de produit et les preuves prêtes pour le régulateur. Ces questions ne sont pas théoriques. Le dossier d'Adobe de 2013 montre à quelle vitesse ces surfaces peuvent converger.

Le cycle de vie logiciel et la dépendance ont changé le levier de récupération

Les produits d'Adobe se trouvaient à l'intérieur des flux de travail des clients. Les équipes créatives, les équipes documentaires, les développeurs, les administrateurs web et les acheteurs d'entreprise ne pouvaient pas simplement cesser de dépendre d'Adobe du jour au lendemain parce qu'un avis de brèche était apparu. Cette dépendance change la norme de responsabilité. Lorsque les clients ne peuvent pas sortir rapidement, l'explication du fournisseur doit être plus forte. Elle doit permettre aux clients de continuer à fonctionner tout en prenant des décisions de risque rationnelles.

Le risque du cycle de vie logiciel est également plus long que le risque de réinitialisation de compte. Un mot de passe peut être changé en quelques minutes. L'exposition du code source peut influencer la révision de la sécurité produit pendant des mois ou des années si elle révèle des détails d'implémentation ou des pratiques de développement. L'accès au référentiel peut également soulever des questions sur les secrets intégrés, l'historique des branches et les contrôles de construction.

La position publique d'Adobe était qu'il n'avait pas connaissance de risque accru spécifique pour les clients résultant de l'accès au code source, et les reportages publics décrivaient une activité de révision. La question de responsabilité non résolue est le niveau de preuve que les clients pouvaient voir pour cette conclusion.

Le langage du cadre de développement sécurisé de logiciels du NIST est utile car il traite la production sécurisée de logiciels comme un cycle de vie géré. Protéger les artefacts logiciels, les environnements de développement et les versions n'est pas seulement une préférence d'ingénierie. C'est un devoir d'assurance pour l'acheteur. Dans une relation logicielle verrouillée, les clients ont besoin de preuves que le fournisseur peut protéger le logiciel avant la sortie et prouver ce qui s'est passé après un incident.

Les conseils d'administration devraient traiter la conception des identifiants comme une question de gouvernance

Le stockage des identifiants peut sembler technique jusqu'à ce qu'une brèche oblige les dirigeants à l'expliquer aux clients, aux banques, aux régulateurs et au public. Le dossier d'Adobe montre pourquoi les conseils d'administration devraient traiter la conception des identifiants comme une question de gouvernance. La différence entre le chiffrement réversible, des vérificateurs de mots de passe correctement protégés, des indices faibles, des flux de réinitialisation solides et le support multi-facteurs affecte le préjudice client et la crédibilité de l'entreprise.

Ce sont des conséquences au niveau du conseil, même lorsque les détails de conception sont techniques.

Un conseil d'administration n'a pas besoin de choisir un algorithme de hachage de mot de passe. Il doit demander si les identifiants stockés de l'entreprise résisteraient à une attaque hors ligne après un vol de base de données, si les indices de mot de passe ou les questions de récupération révèlent des secrets, si les anciens comptes sont minimisés et si les comptes de test sont gouvernés.

Il doit demander si les systèmes d'identité sont segmentés des systèmes de paiement, si les plans d'avis de brèche distinguent les populations d'utilisateurs et si l'entreprise peut envoyer rapidement des conseils de réinitialisation fiables sans former les clients à cliquer sur des liens non sécurisés.

Le même conseil devrait demander comment le code source est protégé. Qui peut accéder aux référentiels? Comment les secrets sont-ils gardés hors du code? Les systèmes de construction sont-ils isolés? Les clés de signature sont-elles protégées? Les validations anormales sont-elles examinées? L'entreprise peut-elle prouver l'intégrité des versions après un accès non autorisé? Le cas Adobe est utile car il réunit à la fois l'identité et le code source. Un conseil qui les traite séparément manquera comment une seule intrusion peut rendre les deux publics.

Les acheteurs devraient demander des preuves avant l'événement

Les acheteurs demandent souvent des preuves d'incident seulement après une brèche. Le dossier Adobe suggère plusieurs questions qui devraient être posées avant la signature du contrat ou le renouvellement. Comment les mots de passe et les vérificateurs de comptes sont-ils protégés? Des indices de mot de passe ou des questions secrètes sont-ils utilisés? Comment le fournisseur notifie-t-il les comptes actifs et inactifs? Comment le fournisseur sépare-t-il les données de paiement des données d'identité? Qui reçoit les avis aux administrateurs? Quelles preuves sont partagées lorsqu'un référentiel de code source est accédé?

Comment les systèmes de construction, la signature des versions et les mises à jour de produit sont-ils protégés? Quels canaux de support sont utilisés pour que les clients puissent éviter le phishing après une brèche?

Ces questions devraient apparaître dans les discussions d'approvisionnement, de révision de sécurité et de renouvellement car les clients perdent du levier une fois qu'un incident est en cours. Pendant une brèche, le fournisseur est concentré sur le confinement et la révision juridique, et les clients essaient de protéger les opérations. Avant une brèche, un acheteur peut exiger des engagements de notification, des listes de contacts administrateurs, des conseils basés sur les rôles, des avenants de sécurité, des droits d'audit et des catégories de preuves post-incident. L'objectif n'est pas d'exiger chaque détail interne.

L'objectif est de définir le paquet de preuves qui sera utile en cas de défaillance.

Pour un fournisseur de logiciels avec des dépendances majeures de comptes et de produits, ce paquet de preuves devrait couvrir les identifiants, les données de paiement, le code source, l'avis client et l'intégrité des mises à jour de produit. Le dossier d'Adobe de 2013 reste une raison compacte pour laquelle les cinq devraient être dans la même conversation d'achat.

Le langage contractuel devrait suivre la surface exposée

Les clauses de brèche génériques sont trop minces pour un cas comme celui-ci. Le langage contractuel devrait suivre la surface exposée. Si des données de comptes clients sont stockées, le contrat devrait traiter de la protection des vérificateurs de comptes, de l'avis aux administrateurs, des devoirs de réinitialisation des mots de passe et des journaux d'identité. Si des données de paiement sont traitées, il devrait traiter des limites de l'environnement des données de carte, de la coordination avec les processeurs, du chiffrement et des preuves de gestion des clés, et de l'avis client.

Si le code source ou les systèmes de construction de produit sont matériels pour le service, il devrait traiter du contrôle d'accès au référentiel, de l'intégrité des constructions, de la signature des versions, de la révision des produits vulnérables et des avis produit destinés aux clients.

Une clause utile n'exige pas que le fournisseur révèle des secrets qui créeraient plus de risque. Elle exige que le fournisseur partage suffisamment de preuves pour que le client puisse agir. Cela signifie des catégories, des chronologies, des systèmes affectés, des actions clients, des exclusions, des méthodes de révision et des contrôles modifiés. Cela signifie aussi des voies d'escalade. Les personnes qui reçoivent un avis de réinitialisation consommateur ne sont pas les mêmes que celles qui ont besoin d'un briefing d'administrateur d'entreprise ou d'une note d'assurance de sécurité produit.

L'événement Adobe montre pourquoi cela est important. Le même incident public a touché les comptes consommateurs, la réponse aux cartes de paiement, l'identité d'entreprise, la révision du code source, l'assurance du cycle de vie logiciel et la surveillance réglementaire. Un langage contractuel qui ne mentionne que les données personnelles peut manquer le risque du code source. Un langage contractuel qui ne mentionne que les correctifs de sécurité peut manquer la réutilisation des identifiants. La responsabilité exige de nommer les surfaces avant qu'elles ne défaillent.

Indicateurs opérationnels qui rendraient les réclamations vérifiables

Plusieurs indicateurs rendraient les affirmations de récupération d'un fournisseur plus faciles à tester sans exposer de détails sensibles. Pour les données de comptes, le fournisseur peut identifier les classes de comptes affectés, le statut de réinitialisation des mots de passe, si des indices ou des données de récupération ont été exposés, si des comptes dormants étaient inclus et si les options multi-facteurs ont changé. Pour les données de paiement, le fournisseur peut indiquer les catégories de champs, les limites de chiffrement, la base de séparation des clés, les notifications aux processeurs et les critères d'avis client.

Pour le code source, le fournisseur peut indiquer les classes de référentiels, les familles de produits, les vérifications d'intégrité des constructions, le statut des clés de signature, les résultats d'analyse des secrets par catégorie et si les mises à jour de produit ont été accélérées.

Ces indicateurs ne sont pas exotiques. Ils sont ce dont les clients ont besoin pour réduire les conjectures. Une petite entreprise a besoin de savoir si le personnel doit changer les mots de passe réutilisés. Une banque a besoin de savoir si la surveillance des cartes est suffisante ou si un remplacement de carte est probable. Un réviseur de sécurité logicielle a besoin de savoir si les cycles de correctifs futurs méritent une attention supplémentaire. Une autorité cyber régionale a besoin de savoir si elle doit avertir du phishing, des mises à jour de produit, de la fraude aux paiements, ou des trois.

Le dossier public d'Adobe contient certains de ces indicateurs, mais pas tous. Il nommait les réinitialisations de mots de passe, les étapes d'avis de carte, le contact avec les forces de l'ordre, le contact avec les banques de paiement et la révision du code source. Des sources ultérieures ont nommé une population de comptes plus large et le risque des indices de mots de passe. Un dossier plus solide rassemblerait ces pièces en une carte de preuves claire.

La question de récurrence est plus large qu'Adobe

La question de récurrence n'est pas de savoir si Adobe a eu un autre incident identique. La question est de savoir si des fournisseurs comparables ont tiré la bonne leçon. Tout grand fournisseur de logiciels peut détenir des identifiants de comptes, des données de paiement, du code source de produits, des métadonnées de support, du stockage cloud, de la télémétrie et de l'administration de licences au sein d'une seule relation de confiance. Une intrusion qui traverse ces limites créera du travail client même lorsque chaque catégorie de données individuelle a un traitement juridique différent.

Le cas Adobe appartient donc à un catalogue de responsabilité plus large. Il montre pourquoi le stockage des mots de passe devrait supposer un vol de base de données. Il montre pourquoi les référentiels de code source nécessitent la même sérieux que les systèmes de production. Il montre pourquoi l'avis client devrait être progressif mais précis. Il montre pourquoi les décomptes publics peuvent évoluer et pourquoi les entreprises devraient expliquer les différences de catégories tôt. Il montre pourquoi l'action du régulateur d'État peut arriver des années après le premier avis.

Il montre pourquoi les index publics de brèches peuvent maintenir les enregistrements de risque client en vie longtemps après que l'entreprise est passée à autre chose.

Cette leçon de récurrence est constructive. L'objectif n'est pas de figer un incident de 2013 dans l'ambre. L'objectif est de l'utiliser comme une carte de contrôle. Si un fournisseur aujourd'hui ne peut pas dire comment il répondrait à des questions de type Adobe sur les identifiants, le périmètre des paiements, l'accès au code source et la preuve d'intégrité du produit, son plan d'incident n'est pas prêt.

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

Le résultat final est qu'Adobe contrôlait les systèmes que les clients avaient besoin de voir expliqués. Les clients pouvaient changer les mots de passe, surveiller les comptes de paiement et se méfier du phishing, mais ils ne pouvaient pas vérifier par eux-mêmes le magasin d'identifiants, la limite des données de paiement, l'accès au code source ou l'examen de l'intégrité du produit. Cela a fait du dossier public d'Adobe le principal outil de prise de décision des clients.

Le dossier a commencé par un avis de l'entreprise, s'est élargi grâce à des reportages publics et des index de brèches, et a ensuite reçu une couche de règlement réglementaire.

La conclusion la plus solide en matière de responsabilité n'est pas que chaque préjudice redouté s'est produit. La conclusion la plus solide est que l'incident a exposé un ensemble de devoirs qui devaient être gérés ensemble: protection des identifiants, délimitation des données de carte, gestion du code source, avis client et récupération fondée sur des preuves. Les informations publiques soutiennent ces devoirs. Elles montrent également les limites de ce que les parties affectées pouvaient savoir de l'extérieur.

Pour les acheteurs, la leçon est d'exiger des catégories de preuves avant une brèche. Pour les conseils d'administration, c'est de traiter la conception des mots de passe et la protection du code source comme une gouvernance. Pour les régulateurs, c'est de regarder au-delà du premier avis et d'examiner si des pratiques raisonnables de détection, de segmentation et de sauvegarde existaient. Pour les clients, c'est de traiter un compte de fournisseur de logiciels comme une véritable surface d'identité, et non comme une connexion de site web mineure.

La décision du lecteur

Un lecteur devrait ressortir avec une question pratique plutôt qu'un slogan. Si un fournisseur de logiciels cloud aujourd'hui divulguait que des enregistrements clients et du code source avaient été accédés, pourrait-il montrer les classes de comptes affectés, les protections des vérificateurs, la limite des données de paiement, la révision du référentiel, les vérifications d'intégrité du produit, la chronologie des notifications, les actions clients et les inconnues restantes sans attendre que des journalistes externes ou des index de brèches complètent le tableau?

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

L'événement Adobe de 2013 est utile car il refuse de rester dans une seule catégorie. C'est un cas d'identité, un cas de périmètre de paiement, un cas de cycle de vie logiciel, un cas de notification transfrontalière et un cas de gouvernance. C'est ainsi que les défaillances modernes des services cloud se comportent souvent. Le fournisseur qui a le plus de contrôle doit produire les preuves les plus claires, et les parties dépendantes ne devraient pas avoir à déduire ces preuves à partir de fragments.

La norme équitable n'est pas l'omniscience. C'est une preuve publique disciplinée. Dites ce qui s'est passé. Dites ce qui est connu. Dites ce qui reste incertain. Dites ce que les clients devraient faire. Dites quelles preuves soutiennent l'affirmation que le risque a été maîtrisé. Dans le dossier Adobe, ces devoirs définissent la surface de responsabilité plus clairement qu'un seul numéro de brèche.