Summary

  • Adobe 2013年顧客データ侵害、パスワード保管、ソースコード露出、顧客リセット、長期アイデンティティ説明責任の記録。
  • Adobe の2013年顧客データ侵害は、アカウント記録とソースコードリスクを暴露し、パスワード保護、通知、および長期の認証情報再利用に関する公的な精算を迫った。
  • 誰がパスワード保管の設計、ソースコード保護、侵害通知、顧客リセット、露出フィールドの最小化、和解の証拠、そして開示日以降もレガシーアカウントシステムがリスクを転嫁し続けなかったことの証明を実質的に管理していたのか？
  • 説明責任の課題は、侵害前に行われたパスワード保管の決定が、企業がアカウントをリセットし世間の注意が他に移った後も、コストを負わせ続ける可能性があることだ。
  • 顧客、開発者、ソフトウェア購入者、アイデンティティリスクチーム、規制当局、集団訴訟参加者、セキュリティエンジニアは、アカウントシステムの修復が永続的な認証情報とソースコードのリスクに対処したという証拠を必要としていた。

本件がリスクと説明責任のファイルに属する理由

Adobe は、パスワード保管の証拠を長期にわたるアイデンティティ説明責任の試金石としました。2013 年の侵害は単なる開示イベントではなかったからです。それは、企業が顧客にパスワードのリセットを指示した後も、古いアカウントシステム、パスワード保管の選択、顧客通知、ソフトウェアのソースコード管理、サブスクリプション時代のアイデンティティ依存がどのようにリスクを転嫁し続けるかについての公開講座となりました。中心的な説明責任の問いは、Adobe が最終的に当初の公表数よりも多くの影響を受けたアカウントを認めたかどうかではありません。そうではなく、公的記録が、顧客やソフトウェア購入者が保管設計と修復の永続的な結果を理解できるものだったかどうかです。

この事例は、あまりに古いため、単純な歴史として誤って記憶される可能性があります。それは危険です。Adobe の古い顧客セキュリティ発表（http://blogs.adobe.com/conversations/2013/10/important-customer-security-announcement.html）とソースコード発表（http://blogs.adobe.com/asset/2013/10/illegal-access-to-adobe-source-code.html）は、顧客データと製品ソースコードの侵害に関する初期の公的記録でした。後に BBC の報道（https://www.bbc.com/news/technology-24740873）などを含む報告では、当初報告された 290 万人の影響を受けた顧客から、約 3,800 万人のアクティブユーザーへと規模が拡大したこと、また、以前の Acrobat や ColdFusion への言及に加えて Photoshop に関わるソースコードの露出についても指摘されました。数字は重要ですが、設計の教訓の方がさらに重要です。

パスワード保管は侵害前の決定であり、失敗後に初めて公になります。企業が攻撃者の推測に役立つ形でパスワード素材を保管している場合、リセットによって被害が消えるわけではありません。攻撃者はもはや元のサービスを必要としないかもしれません。同じ、もしくは類似した認証情報を他の場所で試したり、パスワードヒントからパターンを推測したり、メールアドレスを他の露出データと組み合わせたり、弱い保管設計から利益を得続けることができます。一次サイトが修復された後もずっとです。だからこそ、本記事はこの侵害を一時的なセキュリティの話題ではなく、長期にわたるアイデンティティ記録として扱うのです。

ソースコードの露出は、第二の時間軸を追加します。SANS Internet Storm Center の FAQは、開示直後に顧客データ、ソースコード、ColdFusion の状況について議論しました。Krebs によるセキュリティ報道（http://krebsonsecurity.com/2013/10/adobe-to-announce-source-code-customer-data-breach/）や Ars Technica（http://arstechnica.com/security/2013/10/adobe-source-code-and-customer-data-stolen-in-sustained-network-hack/）も、このイベントを顧客データとソースコードの両方の侵害として位置付けました。ソースコードはパスワードテーブルと同じリスクを生み出すわけではありませんが、実装の詳細、製品の前提、潜在的な脆弱性の経路を明らかにすることで、攻撃者の経済性を変える可能性があります。

本記事は、すべての二次的主張を証明された内部事実として扱うわけではありません。Adobe の声明、当時の報道、技術的分析、現在の基準を区別します。現在のAdobe Trust Centerのページやhttps://www.adobe.com/trust/security.htmlは、現在のセキュリティプログラムの表現として使用しており、2013 年の管理策の証明としては使用していません。OWASP と NIST の資料は、パスワードとアイデンティティの原則のために用いており、遡及的な法的判断としてではありません。この情報源の規律が重要なのは、長期にわたる説明責任が、何が知られていたか、後から何が報告されたか、そして現在も公的記録に残っていないものを区別することにかかっているからです。

