Adobe はソースコードと顧客記録を、共有された資格情報の説明責任の試金石とした

要約

• Adobe は 2013 年 10 月、攻撃者が Adobe の顧客 ID、暗号化されたパスワード、一部の顧客注文および支払いカード情報、さらに複数製品のソースコードにアクセスしたと公表した。
• 中心的な説明責任の問題はこれである：パスワードのハッシュ化、支払いデータの範囲、ソースコードリポジトリアクセス、顧客へのリセット案内、侵害通知のタイミング、そして盗まれたコードが顧客リスクを拡大しなかったことの証明に対して、誰が実際の管理権限を持っていたのか？
• その後の公的記録は Adobe の当初の顧客数以上に拡大した。KrebsOnSecurity は Adobe の確認として、有効な暗号化パスワードを持つ約 3800 万のアクティブユーザーが対象であり、非アクティブ、無効、テストアカウントのデータも調査中であると報じた。Have I Been Pwned は侵害コーパスに 1 億 5240 万の影響アカウントを掲載した。
• 顧客、開発者、企業管理者、支払いカード対応チーム、製品セキュリティレビュー担当者は、Adobe の内部リポジトリログ、パスワード保存設計、決済システムの証拠、顧客ごとの影響範囲マップを見ることなく行動しなければならなかった。
• この記録は管理義務と証拠の欠如に関する高信頼度の説明責任の結論を支持する。あらゆる内部システム、攻撃者の手順、製品ビルド、顧客の損失、リポジトリの変更について私的事実を捏造することは支持しない。

証拠記録とその利用方法

本記事は公的記録を単一の完全な説明としてではなく、階層化された証拠として扱う。企業や政府の記録は、Adobe Inc. や公的機関が述べたことを示すために用いられる。規制当局の和解資料、セキュリティ研究、公開された侵害インデックス、支払い基準、ソフトウェアセキュリティガイダンス、パスワード保存ガイダンスは、管理義務、時系列、影響を受ける当事者の意味合いを整理するために用いられる。分析は二次的報道を、公的記録が示していない私的事実の証明として扱わない。

説明責任の枠組みは非難よりも狭く、侵害通知より広い

Adobe はソースコードと顧客記録を、共有された資格情報の説明責任テストとした。なぜなら、このケースは一つのきれいな枠に収まらなかったからである。単なるアカウント侵害でも、単なる支払いカード事案でも、単なるソースコードインシデントでもなかった。Adobe の告知は、攻撃者が顧客 ID と暗号化パスワードにアクセスし、290 万人の顧客の一部の顧客情報と支払いカードフィールドを削除し、複数の製品のソースコードにアクセスしたと述べた。CISA は公的警告の中で顧客情報とソースコードへの懸念を繰り返した。その後の公開報道と侵害インデックスの記録は、アカウントデータの全体像を最初の数字よりも大きくした。この流れが重要なのは、クラウドサービスにおける説明責任が最初の声明のみで測られるわけではないからである。それは、顧客、銀行、開発者、管理者、規制当局が判断を下す中で、事業者が事実を絞り込み続けられるかどうかで測られる。

非難というものは通常、この記録に対しては大雑把すぎる。有用な説明責任分析は、各段階で誰がリスクを低減するための権限、証拠、ツール、そして義務を有していたかを問う。Adobe は本人確認システム、顧客への告知、パスワードリセットのキャンペーン、ソースコードレビュー、支払いカード暗号化に関する公的声明を管理していた。決済代行業者と銀行はカード監視と顧客保護の一部を管理していた。顧客はパスワードの使い回し、アカウントリセット、自らのローカルなセキュリティフォローアップを管理していた。研究者と記者は、この事案に対する一般の理解を変える外部証拠を提供した。規制当局は後に、攻撃の前および最中に合理的な対策が存在したかどうかを検証した。

核心は実質的な管理である。顧客は Adobe のパスワード保存設計、リポジトリログ、決済処理ネットワークを調査できなかった。彼らは Adobe が公的記録に載せた指示と証拠にしか対応できなかった。プロバイダーが事実を握り、顧客が多くの労力を負うとき、プロバイダーには記録を明確で、段階的で、検証可能にする義務がある。

公的記録が確立していること

公的記録はいくつかの点を確固たるものとしている。Adobe 自身の告知は、同社のセキュリティチームが顧客情報とソースコードへの不正アクセスを伴う攻撃を発見したと述べた。それは、攻撃者が Adobe の顧客 ID と暗号化パスワードにアクセスしたと述べた。同社は、攻撃者が 290 万人の顧客の氏名、暗号化されたクレジットカード番号またはデビットカード番号、有効期限、注文関連情報を削除したと考えているが、復号されたカード番号が同社のシステムから流出したとは考えていないと述べた。Adobe は、関連する顧客パスワードをリセットし、カード情報が関与したと考えられる顧客に通知し、可能な場合はクレジット監視を提供し、決済銀行に通知し、法執行機関と協力していると述べた。また Adobe は、当時入手可能な調査結果に基づき、ソースコードアクセスによって特定の顧客リスクが増大したとは認識していないと述べた。

公的機関と外部記録はさらに別の層を加える。CISA は顧客に対し、不正なアカウント活動に注意するよう警告した。KrebsOnSecurity の初期報道は、ソースコードの一群について説明し、調査、可能性のある製品群、製品の完全性レビューに関する Adobe のインタビュー発言を報じた。後に KrebsOnSecurity は、攻撃者が約 3800 万のアクティブユーザーの Adobe ID と有効な暗号化パスワードへのアクセスを取得し、さらに非アクティブ、無効、テスト用のアカウントデータも調査中であるという Adobe の確認を報じた。Have I Been Pwned は後に、Adobe の侵害を 1 億 5240 万の影響アカウントとして掲載し、メールアドレス、ユーザー名、パスワード、パスワードヒントが含まれることを明らかにした。後に各州の司法長官は、2013 年の侵害から生じた請求を解決する複数州による和解を発表した。

