OKTA はサポート成果物をサードパーティの信頼境界の説明責任テストとした

要約

• OKTA のサポートシステム侵害は説明責任のテストとなった。サポートケースファイルやトラブルシューティングの成果物には、セッションクッキー、トークン、管理者コンテキスト、テナント情報など、中核となる本番のアイデンティティサービス自体が侵害されていなくても顧客環境に影響を与えるのに十分な強力な情報が含まれる可能性があるためである。
• OKTA の最初の2023年10月の勧告、11月の根本原因と是正措置の投稿、その後の更新と推奨アクション、そして2024年2月の調査終了ノートがプロバイダーの記録を形成する。
• 1Password、BeyondTrust、Cloudflareからの顧客報告は、サポート成果物がテナントレベルの対応作業や顧客側の封じ込めにどのように変換されるかを示している。
• OKTA の SEC 提出のForm 8-K、Exhibit 99.2、Form 10-Q、Form 10-Kが重要なのは、公開企業の開示によりサポートインシデントが顧客関係、サードパーティプロバイダーリスク、ビジネスへの影響の文脈に置かれたからである。
• 修復の課題は、OKTA とその顧客が、サポートケースファイルの処理、HAR の編集、セッションのバインド、サポートシステムのプロビジョニング、通知、顧客による検知が、アイデンティティプロバイダーのサポートワークフローが偶発的に持つ可能性のある権限に現在適合していることを証明できるかどうかである。

サポートはアイデンティティ境界の一部となった

サポートシステムは製品境界の外部として扱われることが多い。それらはカスタマーサービスのワークフロー、ケース管理ツール、ファイル添付、メールスレッド、トラブルシューティング記録に存在する。OKTA の2023年のインシデントはその分離に挑戦した。同社は10月20日の勧告で、攻撃者が盗まれた認証情報を使用してサポートケース管理システムにアクセスし、サポートケースの一部として特定の顧客がアップロードしたファイルを閲覧したと述べた。OKTA はまた、HAR ファイルにクッキーやセッショントークンなどの機密データが含まれる可能性があると警告した。

これが説明責任の要である。サポート成果物に有効なセッションクッキーやトークンが含まれている場合、メインのアイデンティティサービスが侵害されていなくても、それは鍵のように機能する可能性がある。サポートワークフローは、認証されたセッションを表す可能性のある資料を受け取るため、実質的な信頼境界の一部となる。境界は製品図が示す場所にあるのではない。それは機密の権限が保存、表示、コピー、再生、または悪用される可能性がある場所にあるのだ。

OKTA の11月3日の根本原因と是正措置の投稿は、9月28日から10月17日までのアクセス、134の顧客に関連するファイル、アクセスされたファイルのセッション成果物を使用してハイジャックされた5つの顧客セッション、侵害されたサポートサービスアカウント、そして従業員の個人 Google プロファイルまたはデバイスが関与する最も可能性の高い認証情報漏洩経路について説明した。この記録は企業が作成したものであり、最も可能性の高い経路を独立した証拠として過大評価すべきではない。しかし、重要な事実は直接的である。OKTA はサポートファイルからのセッション成果物が5つのセッションをハイジャックするために使用されたと述べた。

本番サービスの侵害とサポート成果物の侵害の区別は重要である。OKTA は本番の OKTA サービスは侵害されていないと述べた。責任ある分析はそれを保持すべきである。しかし、それを保持してもインシデントを軽視することにはならない。アイデンティティプロバイダーにとって、顧客の信頼には、テナントの証拠、管理者のトラブルシューティング、サポートファイル、通知を扱う周囲のワークフローが含まれる。本番サービスは無傷のままであっても、サポートワークフローがテナントリスクを生み出す可能性がある。

それが、このインシデントが信頼境界の記録に属する理由である。アイデンティティプロバイダーは顧客に認証とアクセス決定を集中化するよう求める。周囲のサポートシステムは、その権限の一部を一時的に保持できるかのように統治されなければならない。サポートチケットは単なる会話ではない。それはアクセス経路になり得るのだ。

HAR ファイルが診断の利便性をセキュリティ問題にした

HTTP Archive ファイルは、トラブルシューティングのためにブラウザのネットワークアクティビティをキャプチャするのに役立つ。また、機密資料を含む可能性もある。OKTA のHAR ファイルの生成に関するドキュメントは、ファイルを OKTA に送信する前に機密情報や個人識別情報を削除するよう顧客に警告している。Chrome のネットワークリクエストの HAR ファイルへの保存に関する開発者ドキュメントは、ブラウザのエクスポート動作と機密ヘッダーの現在の処理を説明している。これらのソースは診断上のトレードオフを示している。サポートは問題を再現するために十分な詳細を必要とするかもしれないが、同じ詳細がセッションを露出させる可能性がある。