パスワード保管はリセット後もコストを転嫁しうる

侵害されたパスワードデータベースに対する通常の対応はリセットです。リセットは必要ですが、リスクのすべてに応えるものではありません。元のパスワード保管方法が意味のあるオフライン推測を許した場合、Adobe アカウントに古い秘密鍵でアクセスできなくなった後も、攻撃者はユーザーのパスワード習慣を知るかもしれません。同じまたは関連するパスワードが他で再利用されていた場合、ユーザーの他のアカウントは露出したままになる可能性があります。パスワードヒントが平文または推測可能な形で利用可能だった場合、それは攻撃者を助け続けるかもしれません。長期的なコストは、侵害された企業だけではなく、ユーザーに降りかかるのです。

Ars Technica のパスワードに焦点を当てた分析（http://arstechnica.com/security/2013/11/how-an-epic-blunder-by-adobe-could-strengthen-hand-of-password-crackers/）が影響力を持ったのは、パスワード保護の形式がなぜ重要なのかを説明したからです。この記事は単なる技術的な叱責に矮小化されるべきではありません。それは説明責任の原則を提起しました。すなわち、保管設計が、流出後に攻撃者がどれだけの価値を引き出せるかを決定するということです。堅牢なシステムは、データベースの盗難が起こり得ると想定し、盗難が役に立たなくなるようにパスワード検証子を保存します。弱いレガシーシステムは、データベースをパスワードクラッカーのトレーニングセットに変えてしまうかもしれません。

OWASP の Password Storage Cheat Sheetは、この問題に対する現代的な用語を提供します。ゆっくりとしたパスワードハッシュ、ソルト、ワークファクター、適切な場合はペッパー、そして弱いスキームからの移行です。これらの概念は事后的な装飾ではありません。それらはユーザーや監査人が必要とする証拠を定義します。企業がパスワードをリセットしたと言うとき、公的ファイルは依然として問うべきです。どのような保管設計が廃止されたのか、どのような新しい設計に置き換えられたのか、古いレコードはどのように移行されたのか、非アクティブなレコードは保持されたのか、パスワードヒントや関連するアカウント回復アーティファクトは最小化されたのかどうか。

NIST の現在のデジタルアイデンティティガイダンス（https://pages.nist.gov/800-63-4/sp800-63b.html）は、認証がライフサイクルであるという点を補強します。それには発行、維持、無効化、セッション制御、そして救済が含まれます。パスワードリセットはそのライフサイクルにおける一つのイベントです。侵害後には、アカウント回復、多要素認証オプション、漏洩シークレットのスクリーニング、再認証、認証問題に関する救済がすべて重要です。Adobe にとって、長期的な課題は、顧客が自分の認証情報リスクが Adobe アカウントを超えてどこまで及ぶかを知るのに十分な証拠を受け取ったかどうかです。

公的記録は、「暗号化された」が不十分なユーザー向けの言葉になり得る理由を示しています。暗号化、ハッシュ化、ソルト、パスワードヒントは異なる結果をもたらしますが、多くの通知はこうした区別を大まかな安心感へと圧縮してしまいます。ユーザーは暗号の講義を必要としませんが、実際的な結果を知る必要があります。攻撃者は古いパスワードを逆算したり効率的に推測したりできるのか？　ヒントは露出したのか？　非アクティブアカウントは含まれていたのか？　顧客 ID、メールアドレス、支払い記録、その他の属性が同じファイルに紐付けられていたのか？　通知は、企業の開示カテゴリだけでなく、ユーザーのリスクの問いに答えるべきです。

ソースコードの露出は侵害をソフトウェアライフサイクルの問題に変える

Adobe の 2013 年の出来事がこの連載に含まれるのは、ソースコードの露出が顧客のアイデンティティを超えて広がるからでもあります。古い Adobe のソースコード発表、SANS FAQ、Krebs の報道、BBC の報道、Ars Technica の報道はすべて、このインシデントが主要な Adobe 製品またはコンポーネントのソースコードに関わるものとして扱いました。公開報道では Acrobat、ColdFusion、ColdFusion Builder、後に Photoshop に言及されました。説明責任の問いは、ソースコードの露出が自動的に既知のエクスプロイトを生み出すかどうかではありません。企業が新たなリスクに合わせて、製品セキュリティのレビュー、脆弱性対応、顧客ガイダンスを変更したことを証明できるかどうかです。

