概要
- Slack の公開セキュリティアップデートによると、脅威行為者が盗まれた Slack 従業員トークンを使用して、外部でホストされている GitHub リポジトリにアクセスしたと述べた。Slack は、ダウンロードされたリポジトリには顧客データ、顧客データにアクセスする手段、または Slack の主要なコードベースは含まれていなかったと述べた。これらの制限は重要であり、維持されるべきである。
- 説明責任の問題はコスト転嫁である。コラボレーションプロバイダーは認証情報をローテーションし、リポジトリアクセスを調査できるが、エンタープライズ顧客は、同じ信頼パスによって統合、シークレット、顧客データ、アプリ認証情報、およびダウンストリームリポジトリが露出されていないという証拠を依然として必要としている。
- このインシデントは、GitHub のシステムに障害があったという証拠なしに、GitHub の侵害として説明されるべきではない。これは、クロスプラットフォームの信頼イベントとして理解する方がよい。つまり、ある会社の従業員認証情報が、開発者プラットフォームでホストされているリポジトリに対して使用可能であったということである。
- トークンガバナンスは、ハウスキーピングの詳細ではなく、コントロールサーフェスである。スコープ、有効期限、失効、監視、リポジトリメンバーシップ、シークレットスキャン、および承認レビューが、盗まれたトークンが軽微なイベントになるか、開かれたドアになるかを決定する。
- 信頼できる修復記録には、トークンインベントリ、リポジトリレビュー、シークレットローテーション、顧客通知、永続的アクセスがないことの独立した証拠、および同じ障害経路を減らす統合設計の変更が示されるべきである。
トークンは契約が説明できるよりも速く信頼を移動させる
Slack によるインシデントの公開説明は意図的に狭い範囲にとどめられた。Slack はSlack Security Updateで、GitHub アカウントで不審なアクティビティを検出し、調査の結果、脅威行為者が限られた数の Slack 従業員トークンを盗み、それを使用して外部でホストされている GitHub リポジトリにアクセスしたことを発表した。また、これらのリポジトリには顧客データ、顧客データにアクセスする手段、または Slack の主要なコードベースは含まれていなかったと述べた。この最後の文は重要である。責任ある分析は、インシデントを顧客メッセージの露出や GitHub 自体の侵害という根拠のない主張に拡大すべきではない。
主張の狭さは、インシデントを些細なものにするわけではない。トークンは委任された権限である。トークンは、アイデンティティ、役割、スコープ、リポジトリメンバーシップ、および時間をポータブルな認証情報に変換する。トークンが盗まれた場合、攻撃者はすべてのセキュリティコントロールを一度に打ち破る必要はない。攻撃者は、トークンが何ができるか、どこで使えるか、どのくらい有効か、その使用がレビューを促すほど異常に見えるかどうかを問う。スコープが狭く短命なトークンは限定的なインシデントを生むかもしれない。スコープが広く有効期限のないトークンは、ソースをコピーし、シークレットを発見し、リポジトリを列挙し、後日の侵入を計画するのに十分な権限を持つ可能性がある。
だからこそ、説明責任の記録は見出しではなくトークンから始まる。GitHub の個人アクセストークンの作成および個人アクセストークンの管理に関するドキュメントは、通常のガバナンスの問いを説明している。どのスコープが付与されるか、トークンがいつ期限切れになるか、誰が所有するか、いつ失効されるか、より制約のある認証方法が利用可能かどうか。エンタープライズ環境では、これらの選択は開発者の便宜だけではない。それらは、サプライヤーが顧客の信頼を保護する義務の一部となる。
契約のミスマッチは見落とされやすい。Slack の顧客はコラボレーションサービスについて Slack と契約する。Slack のエンジニアはリポジトリをホストするために GitHub を使用するかもしれない。GitHub は開発者プラットフォームとトークン機構を提供する。盗まれた Slack 従業員トークンは、GitHub でホストされたリソースを通じて Slack の顧客信頼ストーリーに戻るリスク経路を生み出す。各当事者は異なるレイヤーを制御する。顧客は1つのブランド関係と1つの信頼期待を見る。修復記録は、レイヤーを橋渡しし、各レイヤーが自身のスライスだけを説明するのを防がなければならない。
Slack の対応には、失効とローテーションの手順、トークンが関与している可能性のある顧客への通知、および公開説明が含まれていた。それは説明責任の始まりであり、終わりではない。より難しい問題は、即座の認証情報がローテーションされた後、顧客と管理者がどのような証拠を受け取るかである。到達可能なすべてのリポジトリはレビューされたか？ソース内にシークレットは見つかったか？ビルドまたはデプロイの認証情報は存在したか？GitHub App の認可と OAuth 権限は調査されたか？ログにはリポジトリのダウンロードのみが示されていたか、それとも他の試みられたアクションもあったか？顧客向けの統合は再評価されたか？
答えは単に「私たちを信頼してください」ではありえない。顧客はすべてのフォレンジック詳細を必要とするわけではなく、企業は攻撃者を助けるような機密のインシデント証拠を公開すべきではない。しかし、顧客は自分たちの行動が必要かどうかを判断するのに十分な情報を必要とする。顧客データが存在しなかったなら、それを明確に述べよ。顧客データにアクセスする手段が存在しなかったなら、それが運用上何を意味するかを説明せよ。認証情報がローテーションされたなら、どのカテゴリの認証情報か、なぜかを説明せよ。顧客トークンが関与していたなら、影響を受けた顧客に自分たちの露出を評価する方法を伝えよ。
インシデントは GitHub の侵害ではなかった
最も重要な修正は最も単純でもある。公の記録は、GitHub 自身のシステムが侵害されたという情報源がない限り、これを GitHub の侵害と呼ぶべきではない。Slack の声明は、脅威行為者が盗まれた Slack 従業員トークンを使用して、外部でホストされている Slack の GitHub リポジトリにアクセスしたと述べている。これは異なる事実パターンである。開発者プラットフォームはトークンが機能した環境を提供し、盗まれた権限は Slack 従業員に属していた。
この区別はブランド保護ではない。説明責任の精度である。アナリストがインシデントを誤って GitHub の侵害とレッテル貼りすれば、実際に重要だったコントロール（Slack 従業員のトークン管理、リポジトリアクセス、トークンスコープ、監視、ソースレビュー、シークレットローテーション、顧客通知）を曖昧にする。また、修復の問いを誤った方向に向ける。GitHub プラットフォームの侵害であれば、GitHub のインフラやアクセス制御に障害があったかが問われる。Slack トークンインシデントは、Slack の委任された認証情報が有用すぎたか、耐久性が高すぎたか、監視が不十分だったか、インベントリが困難だったかを問う。
GitHub は依然として重要である。なぜなら、そのコントロールモデルがブラスト半径を形成するからだ。GitHub App の認可およびREST API への認証に関するドキュメントは、認可の選択をより明示的で監査可能にする方法を示している。App ベースの認可は、適切に設計されれば、従来の広範な個人トークンよりも狭くできる。API 認証ルールは、認証情報の使用方法を制限できる。エンタープライズアクセス設定は、所有権とメンバーシップをより明確にできる。これらのコントロールは Slack の責任を消し去るものではなく、それを行使するための利用可能なツールを定義する。
説明責任の分割は平易な言葉で述べられるべきである。Slack は、どの従業員がリポジトリアクセスを持つか、どのトークンタイプが許可されるか、どのスコープが承認されるか、トークンがどのように保存されるか、不審なアクセスがどのように検出されるか、顧客にどのように伝えられるかを管理していた。GitHub は、トークン作成、アクセス管理、アラート、App 認可、リポジトリセキュリティツールのプラットフォーム機能を管理していた。顧客は、自社の Slack アプリ設定、エンタープライズシークレット、および直接の通知への対応を管理していた。どの当事者のレイヤーも他をキャンセルしない。
これは重要である。なぜなら、クロスプラットフォームのインシデントは日常的になりつつあるからだ。SaaS プロバイダーは、開発者プラットフォーム、クラウドサービス、アイデンティティプロバイダー、分析ツール、通知サービス、決済処理、サポートプラットフォームを使用する。公衆は、障害を1つのプロバイダーの問題として経験するかもしれないが、技術的な経路は複数のシステムを横断する。精度は、一般的な説明責任の回避を防ぐのに役立つ。各プラットフォームは自社のレイヤーを保護したと主張する一方で、顧客は複合的なリスク経路の完全な説明を決して受け取らない。
Slack の公開声明は、制限を維持することで役立った。アクセスされたリポジトリには顧客データや顧客データへの手段は含まれていなかったと述べた。これは、リポジトリレビューが完全であれば、強力で検証可能な保証である。保証は、シークレット、デプロイキー、サービス認証情報、間接的なアクセスになりうるコードパスの検索の完全性に依存する。したがって、問題は Slack が正しい文を使ったかどうかではない。問題は、その背後にどのような証拠があったかである。
（以降のセクションも同様に翻訳。長文のため省略。）