🛡️

Google SecOps:SOAR のケース管理でインシデント対応を効率化!

2024/12/10に公開

はじめに

こんにちは、クラウドエースの小田です。

Google Security Operations(以下、Google SecOps)における SIEM については、過去記事でご紹介したようにさまざまなソースからセキュリティイベントログを収集・分析し、脅威の兆候を検知する役割を担います。
しかし、SIEM だけでは、検知された脅威への対応が手動で行われるケースが多く、迅速な対応が難しいという課題がありました。

そこで注目されているのが、SIEM とシームレスに連携する SOAR を用いて脅威への対応を自動化し、人手に頼っていた作業を効率化するという解決策があります。

Google SecOps では、SIEM の機能に加え、SOAR を活用したケース管理やインシデント対応といった便利な機能があります。
今回は Google SecOps における SOAR のケース管理でのインシデント対応について説明します。
google-secops-components
【図】: SIEM と SOAR の概要

Google SecOps の機能の概要については別の記事でご紹介してるので、そちらをご覧ください。
https://zenn.dev/cloud_ace/articles/google-secops-overview

SOAR のケース起票について

Google SecOps の SOAR では SIEM で発報されたアラートを自動的に1つのケースとしてまとめ、優先順位付け、担当者の割り当て、エスカレーションを実施するためのケース管理機能があります。
アラートの作成方法については以下の公式ドキュメントを参照ください。
https://cloud.google.com/chronicle/docs/detection/yara-l-2-0-overview?hl=ja

関連したアラートが複数発報されると自動的に1つのケースとしてまとめられて起票されます。
google-secops-case-alert-summary
【画像】: ケース内に含まれる複数のアラート

ケースは手動でも作成できます。
手動でのケースの作成方法については以下の公式ドキュメントを参照ください。
https://cloud.google.com/chronicle/docs/soar/investigate/working-with-alerts/whats-on-the-alert-overview-tab

ケース内のアラートグループ化メカニズム

Google SecOps の SOAR では、同一の脅威に関連する複数のアラートを効果的に管理するための「アラートグループ化メカニズム」を提供しています。
この仕組みにより、類似した特徴を持つアラートを自動的にまとめられ、アナリストが同じインシデント調査に時間を費やすことを防ぎます。

アラートがグループ化される条件には以下のような基準があります

  1. エンティティの一致: アラートに関連するエンティティが同一である場合
    • 例: ユーザー アカウント、IP アドレス
  2. 時間軸の一致: アラートの発生時刻が一定期間内に集中している場合
  3. ルールの類似性: アラートが同じ、または類似した検知ルールに基づいて生成されている場合

例えば、同じユーザー アカウントで短期間に複数の失敗したログイン試行が発生し、異なる複数のアラートルールで検知された場合、これらのアラートは1つのグループとしてまとめられます。

アラートグループ化の設定

SOAR Settings > Advanced > Alerts Grouping > General にて、ケースとしてまとめるアラートの最大数や時間枠を設定できます。

また、SOAR Settings > Advanced > Alerts Grouping > Rules では、独自のグループ化ルールや除外ルールを定義できます。
ルールは階層的に、アラート タイプ > 製品 > データ ソースの順で適用され、一致するルールがない場合は、フォールバック ルールが適用されます。
google-secops-alert-grouping
【画像】: アラートのグループ化設定

詳細な設定方法については、公式ドキュメントをご参照ください。
https://cloud.google.com/chronicle/docs/soar/investigate/working-with-alerts/alert-grouping-mechanism-admin

外部サービスからのアラート連携

Google SecOps SIEM 側のアラートだけでなく、Marketplace で提供されている Integrations Package をインストールすることで、外部サービスのアラートを連携し SOAR 内でケースとして一元管理できます。

AWS の Security Hub や CloudTrail、Microsoft の Defender など、さまざまなサービスからのアラートを連携できます。
google-secops-marketplace
【画像】: Google SecOps 内の Marketplace

インストールできる Integrations Package の一覧は以下の公式ドキュメントをご参照ください。
https://cloud.google.com/chronicle/docs/soar/marketplace-integrations

Integrations Package のインストール後、SOAR Settings > Integration > Connectors で連携先サービスの認証情報などを設定することで、外部サービスのアラートを連携できます。
google-secops-integration-connector
【画像】: インテグレーションのコネクタ設定 (AWS Security Hub)

取り込んだ外部サービスのアラートはケース内で確認でき、他のケースと同様に Gemini によるケース内容の要約や、ネクストアクションの提案を利用することができます。
google-secops-integration-aws-alert
【画像】: AWS Security Hub から取り込んだアラート

ケースが起票された後のインシデント対応の流れ

JPCERT が公開しているインシデントハンドリングマニュアルをもとに、ケースが起票された後のインシデント対応を以下のとおりに説明します。
https://www.jpcert.or.jp/csirt_material/files/manual_ver1.0_20211130.pdf

  1. ケースのトリアージ
    アラートが発報され、ケースが起票されます。
    自動的に割り当てられた担当者は、ケース内のアラートやエンティティなどの関連情報を分析し、誤検知か、対応の優先度、次のステップを判断します。
  2. インシデントの対応
    トリアージの結果対応すべき事象と判断した場合、SIEM Search などを用いインシデントの調査や被害の封じ込めを行います。
    必要に応じて、ケースを上級アナリストや専門チームにエスカレーションします。
    対応の進捗や結果はケース内で記録され、関係者がリアルタイムで状況を把握できます。
  3. クローズと報告
    対応完了後、対応内容の振り返りや報告書を作成しケースをクローズします。