これらの点は義務を分析するには十分に強力である。これらは公的記録の外にある私的事実を主張するには十分ではない。記録は、影響を受けたすべてのデータベース、すべての内部アクセス経路、すべてのリポジトリイベント、あらゆるパスワード管理の詳細、またはすべての顧客の結果を示しているわけではない。その不確実性は、このケースを無視する理由にはならない。それは、依存当事者が Adobe に証明を求める必要があったものに焦点を当てる理由である。

信頼オブジェクトが重要な理由

このケースにおける信頼オブジェクトは単一のファイルではなかった。それは Adobe アカウントのアイデンティティ、支払いデータの取り扱い、ソフトウェアソースの管理という束であった。顧客は、クリエイティブ、ドキュメント、開発、コマース、サポートの関係性を保護するために Adobe ID を信頼していた。銀行やカードネットワークは、カード番号が暗号化されているかどうか、復号されたカード番号が除外されているかどうか、どの決済代行業者に警告すべきかを Adobe が把握していると信頼していた。開発者や企業バイヤーは、盗まれた製品ソースコードが将来のエクスプロイトや改ざんされたリリースの可能性を変えるかどうかを Adobe が把握していると信頼していた。この一連の信頼オブジェクトは顧客データベースよりも広範である。

その広範な信頼オブジェクトが、この事案が長く尾を引いた理由を説明する。アカウント侵害はパスワードリセットや不正監視、使い回しの警告で対処できる。支払いカード事案は銀行やカードネットワークとの連携、データ範囲の証拠、顧客への通知を必要とする。ソースコードアクセスは別の問いを投げかける：攻撃者が実装の詳細、セキュリティチェック、ビルドロジック、埋め込まれたシークレットを研究し、将来のリスクを変える可能性があるか？ Adobe はすべての顧客を満足させるために機密のフォレンジック詳細を公開する必要はなかったが、他者が行動を起こせる程度にそれらの信頼オブジェクトの境界を十分に説明する必要があった。

ここで共有された資格情報の説明責任テストが可視化される。資格情報という言葉は、単にパスワードだけを意味するのではない。資格情報には、パスワード、パスワードヒント、支払いトークンの取扱い、ソースコードリポジトリアクセス、サービスシークレット、署名やビルド管理、そして企業管理者がソフトウェアサプライヤーを信頼し続けるための保証が含まれる。公的記録はパスワードとソースコードの側面を明瞭に示している。多くの証明詳細は非公開のままである。

パスワード保存は顧客アイデンティティを最初の実務負荷に変えた

Adobe が最初に行った顧客向けの対応は、関連アカウントのパスワードリセットキャンペーンだった。それは即時的な顧客保護として正しい種類の対応だったが、同時により深い疑問を露呈させた：なぜ認証情報ストアは盗難後も再利用可能なリスクオブジェクトだったのか？ Adobe の発表ではパスワードは暗号化されているとされていた。その後の公的分析は、パスワード保存方法と平文のパスワードヒントが生み出すリスクに焦点を当てた。Have I Been Pwned は、後のコーパスに顧客レコード識別子、ユーザー名、メールアドレス、暗号化パスワード、ヒントが含まれ、不十分なパスワード暗号化のために多くのパスワードの解読が容易になったと説明している。Troy Hunt の公開分析は、ヒントがパスワード機構が保護しようとする秘密そのものを露呈させうることを強調した。

説明責任の問題は、単にパスワードがリセットされたかどうかではない。リセットは対応である。認証情報の保存は予防である。顧客は Adobe のハッシュ方式、ソルト利用、ワークファクター、ヒント設計、保持ポリシー、検証システムを実際に選ぶことはできなかった。彼らはパスワードの使い回しを避け、リセット通知に対応し、他の場所でパスワードを変更することしかできなかった。つまり、Adobe の管理義務はユーザーの上流に位置していた。適切なパスワード保存の実践は、盗難されたデータベースを事前に計画すべきシナリオとして扱い、事後に対処するエッジケースとはみなさない。

NIST や OWASP による現代的なガイダンスは、この管理クラスを説明するのに役立つ。アカウント検証情報を保持するプロバイダーは、オフライン攻撃に耐えるよう設計された方法でそれらを保護し、ユーザー秘密を明らかにするアカウント回復パターンを避けるべきである。2013 年の Adobe ケースが今なお有用であるのは、認証情報レコードを通常のアカウントデータとして扱うことの代償を示しているからだ。一度コピーされると、そのデータセットはサービスを横断した長期的な攻撃支援となり、特にユーザーがパスワードを使い回している場合に顕著である。

支払いカードの範囲は単なる安心ではなく証拠を必要とした

Adobe の初期の告知は、暗号化されたカードデータと復号されたカードデータを区別した。その区別が中心だった。同社は、攻撃者が 290 万人の顧客の暗号化されたクレジットカード番号またはデビットカード番号、有効期限、注文情報を削除したが、復号されたカード番号は削除されていないと Adobe は考えていると述べた。また Adobe は、顧客の支払いを処理する銀行に通知し、彼らがカード会社やカード発行銀行と連携できるようにしたとも述べた。したがって公的記録は、支払いリスクをアカウントデータリスクよりも狭い箱に入れたが、その箱も証拠を必要とした。