ソフトウェアライフサイクルとロックインは、Adobe の説明責任の対象領域の中心です。多くの顧客は、クリエイティブ制作、文書ワークフロー、公共部門のフォーム、エンタープライズマーケティング、PDF 処理を Adobe ツールに依存しています。彼らはソースコードの事件後にすぐに移行することはできません。その依存性は、ベンダーに対して明確な製品セキュリティの証拠を提供する義務を課します。どの製品が影響を受けたか、どのブランチがレビューされたか、どのパッチや強化ステップが重要だったか、顧客が後のアドバイザリーをどう監視できるかです。Adobe の現在のセキュリティ速報インデックス（https://helpx.adobe.com/security/security-bulletin.html）は、アドバイザリーとパッチの継続的な語彙を示していますが、大衆はソースコードの出来事から後続の製品セキュリティ保証への橋渡しを必要としています。

ソースコードの保管は、ガバナンスの問題でもあります。それにはリポジトリアクセス、セグメンテーション、シークレット管理、ビルド管理、コードレビュー、ログ、内部および外部のアクセス監視、そしてインシデントレスポンスが含まれます。現在の Adobe のセキュリティページ（https://www.adobe.com/trust/security/product-security.htmlやhttps://www.adobe.com/trust/security/incident-response.html）は、安全な製品ライフサイクルやインシデントレスポンスを含む、今日的なセキュリティプログラムの概念を説明しています。それらは 2013 年のシステムがどのように動作していたかを正確に証明することはできませんが、現代の読者が証拠ファイルに見るべきものを示すという点で有用です。

長期的なリスクは、攻撃者が単純にソースコードを永久に保持するということではありません。むしろ、防御側は露出したコードが異なるレンズを通じてレビューされたという保証を必要とします。攻撃者が実装の詳細を調べることができたのであれば、プロダクトチームは不明瞭さが隠れたコントロールとして扱われていたかどうか、共有コンポーネントのレビューが必要かどうか、顧客向けの強化ガイダンスを変更すべきかどうか、過去の脆弱性を再調査すべきかどうかを問うべきです。広く展開された文書ツールやウェブアプリケーションプラットフォームが制度的依存となる可能性があるため、公共部門の継続性もこのファイルに入ってきます。その規模での製品セキュリティの出来事は、私的な不便ではありません。

これが、証拠ファイルが顧客データとソースコードを別々の見出しとして扱うのではなく、結び付けなければならない理由です。パスワードの露出はユーザーとアイデンティティチームに影響します。ソースコードの露出は開発者、企業、ソフトウェア購入者に影響します。同じ侵害対応には別々のトラックが必要ですが、それらのトラックは時系列とガバナンスの所有者を共有すべきです。企業が顧客にパスワードのリセットを指示する一方で、プロダクトチームが静かにソースコードをレビューするだけなら、部外者はその事象が封じ込められたかどうかを判断できません。説明責任は、依存する組織が計画を立てられるよう、両方のトラックが十分に見えるようにすることを要求します。

通知の質が、ユーザーが他のアカウントを守れるかどうかを決める

Adobe の通知の問題は、当初の影響を受けたユーザー数だけではありませんでした。それは、ユーザーが Adobe 以外で何をすべきかという実際的な問いでした。BBC の報道（https://www.bbc.com/news/technology-24740873）は、Adobe がパスワードをリセットしたこと、および他のサービスで再利用された認証情報が引き続きリスクであることを伝えました。これが長期にわたるアイデンティティ説明責任の核心です。企業は古い Adobe パスワードを無効にできますが、顧客がそれを再利用した他のすべてのアカウントをリセットすることはできません。したがって、通知は他の場所で比例した行動を促すのに十分な認証情報リスクを伝えなければなりません。

効果的な通知は、いくつかの事項を分けるでしょう。アクティブアカウント、非アクティブアカウント、顧客 ID、メールアドレス、暗号化されたパスワード、パスワードヒント、支払いカードデータ、ソースコードの露出、リセット状況です。また、企業がまだ検証できていないことも説明するでしょう。急展開するインシデントでは、数字が変わることがあります。それが早期の開示を無意味にするわけではありません。それは、早期の開示が不確実性について明確であるべきだということを意味します。ユーザーは数字が増えるかもしれないと理解できますが、通知がすべての不確実性を自信に満ちているが不完全な声明に押し込めてしまうと、ユーザーは適切に行動できません。

FTC の侵害対応ガイダンス（https://www.ftc.gov/business-guidance/resources/data-breach-response-guide-business）は、通知をパブリックリレーションズではなく、対応の一部として扱う点で役立ちます。FTC の個人情報ガイド（https://www.ftc.gov/business-guidance/resources/protecting-personal-information-guide-business）も、インシデント発生前の最小化と保護対策を指摘しています。Adobe にとって、ユーザー向けの課題は、通知が技術的事実を行動に翻訳したかどうかです。Adobe パスワードをリセットする、他で再利用したパスワードを変更する、支払いアカウントを監視する、フィッシングの試みに注意する、ソースコードの露出が製品ユーザーにとって何を意味し、何を意味しないのかを理解する、といったことです。