OKTA のセッションクッキーに関する開発者ガイドは、OKTA プラットフォームでのブラウザセッションの仕組みを説明している。OWASP のセッション管理チートシートと NIST のセッション管理実装リソースは一般的なセキュリティ原則を提供している。セッション識別子は一時的にそれを生成した認証と同等になり得るため、開示はなりすましを可能にする可能性がある。これらは一般的なソースであり、OKTA インシデントの調査結果ではないが、サポートにアップロードされたファイルが危険であり得る理由を説明している。

問題は HAR ファイルを決して使用すべきでないということではない。問題はそのリスクを第一級のサポート管理問題として扱うべきであるということだ。顧客には明確な警告、ローカルでの編集ツール、可能な限りの自動サニタイズ、最小限の保持デフォルト、アップロード後にセッションをローテーションするタイミングに関する指示が必要である。サポートチームには、機密コンテンツの閲覧を最小限に抑え、ファイルへのアクセスを記録し、管理者コンテキストからのファイルにはより強力な管理を要求するワークフローが必要である。

Cloudflare のHAR Sanitizer の導入に関する投稿は、顧客側の教訓を実用的なツールに変えたため関連性がある。共有前に選択された機密資料を削除する。それは、どのサニタイザーもすべての認証情報が削除されることを保証できるわけではなく、サポートが機密データを必要としないこともあるという意味ではない。それは編集がワークフローとして設計可能であり、ユーザーの記憶に委ねられるべきではないことを示している。

より大きな教訓は、診断の利便性がしばしば権限を借りるということである。ログイン問題を解決するために収集されたファイルには、そのログインを偽装するために必要な証拠が含まれている可能性がある。速度のために設計されたサポートワークフローは、意図せずして本番のアイデンティティ経路に適用される規律を回避する可能性がある。トラブルシューティングの成果物がテナントを解放できるのであれば、アップロードプロセス、保持プロセス、サポートアクセスプロセス、セッションローテーションのガイダンスはアイデンティティ管理として扱われなければならない。

顧客報告がダウンストリームの実態を明らかにした

影響を受けた顧客の報告はインシデントを具体的にした。1Password のOkta インシデント報告は、予期しない管理アクティビティ、封じ込め、そして後にイベントを OKTA のサポート侵害に関連付ける付録を記載した。BeyondTrust のOKTA サポートユニット侵害の報告は、サポートが要求した HAR ファイル、30分以内のセッションクッキーの再生、管理デバイスポリシーの拒否、API アクティビティ、バックドアアカウントの試行を説明した。Cloudflare の緩和報告は、OKTA サポートチケットに関連する管理セッショントークンの検出と、本番または顧客への影響前の封じ込めを説明した。

これらの報告はすべての OKTA 顧客に関する普遍的な主張ではない。それらは公開された顧客環境に対する一次記録である。それらの価値は、サポート成果物リスクがテナント側からどのように見えたかを示す点にある。顧客は異常なアクティビティを検出し、セッションを取り消し、認証情報をローテーションし、管理アクションを調査し、プロバイダーに情報を要求し、自社のユーザーに何を伝えるかを決定しなければならなかった。インシデントは OKTA のサポート組織内にのみ封じ込められたわけではない。

顧客報告はまた通知のタイミングの重要性を示している。プロバイダーがサポート成果物への疑わしいアクセスを確認した場合、影響を受ける顧客は行動するための十分な情報を必要とする。ユーザー識別子、ファイル識別子、アクセス時間、指標、可能性のあるセッションリスク、推奨されるローテーションが必要である。曖昧な通知は顧客が過小反応するか過剰にローテーションするかのいずれかにつながる可能性がある。両方にコストがかかる。過小反応はセッションを露出させる。過剰ローテーションはセキュリティと運用の時間を消費する。

Cloudflare のその後のThanksgiving 2023セキュリティインシデント報告も修復の教訓の一部である。Cloudflare は、10月の露出からの1つのアクセストークンと3つのサービスアカウント認証情報がローテーションされておらず、後に Atlassian システムに影響を与える別の11月のインシデントで使用されたが、顧客やグローバルネットワークへの影響は報告されていないと述べた。これは元の OKTA サポート侵害を後の攻撃者に帰属させるものではない。それはサポート成果物インシデント後のローテーションの見逃しがフォローオンリスクになる可能性があることを示している。