支払いデータの説明責任は「暗号化されていた」という言葉で終わらない。問われるべきは、どのシステムがカードデータを保持していたか、どのフィールドが保存されていたか、暗号化鍵がどのように保護されていたか、攻撃者が復号を試みる可能性はあったか、決済代行業者やアクワイアラに十分な詳細が提供されたか、どの顧客が不正利用に注意するよう伝えられたかである。オハイオ州司法長官の和解発表は後に、Adobe が攻撃者が暗号化された顧客の支払いカード番号を解読しようとしていることを把握し、その攻撃者が Web サーバーを侵害して他のサーバーへのアクセスに使用したと結論づけた。この規制当局の公開情報は、最初の告知だけよりも支払い管理のストーリーを具体的なものにした。

PCI DSS の資料がここで有用なのは、Adobe の法的責任を本記事で決定するからではなく、エコシステムの名前を挙げているからである。カード会員データを保存、処理、伝送する、または影響を与えうる事業体は、加盟店、決済代行業者、アクワイアラ、イシュア、サービスプロバイダの網の中に位置する。その網の中で、クラウドソフトウェアベンダーの支払い証拠は自社の法務ファイルのためだけではない。それは下流の監視、顧客通知、カード再発行判断、不正対応の基盤となる。

ソースコードは単なる知的財産ではなく、製品信頼のリスクだった

ソースコードの盗難はしばしば企業財産の盗難として描写される。このケースでは、顧客リスクの問題はより広範だった。Adobe の製品には、広く導入されたクリエイティブ、ドキュメント、サーバー、Web アプリケーションソフトウェアが含まれていた。KrebsOnSecurity は、露出したソースコード資料に ColdFusion と Acrobat が含まれているように見え、後に Photoshop のソースコードも対象であると報じた。HKCERT は、ソースコードへの不正アクセスが攻撃者による製品の研究や長期的な脆弱性発見を助ける可能性があると警告した。Adobe の自らの告知は、当時入手可能な調査結果に基づき、ソースコードインシデントから特定の増大した顧客リスクを認識していないと述べた。

これらの声明間のギャップが説明責任の領域である。ソースコードが盗まれながらも、改ざんされたリリース、ゼロデイエクスプロイト、顧客の侵害を証明できないことはありうる。また、盗まれたソースコードが、攻撃者に実装の詳細、セキュリティの前提、製品内部に関するより良い知識を与えることで、将来のリスクを高めることもありうる。責任ある公的記録は機密のソースコード詳細を公開する必要はない。必要とされるのは、同社がビルドの完全性、リポジトリアクセス、異常なチェックイン、埋め込まれたシークレット、製品リリース履歴をどのようにチェックしたかを述べることである。

NIST のセキュアソフトウェア開発フレームワークは、生産者の義務を挙げる助けとなる。ソフトウェアの保護には、改ざんや不正アクセスから開発環境とソフトウェアアーティファクトを保護することが含まれる。脆弱性への対応には、残留する弱点の特定と消費者への伝達が含まれる。Adobe の後の PSIRT とセキュリティ速報のページは、顧客が製品セキュリティ情報を受け取る継続的な構造を示している。2013 年の問題は、その信頼の背後にあるソースコードの証拠が、依存する顧客にとって十分強固だったかどうかである。

通知のタイミングが顧客の行動可能範囲を変えた

タイミングの記録が重要なのは、開示が作業を移転させるからである。Adobe の最初の公開発表は 2013 年 10 月 3 日だった。同日の CISA の警告は、一般の認識を顧客に押し上げた。最初の告知は初期の顧客数を示し、パスワードリセット、支払い銀行への通知、ソースコードレビューを説明した。10 月後半、KrebsOnSecurity は Adobe の確認として、約 3800 万のアクティブユーザーが有効な暗号化パスワードとともに影響を受け、さらに非アクティブ、無効、テストアカウントのデータも調査中であると報じた。Have I Been Pwned は後に、はるかに大きな公開侵害コーパスを反映した。

その拡大は、自動的に最初の告知が悪かったことを意味しない。初期の告知は、企業がまだ全容を把握していないため、しばしば段階的になる。しかし、段階的な告知には明確さの義務がある。顧客は、どの事実が確認され、どれがまだ測定中で、最終的な数が判明する前でもどのような行動を取るべきかを知る必要がある。Adobe の最初の告知は、顧客に他のウェブサイトで使い回したパスワードを変更するよう適切に警告した。そのアドバイスは特に重要だった。なぜなら後の公的記録が大規模な認証情報コーパスとパスワードヒントを強調したからである。

説明責任の基準は即時の完璧さではない。それは証拠が固まるにつれて更新されるタイムリーなコミュニケーションである。Adobe ID、使い回したパスワード、企業のソフトウェア資産を保護しようとする顧客は、この事案を狭い支払いカード問題、広範なアイデンティティ問題、製品ソース問題、またはその三つすべてとして扱うべきかを知る必要があった。その答えは三つすべてであり、各パートで異なるレベルの証明を伴っていた。

顧客へのリセット案内は必要だが、設計上不完全だった

パスワードリセットは、プロバイダーが即座に行える数少ない顧客アクションの一つである。Adobe は関連する顧客パスワードをリセットし、同じユーザー ID とパスワードを使い回した他のウェブサイトでパスワードを変更するようユーザーに伝えた。その案内は、最も予測可能な二次被害である認証情報の使い回しに対処した。この案内は、クラウドアカウント侵害の非対称性も明らかにする。Adobe がアイデンティティストアを握っていた。ユーザーはインターネット全体で使い回したパスワードを変更する負担を負った。

リセット案内は、抽象的な告知を行動に変えるために必要である。それは設計上不完全だ。なぜなら、各顧客がどこでパスワードを使い回したか、ヒントが別の秘密を暴露したかどうか、古いアカウントがまだ意味を持つか、企業のアイデンティティ管理者が調達、ライセンス、サポートに関連する休眠アカウントを抱えているかを伝えることはできないからだ。消費者にとっては、その作業は個人のセキュリティ衛生である。組織にとっては、その作業にアカウント棚卸し、管理者レビュー、アイデンティティプロバイダのチェック、ヘルプデスクのコミュニケーション、ユーザー教育が含まれうる。