同じ論理が集団訴訟の参加者や規制当局にも当てはまります。法的手続きはしばしば立場、損害、和解、手続き上の証明に焦点を当てます。それらの記録は重要ですが、技術的証拠の代わりにはなりません。顧客は自分のアイデンティティとアカウントに対する継続的なリスクを理解する必要がありました。規制当局は、保管設計、非アクティブレコード、パスワードヒント、通知慣行が合理的なセキュリティ期待に合致しているかどうかを理解する必要がありました。ソフトウェア購入者は、製品セキュリティのレビューが影響を受けたコードに達したかどうかを理解する必要がありました。単一の開示チャネルが、意図的に構造化されていない限り、これらすべての対象に応えることは稀です。

したがって、通知の基準は下流の意思決定によって測定されるべきです。顧客は他のサービスでパスワードを変更すべきかどうかを特定できたか？　企業のアイデンティティチームは、社内アカウントで Adobe パスワードの再利用を検索すべきかどうかを決定できたか？　開発者は Adobe のアドバイザリーをより注意深く監視すべきかどうかを決定できたか？　公共部門の購入者は適切な調達とパッチの質問をできたか？　もし通知がこれらの意思決定を支援しなかったならば、それは長期的なリスクを企業の説明責任の枠外に置き去りにしたのです。

非アクティブレコードがレガシーシステムを被害の一部にする

非アクティブレコードは、古いアカウント侵害における繰り返し発生する問題です。BBC の報道は、Adobe が攻撃者がアクティブユーザーに加えて、2年以上使用されていないアカウントの詳細にもアクセスしたと考えていると述べました。その事実は重要です。なぜなら、非アクティブアカウントは企業とユーザーの双方から、しばしばあまり注意を払われないからです。ユーザーは古い Adobe ID を覚えていないかもしれませんし、そのメールアドレスを監視していないかもしれませんし、何年も前にパスワードを再利用していたかもしれませんし、なぜ古いクリエイティブソフトウェアのアカウントが現在のアイデンティティリスクを引き起こすのか理解できないかもしれません。したがって、企業の保持と移行の選択がユーザーの現在の露出を形作るのです。

レガシーアカウントシステムは修復も複雑にします。古いパスワード保管システムが廃止予定だったか、現在の認証経路の一部ではなかったとしても、企業はそのシステム内のレコードが価値を漏洩し続けることができないことを証明しなければなりません。侵害後にシステムを廃止するだけでは十分ではありません。レガシーコピー、バックアップ、ログ、ヒント、非アクティブアカウントが残っている場合です。公的ファイルには、古いストアがどのように棚卸しされたか、どのように保護されたか、どのように削除または移行されたか、そして並行する認証情報レコードがリスクを負い続けていないことをどのように検証したかが記されるべきです。

データ主権と地域性は、実務的なレコードガバナンスの関心事としてここに現れます。Adobe はグローバルな顧客にサービスを提供しており、アイデンティティレコードは製品、サブスクリプション、サポート、支払い、地域の境界を越える可能性があります。ある法域の顧客は別の法域の顧客とは異なる通知の権利を持っているかもしれませんが、パスワードヒントや再利用可能なパスワードの技術的リスクはその境界を尊重しません。長期にわたる説明責任のファイルは、データカテゴリを伝わるような方法で説明すべきです。各法域、顧客、購入者が断片から保管設計を再構築することを求めるべきではありません。

NIST Cybersecurity Framework（https://www.nist.gov/cyberframework）と CIS Controls（https://www.cisecurity.org/controls）は、Adobe の内部システムについて裏付けのない主張をすることなく、これについて考える方法を提供します。資産管理、アイデンティティ管理、データ保護、ログ、インシデントレスポンス、回復はすべて関連します。取締役会のレビューでは、企業が古いアカウントストアをリストアップし、その中に認証素材を含むものを特定し、所有者を指名し、保持理由を文書化し、廃止されたストアが排除または強化されたことを証明できるかを問うべきです。

Adobe の事例は、侵害がアカウントシステムの考古学を露わにし得ることを示しているため、依然として有用です。企業はしばしば正面玄関を最新化する一方で、古いレコードストアが地下に残ります。顧客はその地下を見ることができません。インシデントがそれを暴露した時だけ、その存在を知るのです。その非対称性こそが、レガシーシステムが現在のリスクを生み出すとき、公的な説明責任が必要とされる理由です。

基準は評決ではないが、修復の証拠を定義する