担当者割り当て

トリアージやエスカレーションのタイミングなどで担当者を変更したい場合、ケース内でアナリスト名またはロール部分をクリックして任意のアナリストにアサインすることができます。
google-secops-case-analyst-assign
【画像】: ケースの担当者割り当て

新しいケースの作成された際は、SOAR Settings > Organization > Roles でデフォルトとして設定したロールにケースが自動的にアサインされます。
google-secops-case-default-role
【画像】: デフォルトでケースにアサインするロールの設定

ケース内のチャット機能

インシデントの対応時などに、ケース内でチームメンバーやアナリスト間でチャットを行える機能です。
特定のユーザーや SecOps 内のロールを持つ人に対してメンションすることや、必要に応じて調査に利用するファイルなどを添付して送信することが可能です。
google-secops-case-chat
【画像】: ケース内のチャット機能

コメント機能

ケースの下部からコメントを残し、ケースに関する情報を共有したり、対応状況を記録したりできます。
他のアナリストや関係者と情報を共有するのに役立ちます。
google-secops-case-comment
【画像】: ケース内のコメント機能

ケースアクション

Google SecOps のケースページでは、様々なアクションでケースを管理することができます。
使用できるアクションをご紹介します。

Mark as important (重要としてマーク)

アナリストが特別な注意が必要なケースなどを強調表示したい場合、そのケースを重要としてマークできます。
ケースに黄色の三角形のアイコンが表示され、他のアナリストにも注意喚起できます。
google-secops-case-action-mark-as-important
【画像】: ケースを重要としてマーク

Incident (インシデントとしてマーク)

トリアージの結果、インシデントと判断された場合、アナリストは「インシデント」としてマークできます。
ケースに赤色の回転灯のアイコンが表示され、他のアナリストにも注意喚起できます。

インシデントを発生させると、ケースのステージが「インシデント」に変更され、ケースの優先度が「クリティカル」に設定されます。
さらに、ケースは自動的に SOC マネージャーロールを持つユーザーに割り当てられます。
google-secops-case-action-incident
【画像】: ケースをインシデントとしてマーク

Stage (ステージ)

ケースの進捗状況に合わせて、ステージを変更できます。

  1. Triage(トリアージ): ケースが作成されたときの、デフォルトステージ
  2. Assessment(評価): ケースが次の担当層に割り当てられ、評価するステージ
  3. Investigation(調査): アラートや関連エンティティの詳細な調査を行うステージ
  4. Incident(インシデント): ケースをインシデントとして対応している際のステージ
  5. Improvement(改善): アナリストが対応を終えた後、SOC の改善やさらなる調査を対応のステージ
  6. Research(リサーチ): 外部エンティティがどのように組織内に侵入した経緯などの要因について、調査を行うステージ
    google-secops-case-action-stage
    【画像】: ケースのステージを変更

ステージの定義は組織の SOC 管理手法に基づいて SOAR Settings > Advanced > Case Data > Case Stages から変更することも可能です。
各ステージの定義を明確にすることで、アナリスト間での認識のずれを防ぎ、スムーズなケース管理を実現できます。

Priority (優先度)

ケースの優先度は、ケース内に含まれるアラートの最高の優先度を継承しますが、必要に応じて変更できます。
優先度は、どのケースから対応すべきかを視覚的に判断することができます。
「Informative」「Low」「Medium」「High」「Critical」の5段階で設定でき、それぞれに色が割り当てられています。

上部のバーの左側にある色を直接クリックして、そこから変更することも可能です。
google-secops-case-action-priority
【画像】: ケースの優先度を変更

google-secops-case-chat
【画像】: ケースの優先度を変更しようとすると警告が表示
https://cloud.google.com/chronicle/docs/soar/investigate/working-with-alerts/changing-alert-priority-instead-of-case-priority

Report (レポート)

レポートはケースについての報告書を作成する際に便利な機能です。
SecOps で自動的に作成されたレポートを、.doc、.xlsx、.csv .pdf 形式でダウンロードできます。

レポートには、ケースの詳細、関連するアラートやエンティティ、ケースのステータスやアクティビティ履歴などが記載されています。
google-secops-case-action-report
【画像】: PDF で出力したレポートのサンプル

ケースのクロージング

インシデント対応が完了したら、ケースをクローズします。
クローズ時には、「Reason(理由)」、「Root Cause(根本原因)」、「Comment(コメント)」を記録し、将来のインシデント対応に役立てられます。
google-secops-case-action-close
【画像】: ケースのクロージング

まとめ

SecOps の SOAR を活用することで、SIEM や他の外部サービスで検知されたアラートを効率的に管理し、迅速なインシデント対応を実現できます。
特に、ケース管理機能は、インシデント対応のワークフローを整理し、チーム全体の連携を強化する上で非常に有効です。

クラウドエースでは本製品の取り扱いおよび導入・運用のサポートを実施しておりますので、お困りごとがありましたらお気軽にお問い合わせください。

Discussion