リセット案内の質は、今何をすべきか、後で何に注意すべきか、どのような不確実性が残っているかを人々に伝えるかどうかで判断されるべきである。Adobe の告知は、即時のリセット手順、使い回しへの警告、支払い監視の文脈を含んでいた。後の公的記録は、より強力なアカウントセキュリティ記録が助けになった理由を示している：顧客はパスワードヒント、アカウント分類、アクティブ対非アクティブレコード、Adobe の最初の影響カード人口とより大きなアカウントデータコーパスの違いを理解する必要があった。

企業管理者は個人顧客とは異なる問題を抱えていた

個人顧客は Adobe パスワードを変更し、カードアカウントを監視できた。企業管理者は別の一連の質問を自問しなければならなかった。どの Adobe ID がソフトウェアライセンス、調達、サポート、クラウドストレージ、公開ワークフロー、クリエイティブコラボレーション、または開発者アカウントに結びついていたか？ 管理者アカウントは影響を受けたか？ パスワードの使い回しは、Adobe アカウントと企業メール、シングルサインオンの回復経路、またはサプライヤーポータルを結びつけていたか？ サポートチームは侵害に関連したフィッシングに備えていたか？ 従業員は偽のリセットリンクを避ける訓練を受けていたか？

公的記録はテナントごとの管理マップを提供しなかったし、一般的な告知でそれを行うことはできなかった。しかし、このインシデントは、企業顧客が消費者向けのアドバイスと管理者向けの証拠を分けたベンダー通知を必要とする理由を示している。パスワードリセットは重要だが、企業はさらにアカウント棚卸し、役割ベースの露出、認証変更、ドメイン通知、特権アカウントが影響を受けたかどうかを確認する方法を必要とする。これらのニーズは特に切実だった。Adobe は単なるカジュアルなウェブサイトではなく、クラウドアカウント、クリエイティブツール、ドキュメントツール、製品セキュリティ依存関係を持つソフトウェアサプライヤーだったからである。

したがって、説明責任の問題は共有されているが不均等である。Adobe は侵害に関する事実を握っていた。企業顧客は自社のアカウント使用に関する事実を握っていた。より強力な共有記録は、その両者を結びつけるだろう：影響アカウントの基準、管理者向けガイダンス、疑わしいフィッシングパターン、Adobe が検証できることとできないことに関する明確な声明。それがなければ、顧客は一般的な告知を自分たちの管理計画に翻訳しなければならない。

データ主権と地域性は通知ネットワークを通じて現れた

Adobe の記録はグローバルだった。公的な執行記録の多くが北米のものであったとしても。Adobe は地域、製品、サービスラインを越えて顧客を抱えていた。CISA は米国の警告を発出した。HKCERT は同一事案について、フィッシングリスクや盗まれたソースコードがもたらす長期リスクを含め、ユーザーに警告する香港のアドバイザリを発出した。州司法長官は後に、複数州による和解で消費者保護とプライバシーの請求を解決した。その結果は、クラウドサービス侵害が地域の説明責任システムをどのように横断するかという有用な例となっている。

このケースにおけるデータ主権は、単にバイトがどこに置かれていたかだけの問題ではない。どの公的機関が影響を受けた人々に警告する能力を持っていたか、どの法律が通知を規律したか、どの顧客がクレジット監視を受けたか、どの銀行やカードネットワークが行動したか、どの地域のセキュリティ機関が事案をアドバイスに翻訳したか、という問題である。顧客は一つの Adobe アカウントを見る。説明責任記録は、企業通知、連邦サイバー警告、州規制当局の措置、独立報道、地域 CSIRT のガイダンスを通過する。

そのパターンは、あらゆるグローバルなクラウドサービスにとって重要である。プロバイダーの内部アーキテクチャは集中化、分散、またはアウトソースされうるが、影響を受ける当事者はローカルなチャネルを通じてリスクを受け取る。彼らはそれらのチャネルを超えて存続する通知を必要とする。企業がカードデータは暗号化されていたと言うなら、地元の規制当局や銀行は依然として行動を決定するのに十分な証拠を必要とする。企業がソースコードが特定の増大したリスクを生み出さなかったと言うなら、地域のセキュリティ機関は依然として、偽りの確実性を生み出すことなくユーザーに警告するのに十分な文脈を必要とする。

二次報道が利用可能な記録を変えた

KrebsOnSecurity の役割が重要だったのは、この侵害に対する一般の理解が Adobe の発表だけから構築されたわけではなかったからである。Krebs の初期報道は大規模なソースコードの一群の発見を説明し、調査に関する Adobe のインタビュー発言を報じた。後の Krebs の追跡報道は、約 3800 万のアクティブユーザーが有効な暗号化パスワードとともに対象であり、非アクティブ、無効、テストアカウントのデータがまだ調査中であるという Adobe の確認を報じた。Have I Been Pwned と Troy Hunt はその後、公に対して永続的なアカウントデータとパスワードヒントの見解を与えた。

これは二次ソースを Adobe 独自の証拠の代わりとするものではない。しかし、独立性の高い報道や侵害インデックスが、非対称性の高いインシデントにおいて極めて重要になりうる理由を示している。顧客はしばしば、企業声明、記者の発見、公開侵害データ、政府警告の組み合わせを通じて事案の形状を学ぶ。それらのソースが分岐するとき、プロバイダーは影響を受ける当事者が理解できる方法でそれらを調整すべきである。最初の顧客数が支払い関連レコードで 290 万人であり、後のアクティブユーザー数がアカウント資格情報ではるかに大きい場合、その違いは平易な言葉で説明されるべきである。