したがって、サポート境界は顧客のインシデント対応にまで拡張される。プロバイダーはサポートシステムを管理するが、顧客はテナントをローテーションし、監視し、検証しなければならない。プロバイダーが迅速に正確な成果物とアクセスデータを提供できない場合、顧客の対応は推測作業になる。これは、顧客がテナント側の管理を所有している場合でも、プロバイダーの説明責任の問題である。

より広範なレポート露出が悪用の経済性を変えた

OKTA の11月29日の更新と推奨アクションは、特定の顧客人口におけるサポートシステムユーザーの名前とメールアドレスを含む、フィルタリングされていないレポートがダウンロードされたことを説明し、製品と環境の除外があった。OKTA は、レポート内のユーザーの99.6%は氏名とメールアドレスのみが露出したと述べた。この人口は134の顧客ファイルアクセスグループと5つのハイジャックされたセッションとは別である。これらのグループを区別して維持することは不可欠である。

より広範なレポートは依然として重要だった。それは悪用の経済性を変えたからである。サポートシステムに関連する人々の名前とメールアドレスは、攻撃者が管理者、ヘルプデスク、セキュリティチーム、アイデンティティサポートの役割を標的にするのに役立つ可能性がある。FINRA のOKTA カスタマーサービスシステムに関連する可能性のあるフィッシング攻撃に関するサイバーセキュリティアラートは、加盟企業にフィッシングやソーシャルエンジニアリングのリスクの可能性について警告した。このアラートはリスクガイダンスであり、露出したすべての連絡先記録が悪用されたことの証明ではない。しかし、それはサポートユーザーの連絡先データが些細なものではない理由を示している。

サポート連絡先は価値がある。なぜなら、それらはアイデンティティシステムにアクセス権、権限、または影響力を有する可能性が高い人々を特定するからである。ランダムな従業員へのフィッシングメールは一つのことである。公開されたプロバイダーインシデント後に既知のサポート管理者への標的型メッセージは別のことである。盗まれたデータにはパスワードやトークンが含まれていないかもしれないが、攻撃者の調査コストを削減する可能性がある。アイデンティティシステムでは、調査コストの低下は重要である。

OKTA のForm 8-KとExhibit 99.2は、11月の更新を公開企業の開示チャネルに配置した。この提出姿勢は SEC を事実調査者にするものではない。それは OKTA が更新を正式な公開配布に値するほど重要であると扱ったことを示している。

悪用連絡先の教訓は直接的である。サポートシステムのユーザーリストは機密の運用マップとして扱われるべきである。それらはセッションクッキーほど機密ではないかもしれないが、攻撃者が最も操作したい人々を特定する。それらのリストへのアクセス、保持、エクスポート、監視管理は、そのソーシャルエンジニアリング価値に一致するべきである。

タイポグラフィノート

サードパーティホスティングは説明責任を OKTA の境界外に移動させなかった

OKTA の2024年度Form 10-Kは、侵害されたサポートシステムがサードパーティのサービスプロバイダーによってホストされていたと説明し、プロバイダー監督リスクについて議論した。サードパーティホスティングは、サプライヤー管理層を追加するため重要である。それは OKTA から顧客への説明責任の境界を移動させるものではない。顧客は OKTA サポートに成果物を提供した。OKTA はそれらの成果物を扱うサポートワークフローを選択、設定、プロビジョニング、監視、統治した。

サードパーティシステムは現代のクラウド運用では普通である。企業は外部のケース管理プラットフォーム、ストレージサービス、コミュニケーションツール、サポートアプリケーションを合理的に使用する可能性がある。説明責任の問いは、プロバイダーがそれらが保持するデータの機密性に従ってそれらを統治しているかどうかである。アイデンティティプロバイダーのサポートシステムは、低機密性のチケットキューとは異なる扱いを受けるべきである。テナントリスクが異なるからである。

サプライヤー統治には、最小権限のサービスアカウント、強力な認証情報保護、セッション管理、保持制限、ファイルアクセスログ、エクスポート管理、異常検知、迅速な証拠作成が含まれるべきである。また、サポートシステムの認証情報が存在する場合の従業員の個人プロファイル、ブラウザ、デバイスに関する明確なルールも含まれるべきである。OKTA の11月の根本原因投稿は、従業員の個人 Google プロファイルまたはデバイスが関与する最も可能性の高い経路について議論した。その正確な経路が独立して証明されているかどうかに関わらず、それは基本的なサプライヤーとエンドポイントの問題を浮き彫りにする。サポート認証情報が消費者向け同期や個人使用チャネルを通じて露出する可能性はあるか？

