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

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

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

インシデント対応計画に含めることについて検討する必要があるアクティビティのチェックリストについては、インシデント対応計画の記事を参照してください。 インシデント対応計画が策定されたら、最も重大な種類のサイバー攻撃について定期的にテストし、組織が迅速かつ効率的に対応できることを確認します。

組織のインシデント対応プロセスは、組織の構造と機能、および履歴の経験に基づいて異なる場合がありますが、セキュリティ インシデントに対応するためのこの記事の推奨事項とベスト プラクティスのセットを検討してください。

インシデントの間は、次の処理を行う必要があります。

  • 落ち着きを保つ

    インシデントは非常に破壊的であり、感情に影響を受ける可能性があります。 落ち着いて、最初に最も影響を与えるアクションに取り組みを優先することに集中してください。

  • 害を及ぼさない

    データの損失、ビジネスクリティカルな機能の喪失、証拠の喪失を回避する方法で応答が設計され、実行されていることを確認します。 意思決定を避けて、フォレンジック タイムラインを作成し、根本原因を特定し、重要な教訓を学ぶ能力を損なう可能性があります。

  • 法務部門を含む

    調査と復旧の手順を適切に計画できるように、法執行機関が関与するかどうかを決定します。

  • インシデントに関する情報をパブリックに共有する場合は注意してください

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

  • 必要に応じてヘルプを表示する

    高度な攻撃者からの攻撃を調査し、対応する際には、深い専門知識と経験を活用します。

医療病の診断と治療と同様に、重大なインシデントに対するサイバーセキュリティの調査と対応には、次の両方のシステムを防御する必要があります。

  • 非常に重要です (シャットダウンして作業することはできません)。
  • 複合 (通常は 1 人のユーザーの理解を超えています)。

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

  • 速度

    迅速に行動する必要性と、急な意思決定のリスクとのバランスを取ります。

  • 情報の共有

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

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

メモ

ランサムウェアやその他の種類の多段階攻撃に対する組織の準備に関するその他のガイダンスについては、「 復旧計画の準備」を参照してください

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

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

メモ

業界に関するその他のガイダンスについては、 NIST コンピューター セキュリティ インシデント処理ガイドを参照してください。

技術

インシデント対応の技術的な側面については、考慮すべきいくつかの目標を次に示します。

  • 攻撃操作の範囲を特定してみてください。

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

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

    永続的な攻撃者は、将来の攻撃で目的 (データ/システム) に対して頻繁に戻ります。

便利なヒントを次に示します。

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

    多くの敵対者は、ターゲットマルウェアを検出するために、VirusTotal などのサービスのインスタンス数を監視します。

  • 変更を慎重に検討する

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

    アクションを実行しないリスクが実行リスクよりも高い場合に変更が必要な場合は、変更ログにアクションを文書化します。 インシデント対応中に行われた変更は、攻撃者を混乱させることに重点を置き、ビジネスに悪影響を及ぼす可能性があります。 これらの変更は、復旧プロセスの後にロールバックする必要があります。

  • いつまでも調査しない

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

  • 情報を共有する

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

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

    システムに関する深い知識を持つユーザーを調査 (内部スタッフやベンダーなどの外部エンティティなど) に統合することを確認します。これは、セキュリティ全般者だけではありません。

  • 応答機能の低下を予測する

    状況的なストレスのために、通常の容量の 50% で運用しているスタッフの 50% を計画します。

利害関係者と共に管理する主な期待は、ログ ローリングによって攻撃者が追跡をカバーするなど、調査が開始される前に必要なデータが削除された可能性があるため、最初の攻撃を特定できない可能性があるということです。

操作

インシデント対応のセキュリティ操作 (SecOps) の側面については、次の点を考慮する必要があります。

  • フォーカスを維持する

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

  • コーディネーションとロールの明確さを提供する

    危機チームをサポートする業務に対して個別の役割を確立し、技術的、法的、コミュニケーションの各チームが互いに情報を得ていることを確認します。

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

    敵対的なアクションと独自の対応アクションの両方によって、ビジネス運用への影響を常に考慮する必要があります。