したがって Adobe のケースは、コミュニケーションのケースでもある。プロバイダーは、外部の証拠が自らの最初の声明に異議を唱えたり、それを洗練させたりすることを予期すべきである。正しい対応は防御的になることではない。それは、データカテゴリ、アカウントステータス、パスワードの有効性、支払いカードの範囲、ソースコードの範囲、残る未知の事柄について、より正確な地図を示すことである。

ソースコードの証明負担は資格情報の証明負担とは異なる

資格情報の証明はしばしば具体的である。プロバイダーは、どのアカウントが有効なパスワードベリファイアを持っていたか、どのパスワードがリセットされたか、どのヒントが存在したか、どの顧客が通知されたかを述べることができる。ソースコードの証明はより困難である。関連する証拠には、リポジトリアクセスログ、ソーススナップショット、ビルドシステム、リリース署名、異常なコミットのレビュー、シークレットスキャン、製品セキュリティテスト、脆弱性調査が含まれうる。その証拠の多くは機密である。しかし顧客のリスク判断はその結論に依存する。

Adobe の最初の声明は、ソースコードアクセスから特定の増大した顧客リスクを認識していないと述べた。KrebsOnSecurity は、Adobe が出荷済み ColdFusion コードをレビューし、異常なリポジトリ活動を探していると報じた。HKCERT は、インシデント後にリリースされた ColdFusion 製品が汚染されておらず、Adobe がソースコード流出から Adobe 製品を標的とするゼロデイエクスプロイトを認識していないという Adobe の主張を指摘した。これらの公的声明は有用だが、依然として結論である。顧客はその根底にあるチェックを独自に確認することはできなかった。

説明責任のある道は、証拠そのものを露出させることなく、証拠の種類を開示することである。ソフトウェア生産者は、ビルド成果物が比較されたかどうか、署名鍵がローテーションされたかどうか、リポジトリ資格情報が無効化されたかどうか、シークレットがスキャンされたかどうか、影響を受けたブランチがレビューされたかどうか、脆弱な製品が追加テストを受けたかどうかを述べることができる。そのような声明は、バイヤーが通知を攻撃者マニュアルに変えることなく、結論を判断する方法を与える。

規制当局の措置がニュースサイクル後もケースを生かし続けた

2016 年に発表された複数州和解は、Adobe の事案がパスワードリセットの送信で終わらなかったことを示している。規制当局は、合理的な対策がシステムを攻撃から保護したかどうか、攻撃が十分迅速に検知されたかどうかを調査した。オハイオ州司法長官の発表は、和解が 15 州の請求を解決し、Adobe に新しいポリシーと慣行の実装、保護慣行の定期的評価、州消費者法の遵守、参加司法長官への総額 100 万ドルの支払いを要求したと述べた。

規制当局の記録は、侵害通知とは異なる機能を持つ。侵害通知は、インシデント中に顧客が何をすべきかを伝える。和解は、それ以前の管理環境とその後の修復記録をテストする。その違いは説明責任の中心である。企業は通知を適切に処理しながらも、侵害が防げたか、より早く検知できたかという問いに直面しうる。また、企業は主張されたすべての損害が顧客の損失として証明されずに、規制当局の調査結果に直面しうる。

顧客や取締役会にとって、規制当局の後日対応は第二の証拠層を提供する。それは、公的機関がこの事案を単なる技術的侵入ではなく、ガバナンスと消費者保護の問題とみなしたことを確認する。また、情報源に基づく分析が最初の告知でケースを凍結すべきでない理由も示している。完全な説明責任記録には、最初の声明、その後の範囲更新、独立した侵害証拠、顧客ガイダンス、公的警告、後の執行結果が含まれる。

公的記録が証明していないこと

慎重な記事は、知らないことを明示すべきである。公的記録は、Adobe ネットワーク内での攻撃者のすべてのステップを証明していない。正確な初期侵入経路を証明していない。すべてのデータベース、リポジトリ、資格情報、サーバー、顧客レコードを暴露していない。インシデント後の完全な内部パスワード保存移行計画を示していない。すべてのソースコードレビューアーティファクトや、すべてのビルド完全性チェックを示していない。盗まれたソースコードが特定の後のエクスプロイトを生み出したことを証明していない。すべての顧客が損害を被ったことを証明していない。

これらの制限が重要なのは、侵害に関する記事がしばしば安心感と憶測の間を揺れ動くからである。より有用な立場はより狭い。公的記録は管理義務と証拠ギャップを特定するには十分だが、私的事実を捏造するには十分ではない。Adobe 自身の声明は公的主張として用いられる。KrebsOnSecurity は独立報道と時系列として用いられる。HIBP は侵害コーパス参照として用いられる。州和解の告知は規制当局の記録として用いられる。標準規格は合理的な管理クラスを定義するために用いられる。これらの情報源のいずれも、示せる内容を超えて拡張されるべきではない。

この規律は、ソースコードが関与している場合に特に必要である。ソースコード侵害は、改ざんされたビルドが示されていなくても破滅的に聞こえることがある。また、会社の最初の声明が既知の特定の増大リスクはないと述べていても、実質的にリスクがあることもありうる。説明責任のある答えは、どちらかの極端を選ぶことではない。それは、境界に関する証拠を要求することである。

復旧にはアカウントの復元以上のものが必要だった

この事案からの復旧には、少なくとも四つの経路があった。第一はアイデンティティの復旧である：パスワードをリセットし、使い回しについて警告し、弱いアカウント回復アーティファクトを削除または無効化し、アクティブおよび非アクティブなアカウントホルダーに伝達する。第二は支払いの復旧である：カードデータの範囲を定義し、支払い銀行に連絡し、カード会社やイシュアと連携し、可能な限り監視を提供し、顧客通知を支援する。第三はソフトウェアの復旧である：ソースコードアクセスをレビューし、出荷コードとビルドの完全性をチェックし、異常なリポジトリ活動を調査し、製品リスクの調査結果を伝達する。第四はガバナンスの復旧である：何が失敗したかを文書化し、管理を改善し、規制当局を満足させ、取締役会と顧客が後で検証できる記録を作成する。

