侵害された ID インシデント対応 SOP テンプレートを作成する

  • 適用対象: Microsoft Defender XDR

このSOPテンプレートを使用して、漏洩したアイデンティティインシデントのための再利用可能な標準作業手順(SOP)を作成します。 SOP を発行またはアップロードする前に、各プレースホルダーを組織固有の値に置き換えます。

注

このテンプレートは、開始点として意図された一般的な例です。 そのまま使用しないでください。 トリガー、決定ポイント、クエリ、エスカレーション パス、修復手順など、すべてのセクションをカスタマイズして、SOP として発行またはアップロードする前に、組織の環境、ツール、ロール、ポリシーに合わせます。

前提条件

このSOPをカスタマイズまたは公開する前に、以下の前提条件を確認してください:

  • SOP を所有するユーザーと、組織の変更を承認できるユーザーを確認します。
  • アナリストが SigninLogs データや SOP が参照するその他のソースにアクセスできることを確認します。
  • SOP をガイド ブックとしてアップロードする場合は、「 組織のインシデント対応のカスタマイズ」で、サポートされているファイルの種類、サイズ制限、およびアクセス許可の要件を確認します。
  • ガイドブックのテキストに重点を置いたままにしておきます。 テキスト抽出の品質を低下させる可能性があるスクリーンショット、グラフ、複雑な書式設定は避けてください。

SOP メタデータ

SOPの所有者、範囲、データソースを以下のメタデータフィールドに記録してください。

  • 名前：<Compromised identity incident response SOP>
  • バージョン：<v1.0>
  • 所有者：<Security operations team>
  • 適用対象:<location>
  • プライマリ データ ソース:SigninLogs、 <Defender XDR incident data>、 <Identity provider logs>、 <Email telemetry>、および <Endpoint telemetry>

Purpose

侵害されたアイデンティティインシデント対応SOPを活用して、識別情報の侵害を示すインシデントをトリアージ、封じ込め、調査、修復、防止しましょう。 <User>、<Group>、または<Business unit>に影響を与えるインシデント中にアナリストが一貫して対応できるように、スコープ、意思決定ポイント、エスカレーション パスをカスタマイズします。

トリガー (この SOP を呼び出すタイミング)

インシデント、アラート、ユーザー報告でアイデンティティが侵害される可能性が示唆された場合、侵害されたアイデンティティインシデント対応SOPを発動してください。

  • アラートの例としては、 Impossible travel、 Unfamiliar sign-in properties、 Password spray、 MFA fatigue、 Suspicious inbox forwarding rulesなどがあります。
  • <User>が予期しないMFAプロンプト、不審なサインイン通知、または自分が行っていないアカウント変更を報告した場合、侵害されたアイデンティティインシデント対応のSOPを活用してください。
  • アナリストが異常な場所、リスクの高いIPアドレス、または見慣れないアプリケーションからの成功したサインインを観察した場合、漏洩したアイデンティティインシデント対応のSOPを発動してください。

トリアージ フェーズ

まず、サインイン アクティビティが想定されているか疑わしいかを確認するクイック チェックから始めます。

サインイン アクティビティを検証する

影響を受ける ID の最近のサインイン イベントを確認します。 クエリを実行する前に、ユーザー フィルターを置き換えます。

SigninLogs
| where UserPrincipalName =~ "<user@company.com>"
| where TimeGenerated > ago(48h)
| project TimeGenerated, IPAddress, Location, AppDisplayName, AuthenticationRequirement, ConditionalAccessStatus, ClientAppUsed
  1. サインイン時間、IP アドレス、場所、アプリケーションをインシデントタイムラインと比較します。
  2. ユーザーまたはマネージャーが説明できない成功したサインインを強調表示します。
  3. 最初の疑わしいイベント、最新の疑わしいイベント、関連するアカウントまたはアプリを記録します。

資格情報侵害インジケーターを確認する

概要ビューを使用して、繰り返し失敗した後にアクセスが成功したパターンがアカウントに表示されるかどうかを確認します。

SigninLogs
| where UserPrincipalName =~ "<user@company.com>"
| where TimeGenerated >= ago(7d)
| summarize
    Failures = countif(ResultType != 0),
    Successes = countif(ResultType == 0)
    by IPAddress, bin(TimeGenerated, 1h)
  1. 失敗したサインインが連続して発生し、その後に 1 回以上サインインが成功しているパターンを探します。
  2. 同じ IP アドレス、場所、またはアプリケーションが複数のタイム バケットに表示されるかどうかに注意してください。
  3. パターンがパスワード スプレー、資格情報の詰め込み、トークンの盗難、またはその他の疑わしい手法と一致しているかどうかを記録します。

ユーザーによる検証

次の行動を決める前に、影響を受けたユーザーに直接不審な活動を確認しましょう。

  1. 承認されたチャネルを通じて <User> にお問い合わせください。
  2. サインイン、場所、デバイス、アプリケーション、MFA プロンプトを認識するかどうかを確認します。
  3. 最近 MFA 要求を承認したか、プロンプトに資格情報を入力したか、デバイスを共有したか、移動したかを確認します。
  4. インシデント レコードでユーザーの応答をキャプチャします。

封じ込めフェーズ

完全な調査を完了する前にリスクを含めますが、最初に組織固有の承認ロジックを適用します。

