インシデント対応の概要

インシデント対応とは、組織に対するアクティブな攻撃活動を調査して修復する活動です。 インシデント応答はセキュリティ オペレーション (SecOps) 規範の一部であり、本来リアクティブなものです。

インシデント対応は、セキュリティ オペレーションが組織のリスクをどれだけ軽減できるかを測定する全体的な平均確認時間 (MTTA) と平均修復時間 (MTTR) に最大の直接的な影響を与えます。 インシデント対応チームは、実際にリスクを軽減するために、脅威ハンティング、インテリジェンス、インシデント管理 (存在する場合) のチーム間の良好な協業関係に大きく依存しています。 詳細については、「SecOps のメトリック」をご覧ください。

セキュリティ オペレーションの役割と責任について詳しくは、「クラウド SOC 機能」を参照してください。

インシデント対応プロセス

最初の手順は、サイバーセキュリティ インシデントに対応するための内部プロセスと外部プロセスの両方を含むインシデント対応計画を作成することです。 この計画では、組織が次についてどのようにするかを詳しく説明する必要があります。

• インシデントのビジネス リスクと影響に応じて変化する攻撃に対処します。これは、管理者レベルの資格情報の侵害で使用できなくなった分離された Web サイトとは異なる可能性があります。
• サービスへの復帰や、攻撃の法的または公的な関係の側面を処理する場合など、応答の目的を定義します。
• インシデントとそのタスクに取り組む必要があるユーザーの数の観点から、実行する必要がある作業に優先順位を付けます。

インシデント対応計画に含めて考慮すべきアクティビティのチェックリストについては、インシデント対応計画に関する記事を参照してください。 インシデント対応計画を立てたら、最も重大な種類のサイバー攻撃について定期的にテストして、組織が迅速かつ効率的に対応できるようします。

各組織のインシデント対応プロセスは組織の構造と機能によって異なる場合がありますが、この記事のセキュリティ インシデントに対応するための一連の推奨事項と成功事例を検討してください。

インシデント中は、次のことを行うことが重要です。

• 落ち着く

  インシデントは極めて破壊的であり、感情がかき乱される可能性があります。 冷静になって、最も影響が大きい行動への取り組みを最優先にすることに集中します。

• 損害を与えない

  データの損失、ビジネスに不可欠な機能の損失、証拠の損失を回避するような方法で対応策が設計されており、実行されることを確認します。 フォレンジック タイムラインを作成したり、根本原因を特定したり、重要な教訓を得たりする能力を損なう可能性がある意思決定を回避します。

• 法務部門を関与させる

  調査と復旧の手順を適切に計画できるように、法執行機関の介入が計画されているかどうかを判断します。

• インシデントに関する情報を一般に共有する場合は注意します。

  顧客や一般のユーザーと共有する内容が、法務部門のアドバイスに基づくものであることを確認します。

• 必要に応じて支援を受ける

  巧妙な攻撃者からの攻撃を調査して対応する場合は、深い専門知識と経験を活用します。

医学的疾患を診断して処置する場合と同様に、大規模なインシデントに対するサイバーセキュリティの調査と対応では、次の両方に当てはまるシステムを防御する必要があります。

• 非常に重要 (作業するためにシャットダウンできない)。
• 複雑 (通常、1 人の人間の理解を超えている)。

インシデント中は、これらの重要なバランスを取る必要があります。

• 速度

  利害関係者を満足させるために迅速に行動する必要性と、急いで行われる意思決定におけるリスクのバランスを取ります。

• 情報共有

  責任を制限し、非現実的な期待を設定しないように、法務部門のアドバイスに基づいて、調査担当者、利害関係者、顧客に通知します。

この記事は、回避すべき一般的なエラーを特定し、リスクを軽減して利害関係者のニーズを満たす迅速に実行できる行動に関するガイダンスを提供することによって、組織に対するサイバーセキュリティ インシデントのリスクを軽減するように設計されています。