公的記録は四つの経路すべての証拠を示しているが、すべての詳細ではない。Adobe はパスワードリセット、支払い銀行への通知、顧客通知、法執行機関との連絡、クレジット監視、ソースコードレビューを説明した。その後の報道と規制当局の記録は、アカウントデータとガバナンスの経路が継続したことを示している。Adobe の現在の PSIRT とアドバイザリのページは、製品セキュリティ更新が伝達される進行中のインフラストラクチャを示しているが、これらのページ自体は 2013 年の内部修復を証明するものではない。

最も強力な復旧記録は反証可能である。顧客は、自分のパスワードがリセットされたこと、カード通知基準が適用されたこと、製品更新が発行されたこと、管理者向けガイダンスが利用可能だったこと、そしてプロバイダーがソースコード盗難が顧客リスクに影響したかどうかを言うための合理的根拠を持っていたことを検証できるべきである。復旧は単に企業が正常に戻ることではない。それは顧客が今や正常が何を意味するかを知ることである。

より強力な公的記録は、影響を受けた各面を分離していただろう

より強力な公的記録は、データの各面をより容易に分離できただろう。それは支払いカード顧客を Adobe ID 保持者から区別するだろう。アクティブアカウント、非アクティブアカウント、無効アカウント、テストアカウントデータを区別するだろう。暗号化パスワードとパスワードヒントを区別し、各カテゴリが生み出す顧客リスクを説明するだろう。どの製品のソースコードがクラスレベルでアクセスされたか、改ざんや将来のエクスプロイトリスクを評価するためにどのようなチェックが行われたかを特定するだろう。確認された事実とまだ調査中の事実を分離するだろう。

この記録はまた、顧客の役割別ガイダンスから恩恵を受けたであろう。消費者はパスワードとカードのアドバイスを必要とする。企業管理者はアカウント棚卸しと特権ロールのアドバイスを必要とする。開発者とセキュリティチームは製品更新とソースコード保証の文脈を必要とする。支払いパートナーはデータ範囲、時間枠、復号されたカードの除外を支持する証拠を必要とする。地域機関は、ローカルな警告に翻訳できる簡潔な説明を必要とする。画一的な通知はプロセスを開始できるが、プロセス全体であってはならない。

これは無制限の開示の要求ではない。それは利用可能な構造の要求である。高信頼のソフトウェアプロバイダーは、機密詳細を暴露することなく、カテゴリ、タイムライン、レビュー方法、顧客アクション、除外事項、不確実性を開示できる。プロバイダーが顧客ワークフローにとって中心的であればあるほど、その構造はより強固である必要がある。

クラウドサービス依存に関する教訓

Adobe のケースがクラウドサービス依存のケースであるのは、ソフトウェアベンダーのアカウントが、アイデンティティ依存、支払い依存、サポート依存、製品信頼依存のすべてに一度になりうるからである。顧客は侵害作業を引き継ぐために Adobe のアカウントデータベースをホストする必要はなかった。開発者はソースコード保証の質問を引き継ぐために Adobe のソースコードリポジトリを管理する必要はなかった。銀行は監視タスクを引き継ぐために Adobe のコマースシステムを運営する必要はなかった。これがクラウド依存のポイントである：事業者が管理を集中させ、影響を受ける当事者は後でその結果を受け取る。

したがって、共有責任は特定的であるべきだ。顧客は一意のパスワード、可能な限りの多要素認証、アイデンティティの棚卸し、ローカル監視に責任を負う。Adobe はパスワードベリファイアの設計、データ最小化、リポジトリアクセス制御、支払いデータ保護、明確な通知、証明境界に責任を負っていた。支払いパートナーは、自らが管理するカード対応義務に責任を負っていた。規制当局は消費者の保護基準が満たされていたかどうかを検証する責任を負っていた。これらすべてを曖昧な共有責任モデルとして扱うことは、誰が実際に何をできたのかを不明瞭にする。

購買に関する教訓は明らかである。クラウドサービス顧客は、ベンダーがセキュリティページを持っているかどうかだけを問うべきではない。顧客は、そのベンダーが認証情報保存、侵害の範囲特定、管理者通知、ソースコード保護、製品更新保証、規制当局対応可能な証拠をどのように扱うかを問うべきである。これらの質問は理論的なものではない。Adobe の 2013 年の記録は、これらの面がいかに迅速に収束しうるかを示している。

ソフトウェアライフサイクルとロックインが復旧の梃子を変えた

Adobe の製品は顧客のワークフローの中に位置していた。クリエイティブチーム、ドキュメントチーム、開発者、Web 管理者、企業バイヤーは、侵害通知が現れたからといって単純に Adobe への依存を一夜で止めることはできなかった。そのロックインが説明責任基準を変える。顧客が迅速に離脱できない場合、プロバイダーの説明はより強固でなければならない。それは、顧客が合理的なリスク判断を行いながら事業を継続できるようにしなければならない。

ソフトウェアライフサイクルリスクも、アカウントリセットリスクより長期である。パスワードは数分で変更できる。ソースコードの露出は、実装詳細や開発慣行を明らかにすれば、数ヶ月から数年にわたり製品セキュリティレビューに影響を与えうる。リポジトリアクセスはまた、埋め込まれたシークレット、ブランチ履歴、ビルド管理に関する疑問を提起する。Adobe の公的立場は、ソースコードアクセスから特定の増大した顧客リスクを認識しておらず、公開報道はレビュー活動を説明していた。未解決の説明責任問題は、その結論に対して顧客が確認できた証拠のレベルである。