サポートシステムはまた、異なる通知モデルを必要とする。攻撃者が顧客がアップロードした成果物にアクセスした場合、プロバイダーはどの顧客、どのファイル、どのケース、どのユーザー、どのアクセス時間、どの推奨アクションかを把握すべきである。システムのログがいくつかのナビゲーション経路を捕捉しなかった場合、OKTA が根本原因の説明で述べたように、調査は最初にイベントを見逃す可能性がある。それは単なるログの欠陥ではない。それは顧客の封じ込め速度に直接影響する。

したがって、サードパーティ層はプロバイダー統治の証拠の必要性を増大させ、減少させるものではない。顧客はプロバイダーのサポートベンダーを直接検査することはできない。彼らは OKTA がその関係を管理することに依存する。サポートベンダーまたはサポートワークフローがテナント成果物に触れる場合、プロバイダーは委任されたシステムがアイデンティティ信頼境界の一部として統治されていることの証明を顧客に負う。

検知はサポートケースとテナントイベントを関連付けるべきである

OKTA のシステムログのユーザーサインインとリカバリイベントに関するセキュリティ投稿は、顧客がユーザー、IP、外部セッション ID、認証、MFA、パスワードリセット、リカバリイベントで検索する方法を説明している。そのガイダンスは、サポートインシデント中に顧客が必要とした種類の相関関係を指し示すため有用である。サポートケースの成果物、セッション識別子、疑わしい IP、管理アクションは迅速に関連付け可能であるべきである。

顧客はすべての接続を手動で推測する必要があるべきではない。サポート成果物がプロバイダーシステムでアクセスされた場合、プロバイダーは可能な限りどのテナント側のセッションまたはアカウントがリスクにさらされているかを顧客に伝えることができるべきである。顧客はそのセッションのログを検索し、それを取り消し、関連する認証情報をローテーションし、管理変更を検証できるべきである。プロバイダー側の証拠と顧客側のテレメトリは一致しなければならない。

これは、顧客の爆発半径が大きくなる可能性があるため、アイデンティティプロバイダーにとって特に重要である。管理者セッションはアカウントを作成し、MFA 設定を変更し、ポリシーを変更し、アプリケーションを追加し、設定を抽出し、永続性を準備することができる。管理デバイスポリシーは再生試行をブロックする可能性があるが、BeyondTrust が説明したように、顧客は依然として試行されたピボットを調査しなければならない。完全な侵害の成功がないからといって、対応負担がないわけではない。

検知は時間も考慮すべきである。セッション成果物は期限切れになるが、常に即座に切れるわけではない。一部のクッキーやトークンは再生に十分な長さで有効なままである可能性がある。一部の顧客管理はセッションをデバイスやネットワークにバインドする。一部はそうしない。一部の顧客はプレミアムログを持っており、一部は保持期間が短い。プロバイダーの推奨アクションは顧客の成熟度全体で現実的であるべきである。

このインシデントはまた、デフォルトのセッション強化の根拠となる。セッションバインド、管理セッションの短いライフタイム、機密アクションに対する再認証、フィッシング耐性 MFA、デバイス状態チェック、サポート関連のセッション異常に関するアラートはすべて、盗まれたサポート成果物の価値を減らすことができる。これらの管理はサポートリスクを排除しないが、サポートファイルが悪用される可能性のある期間を縮小する。

公開企業の開示はビジネス信頼の損害を示した

OKTA の2023年10月31日終了四半期の Form 10-Qは、インシデントの評判、顧客関係、財務結果、潜在的な負債への影響を枠付けしたため重要である。それは証券用語以上のものである。アイデンティティプロバイダーは信頼を製品の一部として販売することを認識している。サポートシステムの侵害は、中核サービスが稼働し続けていてもその信頼を損なう。

アイデンティティインシデントの市場への影響は、即時の解約やインシデントコストだけではない。顧客はサポート慣行、トークン処理、テナントログ、ベンダーリスク、更新条件、代替アイデンティティプロバイダーを再評価する可能性がある。セキュリティチームは自社のテナントが侵害されていないことを証明するために時間を費やす可能性がある。監査人は証拠を求める可能性がある。規制当局はより強力なベンダーリスク管理を期待する可能性がある。サポートインタラクションは、顧客が何をアップロードするかについてより慎重になるため、遅くなる可能性がある。

Form 10-K のサードパーティプロバイダーリスクの文言は、イベントをより広範な統治フレームに配置する。サポートシステムがサードパーティのサービスプロバイダーによってホストされている場合、アイデンティティベンダーの独自のリスクプログラムにはそれらのシステムが含まれていなければならない。顧客は、製品が失敗したときに使用するよう求められるサポートワークフローを除外する製品境界を受け入れることはできない。