現代のパスワード保管基準を、2013 年のシステムに対する遡及的な評決として安易に使うべきではありません。技術は変わり、脅威モデルは変わり、公開ガイダンスは進化します。しかし、基準は依然として必要です。なぜなら、それらが修復の証拠が今どうあるべきかを定義するからです。OWASP のパスワードガイダンス（https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html）、NIST のアイデンティティガイダンス（https://pages.nist.gov/800-63-4/sp800-63b.html）、CISA の secure-by-design ガイダンス（https://www.cisa.gov/securebydesign）、そして Adobe の現在のセキュリティプログラムのページ（https://www.adobe.com/trust/security.html等）は、組み合わさって、より強力な修復記録の語彙を示しています。

修復の証拠はいくつかの質問に答えるべきです。どのようなパスワード保管スキームが関与していたか？　それは一方向性で、ソルト付き、低速で、オフライン攻撃耐性のために調整されていたか？　パスワードヒントは保存されていたか、もしそうならなぜか？　非アクティブアカウントはアクティブなものと同じデータとともに保持されていたか？　古いシステムは使用停止されたのか、単に通常のログイン経路から隠されただけなのか？　リセットはセッションとトークンを無効にしたのか？　ユーザーは他で再利用したパスワードを変更するよう促されたか？　企業の管理者には露出を検索するための指標が与えられたか？　製品セキュリティチームにはソースコードレビューの要件が与えられたか？

これらの質問は証拠のためのものであり、告発ではありません。企業は、機密性の高い実装の詳細を守りながら、それらに答えることができます。エクスプロイトのレシピを公開せずに、システムの種類、修復の手順、移行のマイルストーン、外部保証について説明できます。してはいけないのは、完全な修復として「パスワードをリセットしました」を受け入れるよう顧客に求めることです。リセットは見えるものです。保管の移行、ヒントの最小化、非アクティブアカウントのクリーンアップ、ソースコードレビューは、あまり見えません。だからこそ、それらには説明責任のある証拠が必要なのです。

公的ファイルは、基準文書と法的義務を区別すべきです。FTC のガイドはビジネスガイダンスです。NIST と CISA の文書は公開基準またはガイダンスです。OWASP はコミュニティのセキュリティガイダンスです。Adobe の Trust Center は企業が作成したものです。これらの情報源のいずれも、単独では裁判所の認定ではありません。しかし、それらが重なり合う部分は有用です。強力な認証、健全なパスワード保管、最小化、インシデントレスポンス、製品セキュリティ、救済はすべて、耐久性のあるコントロールのテーマとして現れています。長期にわたる説明責任の記事は、その重なりを用いて、顧客が当然受けるべきだった修復のファイルを定義します。

このアプローチは、遡及的な侵害記事によくある誤りを避けます。「ここに現代のチェックリストがある、従って古い企業はすべての項目で失敗した」とは言いません。代わりに、「リスクが転嫁され続けるのを止めたことを示すために、今必要となる証拠はこれだ」と言います。この区別が重要です。説明責任は過去に対する単なる道徳的判断ではありません。それは、古い設計上の選択が、もはやシステムを自分で検査できない人々を害し続けていないという証明を求める要求なのです。

製品の信頼とアイデンティティの信頼は共に動いた

Adobe の侵害が重要だったのは、製品の信頼とアイデンティティの信頼が共に動いたからです。顧客はソフトウェアアクセス、サブスクリプション管理、支払い、アップデート、サポート、アイデンティティのために Adobe アカウントを利用していました。開発者と企業は、文書やクリエイティブのワークフローを Adobe 製品に依存していました。公共部門の組織は、フォーム、記録、コミュニケーションにわたって Adobe のフォーマットとツールに依存していました。顧客データとソースコードが同じ公的なインシデントの枠組みに現れたとき、企業はアイデンティティ層と製品層の両方を保護しなければなりませんでした。

その二重の信頼の対象領域は、現在の Adobe のページに見ることができます。Trust Centerはセキュリティ、プライバシー、可用性、コンプライアンス、製品リソースを強調しています。セキュリティ概要は、安全な製品ライフサイクル、運用セキュリティ、インシデントレスポンス、セキュリティ速報について議論しています。インシデントレスポンスのページは、インシデントの監視と解決に対する現在のアプローチを説明しています。製品セキュリティのページは、反復可能な開発プロセスを説明しています。これらのページは現在のものであり、2013 年の証拠ではありません。それでもなお、現代のソフトウェア購入者が期待すべき統合された証明の構造を示しています。