NIST SSDF の文言は、セキュアなソフトウェア生産を管理されたライフサイクルとして扱うため有用である。ソフトウェアアーティファクト、開発環境、リリースを保護することは、単なるエンジニアリング上の好みではない。それはバイヤー保証の義務である。ロックインされたソフトウェア関係において、顧客はプロバイダーがリリース前にソフトウェアを保護し、インシデント後に何が起きたかを証明できるという証拠を必要とする。

取締役会は資格情報設計をガバナンス問題として扱うべきである

資格情報の保存は、侵害によって幹部が顧客、銀行、規制当局、一般に説明を強いられるまで、技術的に見えることがある。Adobe の記録は、なぜ取締役会が資格情報設計をガバナンスとして扱うべきかを示している。可逆暗号、適切に保護されたパスワードベリファイア、弱いヒント、強力なリセットワークフロー、多要素サポートの違いは、顧客の損害と企業の信頼性に影響する。それらは取締役会レベルの結果である。設計詳細が技術的であっても。

取締役会はパスワードハッシュアルゴリズムを選択する必要はない。しかし、同社の保存された資格情報がデータベース盗難後にオフライン攻撃に耐えるかどうか、パスワードヒントやリカバリ質問が秘密を明らかにするかどうか、古いアカウントが最小化されているか、テストアカウントが管理されているかを問う必要はある。アイデンティティシステムが支払いシステムから分離されているか、侵害通知計画がユーザー人口を区別しているか、企業が安全でないリンクをクリックするよう訓練することなく信頼できるリセット案内を迅速に送信できるかを問うべきである。

同じ取締役会は、ソースコードがどのように保護されているかを問うべきである。誰がリポジトリにアクセスできるか？ どうやってシークレットがコードから排除されているか？ ビルドシステムは隔離されているか？ 署名鍵は保護されているか？ 異常なコミットはレビューされているか？ 不正アクセス後にリリースの完全性を証明できるか？ Adobe のケースは、アイデンティティとソースコードの両方を結びつけるため有用である。これらを別々に扱う取締役会は、単一の侵入がどのようにして両方を公にしうるかを見逃すだろう。

バイヤーは事象の前に証拠を求めるべきである

バイヤーはしばしば侵害後にしかインシデント証拠を求めない。Adobe の記録は、契約署名や更新の前に問うべきいくつかの質問を示唆している。パスワードとアカウントベリファイアはどのように保護されているか？ パスワードヒントや秘密の質問は使用されているか？ ベンダーはアクティブアカウントと非アクティブアカウントにどのように通知するか？ ベンダーは支払いデータをアイデンティティデータからどのように分離しているか？ 誰が管理者通知を受け取るか？ ソースコードリポジトリがアクセスされたときにどのような証拠が共有されるか？ ビルドシステム、リリース署名、製品更新はどのように保護されているか？ 侵害後に顧客がフィッシングを回避できるよう、どのようなサポートチャネルが使用されているか？

これらの質問は、調達、セキュリティレビュー、更新の議論に現れるべきである。なぜなら、顧客はインシデントが進行してしまうと梃子を失うからである。侵害中、ベンダーは封じ込めと法的レビューに集中し、顧客は事業の保護に努める。侵害前に、バイヤーは通知コミットメント、管理者連絡先リスト、役割別ガイダンス、セキュリティ補遺、監査権、インシデント後の証拠カテゴリを要求できる。目標はあらゆる内部詳細を要求することではない。目標は、障害時に有用となる証拠パッケージを定義することである。

主要なアカウントと製品依存を持つソフトウェアベンダーにとって、その証拠パッケージは資格情報、支払いデータ、ソースコード、顧客通知、製品更新の完全性をカバーすべきである。Adobe の 2013 年の記録は、なぜこれら五つすべてが同じバイヤーとの会話に属するのかについての簡潔な理由であり続けている。

契約文言は露出面に従うべきである

一般的な侵害条項は、このようなケースには薄すぎる。契約文言は露出面に従うべきである。もし顧客アカウントデータが保存されるなら、契約はアカウントベリファイア保護、管理者通知、パスワードリセット義務、アイデンティティログに対処すべきである。支払いデータが処理されるなら、カードデータ環境の境界、決済代行業者との連携、暗号化と鍵管理の証拠、顧客通知に対処すべきである。ソースコードや製品ビルドシステムがサービスにとって重要なら、リポジトリアクセス制御、ビルドの完全性、リリース署名、脆弱な製品のレビュー、顧客向け製品アドバイザリに対処すべきである。

有用な条項は、ベンダーにさらなるリスクを生む秘密を明かすことを要求しない。それは、ベンダーに顧客が行動するために十分な証拠を共有することを要求する。すなわち、カテゴリ、タイムライン、影響を受けたシステム、顧客アクション、除外事項、レビュー方法、変更された管理策である。また、エスカレーション経路も意味する。消費者向けリセット通知を受け取る人々は、企業管理者向けブリーフィングや製品セキュリティ保証メモを必要とする人々と同じではない。

Adobe の事案は、これがなぜ重要かを示している。同一の公的インシデントが、消費者アカウント、支払いカード対応、企業アイデンティティ、ソースコードレビュー、ソフトウェアライフサイクル保証、規制当局の精査に触れた。個人データだけに言及する契約文言はソースコードリスクを見逃すかもしれない。セキュリティパッチだけに言及する契約文言は資格情報の使い回しを見逃すかもしれない。説明責任は、それらが失敗する前に面を特定することを要求する。

復旧の主張を検証可能にする運用上の指標