したがって、公開開示は運用の具体性について評価されるべきである。OKTA は影響を受ける人口を明確に特定したか？ファイルアクセスとレポート露出を分離したか？指標と推奨アクションを提供したか？フィルタリングされていないレポートが再構築されたときに範囲を更新したか？過大主張せずに是正措置を説明したか？公開記録にはいくつかの更新が含まれており、それは良いことである。説明責任の問いは、各更新が十分に迅速に到着し、顧客が行動するのに十分な詳細を含んでいたかどうかである。

このケースはまた、開示がどのように成熟するかを示している。最初の通知は不完全かもしれない。その後の根本原因分析は事実を修正または拡張するかもしれない。終了ノートは外部調査を要約するかもしれない。公開企業の提出書類はビジネスリスクを議論するかもしれない。顧客はどの文書がどの役割を果たしているかを理解する必要がある。ブログの勧告は完全なフォレンジック報告ではない。提出書類はテナント固有の指標リストではない。終了ノートはすべての顧客アクションの証明ではない。

サポート成果物にはライフサイクル管理が必要である

最も実用的な修復はサポート成果物のライフサイクルである。アップロード前に、顧客は明確な指示と、できれば機密資料を削除するツールを受け取るべきである。アップロード中に、サポートシステムは成果物を分類し、アクセスを制限し、トークンや秘密が含まれている可能性がある場合に警告するべきである。サポート処理中に、ファイルの表示とダウンロードは記録され、異常なアクセスは警告を発するべきである。解決後、成果物は保持ポリシーの下で期限切れになるか削除されるべきである。成果物がインシデント中にアクセスされた場合、顧客は正確なアクションガイダンスを受け取るべきである。

そのライフサイクルは、他の多くのサポートデスクよりもアイデンティティプロバイダーのサポートでより厳格であるべきである。アイデンティティプロバイダーは企業アクセスの鍵の近くに位置する。サポート成果物には、管理者セッション、アイデンティティプロバイダーの設定、アプリケーション接続、ユーザー詳細、トラブルシューティングトレースが含まれる可能性がある。それらの成果物を通常の添付ファイルとして扱うことは、機密性と管理の間のミスマッチを招く。

顧客も独自のライフサイクルを必要とする。可能な限りライブの管理者セッションキャプチャをアップロードしないようにし、サニタイズされた HAR エクスポートを使用し、トラブルシューティング用の短命なテストセッションを作成し、共有後にセッションを取り消し、どの認証情報やトークンがサポートファイルに表示される可能性があるかを文書化するべきである。サポート成果物のローテーションを標準のインシデント対応項目にすべきであり、後付けにすべきではない。

しかし、顧客の規律はプロバイダーの設計を代替できない。プロバイダーはすべての顧客がプレッシャーの下で完全にサニタイズすると想定できない。ワークフローは人間のエラーに対して回復力を持つべきである。顧客がライブセッションクッキーを含むファイルをアップロードした場合、システムは短い保持、制限されたアクセス、編集、検出、迅速な通知によって害を減らすべきである。サポートセキュリティにおいて、「警告を読め」では十分ではない。

修復記録には測定可能な証拠を含めるべきである。サポートファイルにアクセスできる人の減少、より強力なサービスアカウント管理、改善されたログカバレッジ、自動化されたレポートエクスポート保護、より短い成果物保持、顧客固有の影響報告、セッションリスクの推奨、テストされた通知手順など。サポートセキュリティが改善されたという公の主張は、具体的な管理カテゴリのリストよりも弱い。

信頼境界の修復は顧客に見える形で行われなければならない

OKTA の2024年2月の調査終了ノートは、Stroz Friedberg が調査を完了し、以前に特定された活動を超える証拠は見つからず、カスタマイズされた影響報告、規制当局および法執行機関への通知、サポートシステムのプロビジョニングと保持のレビュー、その後の管理に言及したと述べた。その終了は意味があるが、外部の公開記録は制限されたままである。完全なフォレンジック報告が終了 URL で公開されなかったためである。

したがって、顧客に見える修復は不可欠である。企業は OKTA のサポートインフラのすべての機密詳細を必要とするわけではない。ベンダーリスクを評価するのに十分な証拠が必要である。どの管理ファミリーが変更されたか、どの顧客アクションが推奨されるか、サポート成果物がどのように保持されるか、エクスポートがどのように統治されるか、サービスアカウントがどのように保護されるか、ファイルアクセスがどのように記録されるか、将来の成果物アクセスがどの程度迅速に報告されるか。