購入者は、次のことを尋ねることができるべきです。顧客のパスワードが露出した場合、アイデンティティシステムでは何が変わったのか？　製品のソースコードにアクセスされた場合、製品セキュリティレビューでは何が変わったのか？　古いシステムがパスワード素材を保持していた場合、ライフサイクル管理では何が変わったのか？　顧客が認証情報をリセットしなければならなかった場合、他での再利用に対処するのにどのようなガイダンスが役立ったのか？　開示日以降も古いコードや古いアカウントストアがリスクを生み出した場合、その尾を閉じた証拠は何か？　同じアカウントがソフトウェア、支払い、サポート、アップデート、企業管理を解除する場合、製品の信頼とアイデンティティの信頼は分割できません。

ここはまた、ソフトウェアライフサイクルとロックインがビジネスの抽象概念ではなく、説明責任のトピックになる場所です。顧客は、主要なソフトウェアベンダーからすぐに離れることができないことがよくあります。ファイル、ワークフロー、スタッフのトレーニング、統合、調達スケジュールが彼らを依存させ続けます。そのロックインは、侵害後に有用な証拠を提供するベンダーの義務を増大させます。容易に退去できない顧客は、製品を安全に使い続ける方法を知る必要があります。曖昧な通知は、依存する顧客が自分自身の保証計画を作り出さなければならないままにするため、ロックインのコストを高めます。

したがって、Adobe の事例は今日のクラウドとサブスクリプションソフトウェアにも当てはまります。アカウントシステムは古いデータを蓄積します。ソースリポジトリとビルドシステムは高価値の標的になります。顧客はベンダーが管理するアイデンティティ層に依存します。公共部門のユーザーは、ファイルフォーマットとアップデートチャネルに依存します。アカウント素材と製品ソースコードを露出させる侵害は、ベンダーが新たな機密詳細を露出させることなく、私的な修復を公的な保証に変換できるかどうかのテストになります。

長期の尾こそが、通常説明責任が失われる場所である

長期にわたるアイデンティティリスクは、インシデントのカレンダーよりも長く続くため、ガバナンスが困難です。企業はリセットを完了し、調査を終え、製品セキュリティのページを更新し、新しいアドバイザリーを発表するかもしれませんが、その間顧客は攻撃者が古いデータセットから学習した認証情報の習慣を抱え続けます。だからこそ、Adobe の事例は価値があり続けるのです。それは、説明責任の単位が侵害されたデータベースだけではないことを示しています。それは、顧客、企業、セキュリティチームが、データベースが何を明らかにしたかについて部分的な知識しか持たずに行わなければならない、後の意思決定の連鎖なのです。

長期の尾は、害の意味も変えます。ユーザーは Adobe アカウント自体から金銭を失わないかもしれません。代わりに、標的型フィッシングを受けたり、古いパスワードが無関係なサービスで再利用されていたことを発見したり、支払い記録の確認に時間を費やしたり、他の人々に対する攻撃を改善するパスワードクラッキングコーパスの一部になったりするかもしれません。これらのコストは拡散し定量化が困難ですが、架空のものではありません。それらは、パスワード素材、メールアドレス、ヒント、アカウント履歴が、元のアカウントがロックされた後も再結合できるという事実から生じます。

企業は並行する問題に直面します。企業のアイデンティティチームには、Adobe アカウントに仕事用メールアドレスを使用したか、関連するパスワードを再利用した従業員がいるかもしれません。チームは、漏洩したシークレットを検索し、リセットを強制し、シングルサインオンの例外を確認し、スタッフに警告し、フィッシングキャンペーンを監視すべきかどうかを知る必要があります。この決定は、公的証拠の質にかかっています。ベンダーの通知がパスワードがリセットされたとだけ説明しているなら、企業のチームは残りを推測しなければなりません。通知が保管設計、影響を受けた母集団、非アクティブレコード、推奨される企業の行動を説明しているなら、それは有用なコントロールの入力になります。

公共部門の購入者には別の依存性があります。Adobe ツールはしばしば文書ワークフロー、フォーム処理、クリエイティブ制作、調達記録、公共コミュニケーションに組み込まれています。ソースコードの出来事は、すべての機関が製品の使用を中止することを要求しないかもしれませんが、アドバイザリー、アップデートの頻度、補償的コントロール、ベンダー保証に関する質問を引き起こすべきです。説明責任を果たすベンダーは、機密性の高いコードの詳細を公開する必要はありませんが、顧客が安全に事業を継続するための合理的な根拠を提供しなければなりません。

長期の尾は、通常、その頃には皆が疲れているため、説明責任が失われる場所です。報道陣は去り、法的手続きは遅く、ユーザーはパスワードをリセットし、プロダクトチームは予定された仕事に戻っています。しかし、攻撃者はインシデントのカレンダーを気にしません。彼らは再利用可能なシークレット、コードの洞察、弱い後続のコントロールを気にします。したがって、成熟した修復記録にはメンテナンスフェーズが必要です。更新された顧客ガイダンス、企業管理者向けのノート、製品セキュリティのフォローアップ、そして古いストアが単に忘れられたのではなくクリーンアップされたことの確認です。