いくつかの指標は、機密詳細を暴露することなく、ベンダーの復旧主張の検証を容易にするだろう。アカウントデータについては、ベンダーは影響を受けたアカウントクラス、パスワードリセット状況、ヒントやリカバリデータが露出したかどうか、休眠アカウントが含まれたかどうか、多要素オプションが変更されたかどうかを特定できる。支払いデータについては、ベンダーはフィールドカテゴリ、暗号化境界、鍵分離の根拠、決済代行業者への通知、顧客通知基準を述べることができる。ソースコードについては、ベンダーはリポジトリクラス、製品ファミリー、ビルド完全性チェック、署名鍵ステータス、カテゴリ別のシークレットスキャン結果、製品更新が加速されたかどうかを述べることができる。

これらの指標は風変わりではない。それらは顧客が推測を減らすために必要なものである。中小企業は、スタッフが使い回したパスワードを変更すべきかどうかを知る必要がある。銀行は、カード監視で十分か、カード再発行がありそうかを知る必要がある。ソフトウェアセキュリティレビュー担当者は、将来のパッチサイクルに特別な注意を払うべきかどうかを知る必要がある。地域のサイバー当局は、フィッシング、製品更新、支払い詐欺のいずれか、またはすべてについて警告すべきかを知る必要がある。

Adobe の公的記録は、これらの指標の一部を含んでいるが、すべてではない。それはパスワードリセット、カード通知手順、法執行機関との連絡、支払い銀行との連絡、ソースコードレビューを挙げた。後の情報源は、より大きなアカウント人口とパスワードヒントのリスクを挙げた。より強力な記録は、これらの断片を一つの明瞭な証拠マップにまとめるだろう。

再発問題は Adobe よりも広範である

再発問題は、Adobe が再び同一のインシデントを起こしたかどうかではない。問題は、同種のベンダーが正しい教訓を学んだかどうかである。あらゆる大規模ソフトウェアプロバイダーは、一つの信頼関係の中で、アカウント資格情報、支払いデータ、製品ソースコード、サポートメタデータ、クラウドストレージ、テレメトリ、ライセンス管理を保持しうる。それらの境界を越える侵入は、個々のデータカテゴリが異なる法的扱いを受ける場合でも、顧客作業を生み出すだろう。

したがって Adobe のケースは、より広範な説明責任カタログに属する。それは、なぜパスワード保存がデータベース盗難を想定すべきかを示している。なぜソースコードリポジトリが本番システムと同じ真剣さを必要とするかを示している。なぜ顧客通知は段階的だが正確であるべきかを示している。なぜ公的カウントが進展しうるのか、そしてなぜ企業は早い段階でカテゴリの違いを説明すべきかを示している。なぜ州の規制当局の措置が最初の通知から数年後に到着しうるかを示している。なぜ公開侵害インデックスが、企業が前進した後も長く顧客リスク記録を生かし続けうるかを示している。

その再発の教訓は建設的である。目標は 2013 年のインシデントを琥珀の中に閉じ込めることではない。目標はそれを管理マップとして使うことである。今日のプロバイダーが、資格情報、支払い範囲、ソースコードアクセス、製品完全性の証明に関する Adobe のような質問にどのように答えるかを言えなければ、そのインシデント計画は準備ができていない。

説明責任の結論

結論は、Adobe が顧客に説明を必要としたシステムを管理していたということである。顧客はパスワードを変更し、支払いアカウントを監視し、フィッシングに注意することはできたが、資格情報ストア、支払いデータ境界、ソースコードアクセス、製品完全性レビューを独自に検証することはできなかった。それが Adobe の公的記録を顧客の意思決定の主要なツールとした。その記録は企業通知から始まり、公開報道や侵害インデックスを通じて拡大し、後に規制当局の和解層を得た。

最も強力な説明責任の結論は、懸念されたすべての損害が起きたということではない。最も強力な結論は、このインシデントが一緒に管理されねばならなかった一連の義務を暴露したことである：資格情報保護、カードデータ範囲特定、ソースコード管理、顧客通知、証拠に基づく復旧。公的記録はこれらの義務を支持する。また、影響を受けた当事者が外部から知り得たことの限界も示している。

バイヤーにとっての教訓は、侵害前に証拠カテゴリを要求することである。取締役会にとっては、パスワード設計とソースコード保護をガバナンスとして扱うことである。規制当局にとっては、最初の通知を超えて目を向け、合理的な検知、セグメンテーション、保護慣行が存在したかどうかを調査することである。顧客にとっては、ソフトウェアベンダーのアカウントを軽微なウェブサイトログインではなく、本物のアイデンティティ面として扱うことである。

読者への決断

読者はスローガンではなく、実践的な問いを持ち帰るべきである。もし今日クラウドソフトウェアプロバイダーが、顧客記録とソースコードがアクセスされたと開示した場合、外部の記者や侵害インデックスが全体像を完成させるのを待つことなく、影響を受けたアカウントクラス、ベリファイア保護、支払いデータ境界、リポジトリレビュー、製品完全性チェック、通知タイムライン、顧客アクション、残る未知事項を示せるだろうか？ 答えがノーなら、Adobe の記録は説明責任の教訓として依然として現代的である。

Adobe の 2013 年の事案は、一つのカテゴリに留まることを拒むために有用である。それはアイデンティティのケースであり、支払い範囲のケースであり、ソフトウェアライフサイクルのケースであり、国境を越えた通知のケースであり、ガバナンスのケースである。これが現代のクラウドサービス障害がしばしば振る舞う方法である。最も管理権限を持つプロバイダーが最も明瞭な証拠を生み出さねばならず、依存当事者は断片からその証拠を推測することを強いられるべきではない。

公正な基準は全知ではない。それは規律ある公的証明である。何が起きたかを述べよ。既知のことを述べよ。不確実なままのことを述べよ。顧客が何をすべきかを述べよ。リスクが封じ込められたという主張を支持する証拠を述べよ。Adobe の記録において、これらの義務は、単一の侵害数よりもはっきりと説明責任の面を定義している。