永続的な説明責任基準は、サポートワークフローが決して侵害され得ないということではない。それはサポートワークフローがその権限に比例した管理なしにテナント権限を静かに保持すべきではないということである。サポートが強力な成果物を受け取らなければならない場合、ワークフローは最小化、編集、バインド、期限切れ、監視、通知を行うべきである。サードパーティのサポートシステムがそれらの成果物をホストする場合、ベンダー統治は信頼資料やインシデント報告で顧客に見える形で示されるべきである。

OKTA のインシデントはまた、悪用連絡先リスクのより広範な経済性に属する。サポートユーザーリスト、既知の管理者、最近のインシデント、信頼できるベンダーブランドは、フィッシングやソーシャルエンジニアリングで組み合わせることができる。サポートシステムはファイルを保持するだけではない。それはアイデンティティインフラとやり取りする人々のマップを保持する。攻撃者がそれを重視するため、そのマップは保護されるべきである。

最終的な教訓は、アイデンティティ境界は権限に従い、ブランディングには従わないということである。トラブルシューティングファイルがセッションになり得る場合、サポートアカウントがそのファイルを閲覧できる場合、サードパーティのケースシステムがそれを保存できる場合、そしてアクセス後に顧客がローテーションしなければならない場合、サポートはアイデンティティ管理面の一部である。修復記録は、顧客が次のサポートリクエストを信頼できるように十分に可視化しなければならない。

影響報告は弁護士にとって完全であるだけでなく、防御者にとって有用であるべきである

OKTA の2024年2月の調査終了ノートは、顧客とパートナー向けのカスタマイズされた影響報告に言及した。その種の報告は、防御者が行動するのに役立つ場合にのみ価値がある。顧客が影響を受けたと述べる法的通知は正式に重要かもしれないが、セキュリティチームは運用上の詳細を必要とする。どのケース、どのファイル、どの成果物、どのサポートユーザー、どのアクセス時間、どの可能性のあるセッション、どの推奨ローテーション、どの指標をテナントログで確認すべきか。

1Password、BeyondTrust、Cloudflareからの顧客報告は、防御者が再構築しなければならなかった具体性のレベルを示している。彼らは OKTA サポートチケットを予期しない管理アクティビティ、HAR ファイル、セッショントークン、管理デバイス強制、API 試行、または封じ込め手順に関連付ける必要があった。プロバイダーの影響報告が正確であればあるほど、各顧客がプレッシャーの下で推測しなければならないことは少なくなる。

アイデンティティプロバイダーの影響報告は少なくとも5つのカテゴリを分離すべきである。第一に、ファイル露出：どの顧客がアップロードした成果物がアクセスまたはダウンロードされたか。第二に、セッションリスク：それらの成果物にライブクッキーやトークンが含まれていた可能性があるか。第三に、連絡先リスト露出：サポートユーザーの名前やメールがより広範な報告に表示されたか。第四に、観測されたテナントアクティビティ：プロバイダーまたは顧客の証拠がセッション再生、管理アクション、または試行されたピボットを示しているか。第五に、推奨される顧客アクション：どのセッション、認証情報、サポート連絡先、またはログを確認する必要があるか。

これらのカテゴリは混同されるべきではない。連絡先名が報告に表示された顧客はフィッシングリスクに直面する。HAR ファイルが閲覧された顧客はセッションリスクの可能性に直面する。セッション再生の証拠がある顧客はインシデント対応の緊急性に直面する。3つすべてが当てはまる顧客は、サポートユーザーの連絡先露出のみの顧客とは異なる対応を必要とする。精度は過小反応と不必要な混乱の両方を減らす。

報告はまた、可能な限り機械で使用可能であるべきである。セキュリティチームは、指標、外部セッション ID、ユーザー識別子、ケース番号、ファイルハッシュ、IP アドレス、タイムスタンプが検索可能な構造化形式で到着すれば、より迅速に行動できる。手動の PDF は通知の期待を満たすかもしれないが、ログを照会する必要がある防御者を遅らせる。サポートインシデントは、顧客側の対応がプロバイダー側の証拠パッケージに依存することを示した。

サポート成果物の処理は不完全な顧客向けに設計されるべきである

警告は必要だが十分ではない。OKTA のHAR ファイルの生成に関するドキュメントは、ファイルを送信する前に機密データや個人識別情報を削除するようユーザーに警告している。ブラウザのネットワークリクエストの HAR への保存に関するドキュメントは現在のエクスポート動作を説明している。これらは有用な管理だが、実際の顧客は時間的プレッシャーの下で、トラブルシューティング中に、しばしばサービスを復元しようとする管理者によってファイルをアップロードする。完全な手動編集に依存するサポートセキュリティモデルは、最終的に失敗するだろう。