便利なヒントを次に示します。

  • 危機管理のために インシデント コマンド システム (ICS) を検討する

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

  • 継続的な毎日の操作はそのまま保持する

    インシデント調査をサポートするために、通常の SecOps が完全に傍受されていないことを確認します。 この作業は引き続き行う必要があります。

  • 無駄な支出を回避する

    多くの重大なインシデントにより、デプロイや使用が決して行われることのない、負荷の高いセキュリティ ツールが購入されます。 調査中にツールをデプロイして使用できない場合は、ツールの操作に必要なスキル セットを使用して追加スタッフの採用とトレーニングを含めることができる場合は、調査が完了するまで取得を延期します。

  • 詳細な専門知識にアクセスする

    重要なプラットフォームに関する深い専門家に質問や問題をエスカレートする機能があることを確認します。 これには、ビジネスクリティカルなシステムやデスクトップやサーバーなどの企業全体のコンポーネントのオペレーティング システムとアプリケーション ベンダーへのアクセスが必要になる場合があります。

  • 情報フローを確立する

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

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

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

技術

インシデントからの復旧の技術的側面については、次の点を考慮する必要があります。

  • 海をゆでるな

    復旧操作を 24 時間以内に実行できるように、応答スコープを制限します。 不測の事態と是正措置を考慮して週末を計画する。

  • 気を散らさないようにする

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

役に立つヒントをいくつか次に示します。

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

    パスワードリセットは、調査に基づいて侵害された既知のアカウントに重点を置く必要があり、管理者またはサービス アカウントである可能性があります。 保証された場合、ユーザー パスワードは段階的かつ制御された方法でのみリセットする必要があります。

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

    ビジネスクリティカルなデータを失うという差し迫った脅威に直面しない限り、侵害されたすべてのリソース (ホストやアカウントなど) を迅速に修復する、または侵害されたリソースを見つけたら修復する統合操作を計画する必要があります。 この時間枠を圧縮すると、攻撃オペレーターが永続性を調整して維持することが困難になります。

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

    復旧中に新しいツールをデプロイして学習する前に、既にデプロイしたツールの機能を調査して使用します。

  • 敵対者をひっくり返さないようにする

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

    Microsoft の Security Operations Center (SOC) は、インシデント対応チームのメンバーの安全な通信とコラボレーションのために、非運用環境のMicrosoft 365 テナントを使用してきました。

操作

インシデントからの復旧の操作の側面については、次の点を考慮する必要があります。

  • 明確な計画と制限付きの範囲を持つ

    技術的なチームと緊密に連携し、スコープが限られた明確な計画を立てます。 計画は敵対的なアクティビティや新しい情報に基づいて変更される場合がありますが、スコープの拡大と追加のタスクの実行を制限するために注意深く取り組む必要があります。

  • プランの所有権を明確に設定する

    復旧操作には、多くのユーザーが一度に多数の異なるタスクを実行する必要があるため、明確な意思決定と決定的な情報が危機チーム間で流れる操作のプロジェクト リーダーを指定します。

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

    コミュニケーション チームと連携して、組織の利害関係者にタイムリーな更新と積極的な期待管理を提供します。

役に立つヒントをいくつか次に示します。

  • 機能と制限を把握する

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

  • 学習した教訓をキャプチャする

    書面による手順がなくても初めてのインシデントであっても、SecOps のロール固有の手引きを構築し、継続的に改善します。

インシデント対応のためのエグゼクティブレベルとボードレベルの通信は、実践または予測されていない場合は困難な場合があります。 進行状況レポートと復旧に対する期待を管理するためのコミュニケーション計画があることを確認します。

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

SecOps とスタッフのインシデント対応プロセスに関するこの一般的なガイダンスを検討してください。

1. 決定し、行動する

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

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