証拠はセキュリティチームから顧客へと移動すべきである

Adobe の事例からのもう一つの教訓は、私的なセキュリティ作業が内容を空にすることなく翻訳されなければならないということです。セキュリティチームは、どのストアが露出したか、どの暗号方式が使用されたか、どのコードリポジトリに到達されたか、どの顧客グループに通知されたか、どのシステムが廃止されたかを知っているかもしれません。顧客は生の内部情報を必要としませんが、それらの事実の正確な公開版を必要とします。もし翻訳が重要な区別を除去してしまうなら、通知はそれを生み出した私的な証拠よりも有用性が低くなります。

翻訳は意図的に層状にされるべきです。第一層は個人ユーザー向けです。Adobe パスワードをリセットし、他で再利用したパスワードを変更し、フィッシングに警戒し、該当する場合は支払い手段を監視し、支払いカードデータが関与したかどうかを理解する。第二層は企業の管理者向けです。影響を受けた企業のメールドメインを特定し、認証情報の再利用を評価し、ログイン失敗を監視し、スタッフとコミュニケーションを取り、ベンダーのアドバイザリーを追跡する。第三層はソフトウェア購入者向けです。ソースコードレビュー、安全な開発の変更、セキュリティ速報の頻度、サポートのコミットメントについて尋ねる。第四層は規制当局と裁判所向けです。日付、数字、データカテゴリ、通知記録、修復の証明を保持する。

各層は、異なるレベルの技術的詳細で同じ事実を保存すべきです。それが矛盾を避ける最良の方法です。もしユーザーにパスワードのリセットだけを指示する一方で、管理者にはソースコードが露出したと伝えるなら、公共ファイルは断片化しているように見えます。もし弁護士が暗号化されたパスワード素材と説明する一方で、セキュリティアナリストがなぜその設計が依然としてクラッキングを助けたかを説明するなら、大衆は安心と警鐘を同時に聞くかもしれません。強力な説明責任のファイルは、各用語の実際的な結果を説明することで、それらの声明を両立可能にします。

Adobe の現在の Trust Center の文言が関連するのは、企業が現在、保証を公的な製品として理解していることを示しているからです。セキュリティプログラムの説明、インシデントレスポンスのページ、製品セキュリティのページ、セキュリティ速報のインデックスは、購入者が信頼を判断する方法の一部です。2013 年からの教訓は、それらの公的保証システムが、侵害によって複雑な物語を伝えることを強制される前に準備されているべきだということです。販売のためだけに存在する信頼ページは、その仕事をこなせません。証拠、アドバイザリー、説明責任のある所有者に接続された信頼ページなら、それができます。

したがって、修復ファイルは証拠のパイプラインとして設計されるべきです。内部のフォレンジック所見が顧客カテゴリになります。顧客カテゴリが通知や管理者ガイダンスになります。製品セキュリティの所見がアドバイザリーやライフサイクルの変更になります。法務記録は技術的記録を置き換えることなく、手続き上の説明責任になります。基準は将来の保証のためのベンチマークになります。このパイプラインが欠けていると、各対象者は独自の解釈を構築し、企業は自らの修復の公的な意味に対するコントロールを失います。

完全な Adobe 修復ファイルは尾を保存するだろう

完全な修復ファイルは、検証された時系列から始まるでしょう。侵入がいつ検知されたか、顧客データの露出がいつ確認されたか、ソースコードアクセスがいつ確認されたか、影響を受けた数がいつ変わったか、パスワードリセットがいつ行われたか、顧客通知がいつ出されたか、非アクティブレコードがいつ評価されたか、そして製品セキュリティレビューやアドバイザリーがいつ続いたかを列挙するでしょう。各日付は、その時点で利用可能だった証拠を特定すべきです。ポイントは早期の不確実性を罰することではなく、後日の要約が顧客の意思決定を形作った不確実性を消し去るのを防ぐことです。

第二部は、保管設計の記録でしょう。関与したパスワード保管システム、ソルト、ワークファクター、暗号化またはハッシュ化、パスワードヒント、非アクティブレコード、より強力な保管への移行について説明するでしょう。また、どのレガシーストアが使用停止されたか、どのバックアップが保持されたか、古い認証情報素材がどのように有用性を減じられたかについても説明するでしょう。顧客は秘密の実装詳細を必要としません。彼らは古い設計がリスクの転嫁を止めたという確信を必要とします。