ID を検証する

  1. その ID がサービス プリンシパルまたはその他の非人間アイデンティティ (NHI) であるかどうかを確認します。 その場合は、シークレットのローテーション、アクセスの取り消し、または ID の無効化を行う前に、直接アカウント無効化アクションを一時停止し、 <Service owner> に通知します。
  2. ID が緊急アクセス用アカウントかどうかを確認します。 その場合は、アクションを実行する前に <Identity team lead> と <Incident commander> に通知し、明示的な承認なしにアカウントを無効にしないでください。
  3. 影響を受けるユーザーが、上級リーダーシップ、エグゼクティブ アシスタント、または別の高感度プロファイルであるかどうかを確認します。 その場合は、ユーザーに連絡したり中断を伴う対応を取ったりする前に、<Incident commander> と <Communications lead> に通知してください。

識別情報を含む

以下の措置を用いて、証拠を保存し、ビジネスの混乱を最小限に抑えつつ、漏洩した身元を封じ込めましょう。

  1. <user@company.com>のアクティブなセッションと更新トークンを取り消します。
  2. ID の種類に基づいて、パスワード のリセットまたはシークレットのローテーションを強制します。
  3. リスクがアクティブなままで、ビジネス承認で許可されている場合は、アカウントを一時的に無効にします。
  4. ツールでこれらのアクションがサポートされている場合は、既知の悪意のある IP アドレス、デバイス、アプリケーション、またはトークンをブロックします。
  5. インシデント ID、アラート、サインインのスクリーンショットまたはエクスポート、ユーザー ステートメントなど、証拠を保持します。

調査フェーズ

調査フェーズを使って、可能性のある侵入点を特定し、制御ギャップを確認し、爆発半径を定義します。

根本原因分析を使用する

成功したサインインを使用して、攻撃者がアクセス権を取得した場所と、使用したアプリケーション パスを特定します。

SigninLogs
| where UserPrincipalName =~ "<user@company.com>"
| where ResultType == 0
| order by TimeGenerated asc
| take 10
  1. 悪意があると思われる、最初に確認された正常なサインインを特定します。
  2. そのサインインを、アラート時間、ユーザーの証、フィッシングまたはパスワード スプレーインジケーターと比較します。
  3. フィッシング、パスワードの再利用、敵対者の中間アクティビティ、トークンの盗難、MFA の疲労など、疑わしい根本原因を文書化します。

MFA を評価する

認証管理が失敗したか回避されたかを確認するために、MFAの状態と挙動を確認しましょう。

  1. インシデント発生時に MFA が <user@company.com> に対して有効にされたかどうかを確認します。
  2. 攻撃者が MFA を満たすか、MFA をバイパスしたか、新しい認証方法を登録したかを確認します。
  3. 条件付きアクセス、認証の強度、トークン保護、または登録コントロールのギャップを特定します。
  4. MFA メソッドをリセットする必要があるか、最近の MFA の変更を確認する必要があるかを記録します。

爆発半径と衝撃を分析する

調査を終了する前に、アクセスの範囲と潜在的なビジネスへの影響を評価してください。

  1. 電子メール、ファイル、コラボレーション ツール、クラウド リソース、または特権ロールにアクセスするためのインシデントの証拠を確認します。
  2. 疑わしい受信トレイ ルール、転送ルール、同意付与、メールボックスアクセス、横移動、または権限昇格がないか確認します。
  3. 侵害された ID がアクセスした関連アカウント、デバイス、アプリケーション、ワークロードを特定します。
  4. ビジネスへの影響、データ公開、規制または法的報告の要件を見積もる。

修復フェーズ

攻撃者の永続化を削除し、ID を信頼された状態に戻すアクションを完了します。

修復と回復

  1. パスワードをリセットし、シークレットをローテーションし、すべてのアクティブなセッションに対して新しいサインインを要求します。
  2. 悪意のある受信トレイ ルール、転送ルール、OAuth アプリの同意、または承認されていない認証方法を削除します。
  3. 承認された MFA 設定を復元し、必要に応じて認証方法を再登録します。
  4. エンドポイントの侵害が疑われる場合は、影響を受けるデバイスをスキャンまたは再イメージ化します。
  5. ロールの割り当て、グループ メンバーシップ、アプリケーションのアクセス許可を確認し、承認されていないアクセスを削除します。
  6. 完了したアクション、所有者、タイムスタンプ、証拠を使用してインシデント レコードを更新します。

防止フェーズ

インシデントの教訓を使用して、繰り返しの可能性を減らします。

再発を防ぐ

  1. フィッシングに強い MFA、強力な条件付きアクセス ポリシー、サインイン リスク制御を可能な場合に適用します。
  2. レガシ認証を無効にし、未使用のサービス アカウント、アプリケーション、または資格情報を削除します。
  3. 通常とは異なるサインイン、MFA の不正使用、トークンの不正使用、あり得ない移動、同意アクティビティの検出を改善します。
  4. フィッシングやパスワードの再利用がインシデントに寄与した場合に、 <User>、 <Team>、または <Business unit> に、対象となるユーザー認識ガイダンスを提供します。
  5. インシデントの後にこの SOP を確認し、組織のプレースホルダー、エスカレーション パス、しきい値を更新します。

関連するコンテンツ

  • Last updated on