サポートシステムは機密成果物がアップロードされると想定すべきである。その想定は設計を変える。アップロードページは警告し、スキャンできる。ファイルストアはアクセスを制限し、保持を短縮できる。ケースツールはデフォルトで機密フィールドを含む広範なレポートエクスポートを防止できる。サポートワークフローはセッション資料を含むように見えるファイルをダウンロードする前に昇格された承認を要求できる。顧客ポータルは特定のアップロードタイプ後に自動セッション失効を推奨できる。プロバイダーはサニタイズされた収集をオプションの追加ではなくデフォルトの経路にできる。

顧客も不完全さを前提に設計すべきである。セキュリティチームは限定された権限を持つトラブルシューティング用アイデンティティを作成し、ライブ管理者セッションではなくテストフローから HAR ファイルをキャプチャし、アップロード後にセッションを取り消し、機密成果物を含むサポートケースにタグを付けることができる。どの認証情報やトークンがサポートファイルに表示された可能性があるかを従業員に記録させることを要求できる。インシデント対応中にサポートケースの添付ファイルをレビューできる。これらのステップはプロバイダーの義務を排除しないが、偶発的な露出の価値を減らす。

Cloudflare のHAR Sanitizerは、ファイルがベンダーに届く前に安全な共有を容易にする方向性を示している。ツール自体は万能な答えではなく、一部のトラブルシューティングでは編集が削除するデータが必要になる場合がある。より広範な原則が重要である。サポート成果物の処理は、管理者の記憶テストではなく、安全なデフォルトを持つ設計されたワークフローであるべきである。

アイデンティティプロバイダーのサポートワークフローが不完全な顧客向けに設計されていれば、インシデントが連鎖する可能性は低くなる。顧客はサポートチケットをテナントアクセス経路に変えることなく間違いを犯すことができる。プロバイダーは必要な診断データを受け取りながら、必要以上に長くライブ権限を保持しないようにできる。それが比例したサポートセキュリティのあるべき姿である。

サポートマップはソーシャルエンジニアリングの資産である

OKTA が更新と推奨アクションで説明した11月のレポート露出は、マップとして理解されるべきである。サポートシステムユーザーの名前とメールアドレスは、アイデンティティインフラとやり取りし、サポートケースを開き、特権知識を持つ可能性がある人々を特定する。FINRA のサイバーセキュリティアラートは、露出したサポートデータに関連するフィッシングやソーシャルエンジニアリング攻撃の可能性について加盟企業に警告した。このリスクは抽象的に理論的ではない。それは役割情報自体から生じる。

サポートマップは公開された侵害ニュースと組み合わせることができる。攻撃者は OKTA サポート問題、テナントレビュー、セッションローテーション、セキュリティ検証リクエストに言及するもっともらしいメッセージを作成できる。受信者はまさにそのような通信を期待する人である可能性がある。これが悪用連絡先の経済性問題である。低コンテンツの記録でも、適切なターゲットを適切なタイミングで特定すれば強力になり得る。

管理対応にはコミュニケーションハイジーンを含めるべきである。プロバイダーは検証済みチャネル、必要に応じて署名付き勧告、明確な送信者ドメイン、サポートが特定の認証情報を決して要求しない方法についてのガイダンスを顧客に提供すべきである。顧客はサポートおよび管理者の人口にインシデントをテーマにしたメッセージが届く可能性があることを警告すべきである。ヘルプデスクはベンダーリクエストを検証する方法を指示されるべきである。セキュリティチームは、サポート連絡先露出後に類似ドメインや標的型認証情報収集を監視すべきである。

この修復層は、セッショントークンよりも技術的でないため、しばしば注目されにくい。それでも重要である。侵害されたセッションは即座のアクセスを生み出す可能性がある。サポートマップは次の侵入試行の種をまく可能性がある。最良のインシデント対応は、両方を同じ信頼境界の一部として扱う。攻撃者が誰に電話するかフィッシングするかを知っている場合、サポートセキュリティは完全に回復していない。

ベンダーリスクレビューはサポートプレーンをテストすべきである

エンタープライズのベンダーリスクレビューはしばしば製品管理に焦点を当てる。稼働時間、暗号化、MFA、データ処理、認証、インシデント対応。OKTA のインシデントは、アイデンティティプロバイダーのレビューはサポートプレーンを明示的にテストすべきであることを示唆している。サポートケースはどこでホストされているか？誰が添付ファイルにアクセスできるか？ファイルはどのくらい保持されるか？レポートはエクスポート可能か？サービスアカウントはフィッシング耐性 MFA で保護されているか？従業員の個人ブラウザプロファイルは禁止されているか？顧客はインシデント中にファイルレベルのアクセスログを取得できるか？サポート成果物はスキャンまたはサニタイズされているか？