第三部は、顧客行動記録でしょう。Adobe アカウントのリセットを、他での再利用パスワードのリスクから分離するでしょう。企業管理者には、社内の認証情報露出を検索するためのガイダンスを与えるでしょう。個人顧客には、再利用したパスワードの変更、支払いアカウントの監視、侵害に基づくフィッシングへの対抗について明確な助言を与えるでしょう。クレジット監視や個人情報盗難支援が特定の集団に適用されるかどうかを説明するでしょう。支払いカードの露出、アカウント ID の露出、パスワードの露出、ソースコードの露出の違いを保持するでしょう。

第四部は、製品セキュリティ記録でしょう。どの製品ソースコードリポジトリが関与したか、どの製品ラインがレビューされたか、関連するのであればどのアドバイザリーやパッチがあったか、顧客が将来のセキュリティ速報をどのように監視すべきかを説明するでしょう。また、知られていないことも説明するでしょう。ソースコードの露出は、あらゆる製品での確認された脆弱性と同じではありません。しかし、それは保証の負荷を変えます。ソフトウェアベンダーは、露出を念頭にコードと開発パイプラインを調査したことを示すことができなければなりません。

最後に、修復ファイルはクロージャの基準を持つべきです。クロージャは、公的な関心が去ったことや、最初のパスワードリセットが終わったことを意味すべきではありません。クロージャは、古いアカウントストアが棚卸しされ、保管設計が強化され、非アクティブレコードが対処され、製品ソースの露出がレビューされ、顧客ガイダンスが提供され、残る不確実性が明示されたことを意味すべきです。Adobe にとって、長期的な教訓は、パスワード保管の証拠がニュースサイクルよりも長く存続しなければならないということです。

読者向け証拠ファイル

本記事では、Adobe 2013 年顧客データ侵害、パスワード保管、ソースコード露出、顧客リセット、長期アイデンティティ説明責任の記録のための読書ファイルとして、以下の公的情報源を使用しています。企業の発表は、当時 Adobe が公に述べたことの証拠として扱っています。ニュースとセキュリティ分析は、時系列と技術的文脈のために用いています。現在の企業のトラストページと基準ガイダンスは、2013 年の内部コントロールを証明するためではなく、現代の修復証拠を定義するために使用しています。

この証拠ファイルは、パスワード保管、非アクティブレコード、ソースコード管理、アカウントリセット、製品保証、ソフトウェア購入者の依存を跨ぐ長期的な問題のため、意図的に単一の発表よりも広範になっています。公的記録は、読者が顧客アイデンティティの修復と製品セキュリティの修復を、それらの義務が無関係であるかのように装うことなく、分離できるようにすべきです。

取締役会レビューの質問

取締役会のレビューでは、誰がレガシーアカウントストアを所有していたか、誰がパスワード保管の移行を所有していたか、誰が顧客通知を所有していたか、誰がソースコードリポジトリアクセスを所有していたか、誰が製品セキュリティレビューを所有していたか、誰が企業顧客ガイダンスを所有していたか、誰がクロージャを所有していたかを問うべきです。答えは努力の物語ではなく、管理マップであるべきです。管理マップは、古いシステムが皆のリスクでありながら、誰の名前付きの義務にもならないままでいることを難しくします。

レビューはまた、非アクティブレコードがガバナンスされているという証拠を要求すべきです。古いアカウント、古いバックアップ、古いヒント、古い認証ストアには、所有者、保持理由、保護基準、削除日があるべきです。製品のサブスクリプションへの移行がアカウントアイデンティティの価値を高めるなら、企業は攻撃者より先に古いストアを再検討すべきです。レガシーが無害を意味するわけではありません。

取締役会は、ソースコード露出のプレイブックを要求すべきです。リポジトリの分離、認証情報とシークレットのローテーション、コードレビューのトリガー、顧客アドバイザリーのルール、製品強化レビュー、依存する顧客のための証拠を定義すべきです。ソースコードの出来事は、すべての内部リポジトリに関する公開の詳細を必要としないかもしれませんが、ソフトウェアを使い続けなければならない顧客には十分な保証を必要とします。

この特定の事例について、取締役会のレビューは、誰がパスワード保管の設計、ソースコード保護、侵害通知、顧客リセット、露出フィールドの最小化、和解の証拠、そして開示日以降もレガシーアカウントシステムがリスクを転嫁し続けなかったことの証明を実質的に管理していたのかを問うべきです。答えには、日付付きの証拠、指名された所有者、パスワード保管の移行の証明、非アクティブレコードのクリーンアップ、製品セキュリティレビュー、顧客行動ガイダンス、そして最初のリセットが完了したときに消えなかった残余の不確実性が含まれるべきです。