対応のベスト プラクティス

インシデントへの対応は、これらの推奨事項を使用して、技術と運用の両方の観点から効果的に行うことができます。

技術的な対応の成功事例

インシデント対応の技術的側面については、次のような検討すべき目標があります。

• 攻撃操作の範囲を特定してみます。

  ほとんどの敵対者は、複数の永続化メカニズムを使用します。

• 可能であれば、攻撃の目的を特定する。

  永続的な攻撃者は、将来の攻撃でその目的 (データまたはシステム) を得るために、頻繁に戻ってきます。

有用なヒントを次に示します。

• オンライン スキャナーにファイルをアップロードしない

  多くの敵対者は、対象のマルウェアを検出するために、VirusTotal のようなサービスでインスタンス カウントを監視しています。

• 変更を慎重に検討する

  削除、暗号化、および流出など、ビジネス クリティカルなデータを失うという差し迫った脅威に直面した場合を除き、変更を行わないことによるリスクと、予測されるビジネス上の影響のバランスをとってください。 たとえば、アクティブな攻撃中にビジネス クリティカルな資産を保護するために、組織のインターネット アクセスを一時的にシャットダウンする必要がある場合があります。

  アクションを実行しないリスクがアクションを実行するリスクよりも高い場合に変更が必要な場合は、変更ログにアクションを記録します。 インシデント対応中に行われた変更は、攻撃者を混乱させることに重点を置いており、ビジネスに悪影響を与える可能性があります。 これらの変更は、復旧プロセスの後に元に戻す必要があります。

• 無期限で調査を行わない

  調査作業の優先順位の設定については、容赦なく行う必要があります。 たとえば、フォレンジック分析を行うのは、攻撃者が使用または変更したエンドポイントに対してのみにします。 例えば、攻撃者が管理者特権を持っている大規模なインシデントでは、侵害された可能性があるすべてのリソース (これには、組織の全リソースが含まれる可能性がある) を調査することは事実上不可能です。

• 情報の共有

  法務部門のアドバイスに基づいて、すべての内部チームと外部調査員または保険プロバイダーを含むすべての調査チームが、互いにデータを共有しているのを確認します。

• 適切な専門知識にアクセスする

  セキュリティのゼネラリストだけでなく、社内スタッフや外部エンティティ (たとえば、ベンダー) など、システムに関する深い知識を持つ人々を調査に組み入れていることを確認します。

• 対応能力の低下を見込む

  状況的ストレスによってスタッフの 50% が正常生産能力の 50% で稼働する場合の計画を立てます。

利害関係者について管理すべき重要な期待は、攻撃者がログのローリングによって自分の行動の形跡を隠すなどして、調査が開始される前に、識別に必要なデータが削除されているために、最初の攻撃を特定できない可能性があるということです。

運用対応の成功事例

インシデント対応のセキュリティ オペレーション (SecOps) の側面については、次のような検討すべき目標があります。

• 焦点を絞る

  ビジネスに不可欠なデータ、顧客への影響、修復の準備に焦点を絞っていることを確認します。

• 調整と役割の明確さを提供する

  緊急対策チームをサポートする操作に対して明確な役割を確立し、技術、法務、およびコミュニケーションの各チームが相互に情報を提供し合っていることを確認します。

• ビジネスの観点を維持する

  敵対者のアクションと自身の対応アクションの両方がビジネスの業務に与える影響を常に考慮する必要があります。

有用なヒントを次に示します。

• 危機管理にインシデント コマンド システム (ICS) を使用することを検討する

  セキュリティ インシデントを管理する永続的な組織がない場合は、危機を管理するための一時的な組織構造として ICS を使用することをお勧めします。

• 継続中の日常業務を維持する

  インシデント調査をサポートするために、通常の SecOps を完全に二の次にしないようにします。 この作業は、引き続き実行する必要があります。