OKTA のForm 10-Kはサードパーティのサポートシステムホスティングとプロバイダーリスクの文脈について議論した。顧客はその一般的なリスクを具体的なデューデリジェンスに変えるべきである。サードパーティのケースシステムは、その管理がそれが保存する成果物の機密性に一致するかどうかを顧客が尋ねるために公開される必要はない。アイデンティティプロバイダーにとって、サポートプレーンの保証は製品プレーンの保証と同じくらい日常的であるべきである。

レビューはまた、プロバイダーがどのように顧客に通知するかを尋ねるべきである。影響を受ける顧客は直接連絡を受けるか？テナント固有の指標を受け取るか？プロバイダーはアップロードされたファイルにセッション資料が含まれていた可能性があるかどうかを特定するか？顧客は公の詳細がフィッシングリスクを生み出す前にローテーションする十分な時間を得るか？広範な連絡先リスト露出は成果物露出から分離されるか？これらはインシデント準備の質問であり、法的通知の質問だけではない。

顧客にとって、レビューは内部のコミットメントも生み出すべきである。プロバイダーが HAR ファイルが機密である可能性があると言う場合、顧客は誰がそれらをアップロードできるかを定義すべきである。プロバイダーがアップロード後にセッションを取り消すべきと言う場合、顧客はそのステップを自動化すべきである。プロバイダーがサポートユーザーリストがフィッシングリスクを生み出す可能性があると言う場合、顧客はインシデント後に標的型認識を必要とする管理者およびサポートロールのリストを維持すべきである。

結果はサポートプレーンのプレイブックであるべきである。それは管理者に診断データを安全に収集する方法、提出方法、その後何をローテーションするか、ベンダー通信を検証する方法、プロバイダーがサポートシステムアクセスを報告した場合にログを検索する方法を指示すべきである。そのプレイブックがなければ、すべてのサポートインシデントは即興から始まる。

顧客は次のサポートインシデントの前にリハーサルを必要とする

OKTA インシデントはまた、顧客がプロバイダーの通知が届く前にサポート成果物対応をリハーサルする必要があることを示している。セキュリティチームは簡単な質問に迅速に答えられるべきである。どの従業員がアイデンティティプロバイダーにサポートケースを開くか？どのアカウントが診断ファイルをアップロードする権限を持っているか？それらのファイルのコピーは内部のどこに保存されているか？アップロード後に誰がセッションを取り消すことができるか？どのログが外部セッション ID の使用を示すことができるか？トラブルシューティングに関連するサービスアカウント認証情報をローテーションするかどうかを誰が決定するか？

OKTA のシステムログイベントに関するガイダンスは顧客に検索概念を提供するが、概念は対応計画ではない。顧客はチームが関連イベントを見つけ、解釈し、サポートケースに関連付けることができるかをテストすべきである。サポート管理者がサニタイズされた証拠を作成する方法を知っているかをテストすべきである。特権セッションが必要なビジネスアクセスを無効にせずに迅速に取り消すことができるかをテストすべきである。

リハーサルはまた、公開ニュースへの依存を減らす。2023年には、一部の顧客報告はプロバイダーの公開説明が完了する前に疑わしいアクティビティを発見またはエスカレーションしたと説明した。それはクラウドインシデントでは珍しくない。顧客は完全なプロバイダー説明を受ける前にテナントの症状を見る可能性がある。リハーサルされたプレイブックは、プロバイダーに精度を求めながらも、独自の証拠に基づいて行動するのに役立つ。

演習にはコミュニケーションを含めるべきである。サポート成果物が管理者セッションを露出した可能性がある場合、誰がアプリケーションオーナーに伝えるか？誰がヘルプデスクにフィッシングについて警告するか？誰が経営幹部に通知するか？誰がエンドユーザーが影響を受けるかどうかを判断するか？サポートシステム侵害は狭く見えるかもしれないが、対応はアイデンティティ運用、法務、コミュニケーション、ベンダーリスク、ビジネスオーナーに及ぶ。その引き継ぎを練習することは、サポートを統治された信頼境界にする一部である。

実用的な基準は控えめだが要求が厳しい。HAR ファイル、セッションクッキー、サポートユーザー、テナントログがどのように接続されるかをアクティブなプロバイダーインシデント中に初めて学ぶ顧客があってはならない。アイデンティティサポートは企業権限に近すぎる。

リハーサル記録はベンダーリスク資料とともに保管され、次のサポートインシデントが指名されたオーナーとテスト済みアクションで開始されるようにするべきである。