インシデントを所有するアナリストは、攻撃のストーリーと範囲を理解するのに十分なレベルの信頼度を高めるので、クリーンアップ アクションの計画と実行に迅速に移行できます。

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

  • 行く間にクリーンアップする

    攻撃操作の早い段階で検出されるほとんどの一般的なインシデントでは、アナリストはアーティファクトを見つけたらすぐにクリーンアップできます。 これにより敵対者は不利になり、攻撃の次の段階に進むのを防ぎます。

  • ビッグ バンの準備

    このアプローチは、敵対者が既に環境に対する冗長アクセス メカニズムに解決され、確立されているシナリオに適しています。 これは、 Microsoft の検出および対応チーム (DART) によって調査された顧客インシデントでよく見られます。 このアプローチでは、アナリストは攻撃者の存在を完全に発見するまで敵対者を回避する必要があります。これは、驚きが操作を完全に中断するのに役立つ可能性があるためです。

    Microsoft は、部分的な修復が敵対者にヒントを与えることが多いことを学びました。これにより、インシデントに対応して迅速にインシデントを悪化させる機会が得られます。 たとえば、攻撃者は攻撃をさらに広げたり、アクセス方法を変更して検出を回避したり、追跡をカバーしたり、リベンジのためにデータやシステムの損傷や破壊を与える可能性があります。

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

これらは簡単な意思決定ではなく、これらの判断の呼び出しを行う経験に代わるものはありません。 SOC の共同作業環境と文化は、アナリストが互いのエクスペリエンスを活用できるように支援します。

具体的な対応手順は攻撃の性質に依存しますが、アナリストが使用する最も一般的な手順は次のとおりです。

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

    エンドポイントを分離し、ユーザーまたは IT 運用/ヘルプデスクに問い合わせて再インストール手順を開始します。

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

    IT 運用とアプリケーション所有者と連携して、これらのリソースの迅速な修復を調整します。

  • ユーザー アカウント

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

    アナリストは、MFA メソッドの電話番号とデバイス登録を確認して、ユーザーに連絡して乗っ取られないことを確認し、必要に応じてこの情報をリセットすることもできます。

  • サービス アカウント

    サービスやビジネスへの影響のリスクが高いため、アナリストはレコードのサービス アカウント所有者と連携し、必要に応じて IT 運用にフォールバックして、これらのリソースの迅速な修復を調整する必要があります。

  • メール

    攻撃またはフィッシングメールを削除し、ユーザーが削除されたメールを回復できないようにする場合があります。 ヘッダー、コンテンツ、スクリプト、添付ファイルなど、攻撃後の分析を後で検索するには、常に元の電子メールのコピーを保存してください。

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

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

今後のアクションを変更するまで、学習した教訓の恩恵を受けないため、調査から得られた有用な情報を常に SecOps に統合してください。

同じ脅威アクターまたは方法によって過去と将来のインシデントの間の接続を決定し、これらの学習をキャプチャして、将来的に手動作業と分析の遅延を繰り返さないようにします。

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

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

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

  • 不明な脆弱性またはパッチが適用されていない脆弱性。

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

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

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

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

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

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

リソース 説明
2021 Microsoft Digital Defense Report Microsoft のセキュリティ専門家、実践者、および防御者からの学習を含むレポート。
Microsoft Cybersecurity リファレンス アーキテクチャ Microsoft のサイバーセキュリティ機能と、Microsoft 365やMicrosoft Azure、サードパーティのクラウド プラットフォームやアプリなどの Microsoft クラウド プラットフォームとの統合を示す一連のビジュアル アーキテクチャ図。
Minutes matter インフォグラフィック ダウンロード Microsoft の SecOps チームが継続的な攻撃を軽減するためにインシデント対応を行う方法の概要。
Azure クラウド導入フレームワーク セキュリティ操作 セキュリティ運用機能を確立または最新化するリーダーのための戦略的ガイダンス。
セキュリティ操作に関する Microsoft セキュリティのベスト プラクティス SecOps センターを使用して、組織をターゲットとする攻撃者よりも速く移動する方法。
IT アーキテクト モデル用の Microsoft クラウド セキュリティ ID とデバイスへのアクセス、脅威保護、および情報保護のための Microsoft クラウド サービスとプラットフォーム全体のセキュリティ。
Microsoft のセキュリティ ドキュメント Microsoft からの追加のセキュリティ ガイダンス。