• 無駄な支出を避ける

  大規模インシデントが発生すると、プレッシャーがかかり、決してデプロイまたは使用されない高価なセキュリティ ツールを購入することがよくあります。 調査中にツールをデプロイしたり使用したりできない (そのツールを操作するために必要なスキル セットを持つ追加スタッフの雇用やトレーニングも含まれる) 場合は、調査が完了するまで購入を延期してください。

• 高度な専門知識にアクセスする

  重要なプラットフォームに詳しい専門家に質問や問題をエスカレートできることを確認します。 この機能には、オペレーティング システムや、ビジネスに不可欠なシステムおよびエンタープライズ全体で使用されるコンポーネント (デスクトップやサーバーなど) のアプリケーション ベンダーへのアクセスが必要になる場合があります。

• 情報フローを確立する

  上級インシデント対応リーダーと組織関係者の間の情報の流れについて明確なガイダンスと期待を設定します。 詳細については、「インシデント対応の計画」を参照してください。

復旧のベスト プラクティス

インシデントからの復旧は、これらの推奨事項を使用して、技術と運用の両方の観点から効果的に行うことができます。

技術的復旧の成功事例

インシデントからの復旧に関する技術的な側面については、次のような検討すべき目標があります。

• 実現不可能なことをやろうとしない

  24 時間以内に復旧操作を実行できるように、対応範囲を制限します。 週末については、不測の事態や是正措置を考慮して計画を立てます。

• 集中を妨げるものを避ける

  大規模で複雑な新しいセキュリティ システムの実装やマルウェア対策ソリューションの置き換えのような長期的セキュリティ投資は、復旧操作後まで延期します。 現在の復旧操作に直接かつ即時に影響がないものはすべて、注意をそらすものです。

有用なヒントを次に示します。

• 一度にすべてのパスワードをリセットしない

  パスワードのリセットは、調査に基づいて、侵害されたことが分かっており、管理者またはサービス アカウントである可能性があるアカウントにまず焦点を絞る必要があります。 必要な場合、ユーザー パスワードのリセットは、段階的および制御された方法でのみ行う必要があります。

• 復旧タスクの実行を統合する

  ビジネスに不可欠なデータが失われるという切迫した脅威に直面している場合を除き、セキュリティ侵害を受けたリソースを見つけるたびに修復するのではなく、セキュリティ侵害を受けたすべてのリソース (ホストやアカウントなど) を迅速に修復するための統合操作を計画する必要があります。 この時間枠を圧縮すると、攻撃者にとって、適応して永続性を維持することが難しくなります。

• 既存のツールを使用する

  復旧中に新しいツールをデプロイして使い方を学ぼうとする前に、デプロイしているツールの機能を調べて使用してください。

• 敵対者に情報を与えないようにする

  敵対者が利用できる復旧操作に関する情報を制限する対策を講じる必要があります。 大規模なサイバーセキュリティ インシデントでは、敵対者は、通常、すべての運用データとメールにアクセスできます。 しかし、実際には、ほとんどの攻撃者にはすべてのコミュニケーションを監視する時間はありません。

  Microsoft のセキュリティ オペレーション センター (SOC) では、インシデント対応チームのメンバーに対して、セキュリティで保護されたコミュニケーションとコラボレーションを実現するために非運用 Microsoft 365 テナントを使用しています。

運用回復の成功事例

インシデントからの復旧に関する運用上の側面については、次のような検討すべき目標があります。

• 明確な計画を作成し、範囲を制限する

  技術チームと密接に協力して、範囲を制限した明確な計画を作成します。 計画は、敵対者のアクティビティや新しい情報を基に変わる可能性がありますが、範囲の拡大と追加タスクの引き受けを制限するために熱心に取り組む必要があります。

• 計画の所有権を明確にする

  復旧操作では、多くの人が一度に多くの異なるタスクを実行します。そのため、操作のプロジェクト リーダーを指定して、緊急対策チーム内で明確な意思決定が行われ、信頼できる情報が流れるようにします。

• 利害関係者のコミュニケーションを維持する

  コミュニケーション チームと協力して、タイムリーな更新情報とアクティブな期待管理を組織の利害関係者に提供します。

有用なヒントを次に示します。

• 自分の能力と限界を知る

  大規模なセキュリティ インシデントを管理することは非常に困難で複雑であり、業界の多くのプロフェッショナルにとって未知のことです。 チームが圧倒されていたり、次に何を行うべきか自信がない場合は、外部組織やプロフェッショナル サービスの専門知識を取り入れることを検討してください。

• 得られた教訓を取り込む

  文書化された手順がない初めてのインシデントであっても、SecOps に関する役割固有のハンドブックを作成し、継続的に改善します。

練習していない場合や予想していない場合、インシデント対応に関する役員および取締役会レベルのコミュニケーションは困難な可能性があります。 復旧の進行状況レポートと期待を管理するためのコミュニケーション計画を必ず用意しておいてください。

SecOps のためのインシデント対応プロセス

この一般的ガイダンスで、SecOps とスタッフを対象としたインシデント対応プロセスについて検討してください。

1. 決断して行動する

Microsoft Sentinel や Microsoft Defender XDR などの脅威検出ツールは、可能性のある攻撃を検出すると、インシデントを作成します。 SOC 応答性の平均応答時間 (MTTA) の測定は、この攻撃がセキュリティ スタッフによって認識された時刻から始まります。

シフトのアナリストは、委託されているか、インシデントの所有権を取得して、初期分析を実行します。 このタイムスタンプは MTTA 応答性測定の終わりであり、これによって平均修復時間 (MTTR) 測定が開始されます。

インシデントを所有するアナリストは、攻撃のストーリーと範囲が把握できたという十分な信頼水準を得ると、クリーンアップ アクションの計画と実行にすばやく移行できます。

攻撃の性質と範囲に応じて、アナリストは攻撃の成果物 (メール、エンドポイント、ID など) をクリーンアップしたり、侵害されたリソースの一覧を作成して一度にすべてクリーンアップ (ビッグ バンと呼ばれる) したりできます。

• 進みながらクリーンアップする

  攻撃操作の早い段階で検出されるほとんどの一般的なインシデントでは、アナリストは成果物を見つけたらそれらをすぐにクリーンアップできます。 このプラクティスによって敵対者は不利な立場に置かれ、彼らが攻撃の次の段階に進むのを防ぐことができます。

• ビッグ バンに備える

  このアプローチは、敵対者が既に環境に入り込んで冗長なアクセス メカニズムを確立しているシナリオに適しています。 このプラクティスは、Microsofts インシデント対応チームによって調査された顧客インシデントでよく見られます。 このアプローチでは、アナリストは攻撃者の存在を完全に検出するまで敵対者に情報を与えないようにする必要があります。その理由は、サプライズが、彼らの操作を完全に邪魔するのに役立つ可能性があるからです。

  Microsoft では、部分的修復によって敵対者が情報を得る場合が多いことを学習しました。これにより、彼らはそれに対応し、すばやくインシデントを悪化させる機会を得ることができます。 たとえば、攻撃者は攻撃をさらに拡散し、検出を免れるためにアクセス方法を変更し、行動の形跡を隠し、仕返しとしてデータとシステムに損害と破壊を与える可能性があります。

  フィッシングや悪意のあるメールのクリーンアップは、多くの場合、攻撃者に情報を与えずに実行できますが、ホスト マルウェアをクリーンアップしたり、アカウントの制御を取り戻したりすると、検出される可能性が高くなります。

これらは簡単に行える意思決定ではなく、これらの判断においては経験に代わるものはありません。 SOC での共同作業の環境と文化は、アナリストが互いの経験をうまく利用できるようにするのに役立ちます。

具体的な対応手順は攻撃の性質によって異なりますが、アナリストによって使用される最も一般的な手順としては次のものがあります。

• クライアント エンドポイント (デバイス)

  エンドポイントを分離し、ユーザーまたは IT 運用、もしくはヘルプデスクに連絡して再インストール手順を開始します。

• サーバーまたはアプリケーション

  IT 運用およびアプリケーション所有者と協力して、これらのリソースの迅速な修復を手配します。

• ユーザー アカウント

  アカウントを無効にし、侵害されたアカウントのパスワードをリセットすることによって制御を取り戻します。 ユーザーが Windows Hello または別の形式の多要素認証 (MFA) を使用してパスワードレス認証に移行するにつれて、この手順は進化する可能性があります。 別の手順では、Microsoft Defender for Cloud Apps を使用してアカウントのすべての認証トークンを期限切れにします。

  また、アナリストも、ユーザーに連絡して、ハイジャックされていないことを確認するために MFA 方法の電話番号とデバイス登録を調べ、必要に応じてこの情報をリセットできます。

• サービス アカウント

  サービスやビジネスに対する影響のリスクが高いため、アナリストは、必要に応じて IT 運用に頼りつつ、サービス アカウント所有者と協力して、これらのリソースの迅速な修復を手配する必要があります。

• 電子メール

  攻撃またはフィッシングのメールを削除し、場合によっては、削除されたメールがユーザーによって復旧されないように、それらをクリアします。 ヘッダー、コンテンツ、スクリプト、添付ファイルなど、攻撃後の分析を行うための後の検索用に、必ず元のメールのコピーを保存します。

• その他

  アプリケーション トークンの取り消しやサーバーとサービスの再構成など、攻撃の性質に基づいてカスタム アクションを実行できます。

2. インシデント後のクリーンアップ

今後のアクションを変更するまでは、学習した教訓の恩恵を得られないため、調査から得た有用な情報は、必ずセキュリティ オペレーションに取り込みます。

同じ脅威アクターまたは方法による過去と未来のインシデント間の関係を判断し、それらの教訓を取り入れて、将来、手作業と分析遅延が繰り返されないようにします。

これらの教訓は多くの形式を取ることができますが、一般的なプラクティスには次の分析が含まれます。

• 侵害インジケーター (IoC)。

  ファイル ハッシュ、悪意のある IP アドレス、メール属性などの適用される IoC を SOC 脅威インテリジェンス システムに記録します。

• 不明または修正プログラムが適用されていない脆弱性。

  アナリストは、欠落しているセキュリティ パッチの適用、構成ミスの修正、セキュリティ パッチを作成して配布できるようにベンダー (Microsoft を含む) に対する "ゼロデイ" 脆弱性の通知が確実に行われるようにするプロセスを開始できます。

• クラウドベースとオンプレミスのリソースを含む資産のログ記録を有効にするなどの内部アクション。

  既存のセキュリティ ベースラインを確認し、セキュリティ制御の追加または変更を検討します。 たとえば、次のインシデントが発生する前にディレクトリで適切なレベルの監査を有効にする方法については、「Microsoft Entra のセキュリティ オペレーション ガイド」を参照してください。

対応プロセスを確認して、インシデント中に見つかったギャップを特定して解決します。

インシデント対応のリソース

• SOC のの計画
• プレイブック: 一般的な攻撃方法に対応するための詳細なガイダンス
• Microsoft Defender XDR のインシデント対応
• Microsoft Defender for Cloud (Azure)
• Microsoft Sentinel のインシデント応答
• Microsoft インシデント対応チーム ガイドでセキュリティ チームとリーダー向けのベスト プラクティスを共有
• Microsoft インシデント対応ガイドは、セキュリティ チームによる疑わしいアクティビティの分析で役に立つ

主要な Microsoft セキュリティ リソース