Agentic AI が GuardDuty インシデント対応プレイブックの実行を簡素化する方法
AWS におけるインシデント対応は、多くの場合、プレイブックから始まります。AWS は、GuardDuty によって検出されたアラートにセキュリティチームが対応する際に使用できるリファレンスプレイブックを公開しています。これは、NIST Computer Security Incident Handling Guide（Special Publication 800-61 Revision 2）に基づくステップバイステップのガイドです。これらのプレイブックは、IAM ユーザーの異常な挙動など、一般的な脅威カテゴリを対象として作成されており、アナリストが収集すべき証拠、検証手順、調査内容の文書化を進めるための指針となります。
例えば、IAM Anomalous Behavior プレイブックでは、対応担当者に以下を実施するよう指示しています。
- 影響を受けたリソースを特定する
- 影響の性質を確認する
- 異常な API 呼び出しが成功したかどうかを判断する
- アクターを調査する
- アイデンティティを相関させる
- リソース所有者または管理責任者に連絡する
これらの各ステップは重要ですが、全体として非常に手作業が多いプロセスでもあります。アナリストは、GuardDuty の検出結果、CloudTrail ログ、AWS IAM コンソール、場合によっては Entra ID や Okta などの外部 ID プロバイダーを行き来しながら、全体像を組み立てる必要があります。「証拠の取得、保全、文書化」という最初のステップだけでも、数時間かかることがあります。特に、企業のアイデンティティと AWS セッションがきれいに対応していない複雑な環境では、その傾向が強くなります。
見た目以上に難しい理由
具体例を見てみましょう。GuardDuty が、IAM ロールが通常のパターンとは異なる API 呼び出しに使用されたことを検知したとします。プレイブックでは、検出結果の「Anomalous APIs」セクションを確認し、それらの呼び出しが成功したのか、エラーを返したのかを確認したうえで、実際に誰がそのロールを引き受けたのかを特定するよう指示しています。
つまり、CloudTrail を調査し、セッション ID を相関させ、引き受けられたロールをその起点まで追跡し、さらに IdP で対応するアイデンティティを確認する必要があります。企業で Okta を使用している場合、多くはサインインログを確認し、IP アドレスを比較し、同じユーザーが同じ時間帯に認証していたかどうかを検証する作業が必要になります。これを複数のログやコンソールにまたがって行うと、このプロセスはあらゆるインシデント対応のボトルネックになります。
しかも、これは 1 件の検出にすぎません。理論上、月に 1 回以上発生する可能性がある検出については、レベル 1 アナリストがトリアージと調査に使用できる文書化済みのプレイブックが用意されているべきです。しかし、そのようなプレイブックを作成するには多大なエンジニアリング工数が必要であり、既存のツールで完全に自動化することはほぼ不可能です。各 IaaS または SaaS サービスは、数十件もの繰り返し発生するアラートを生成します。つまり、成熟した組織では、基本的な範囲をカバーするだけでも数百本のプレイブックが必要になります。多くの SOC にとって、その規模と必要工数は単純に対応能力を超えており、一貫性、再現性、調査品質にギャップが残ります。
エクサフォースがエビデンス収集を自動化する方法
アラートが生成されると、エクサフォースのエクサボットエージェントは直ちに構造化された調査を開始し、GuardDuty、CloudTrail、IAM に加え、Okta や Entra ID などの IdP、CrowdStrike や SentinelOne などの EDR ツールといった外部ツールからもデータを収集します。具体的に説明するため、このプロセスを「アイデンティティ相関」「アクター分析」「リソースとアクションの検証」という 3 つの主要フェーズに分けて見ていきます。
AWS と IdP にまたがるアイデンティティ相関
IAM Anomalous Behavior プレイブックで最も難しいステップの 1 つは、AWS プリンシパルを実際のユーザーにひも付けることです。エクサフォースは、GuardDuty の検出結果で報告されたプリンシパル、そのプリンシパルが引き受けたロール、セッションを発生させた起点のアイデンティティを含む完全なセッションツリーを収集することで、この作業を自動化します。CloudTrail のセッション ID と IdP のサインインイベントを相互参照し、ルートセッションが Okta または Entra ID のログインにひも付いているかを検証します。そのうえでエクサフォースは、「この Okta ユーザーが午前 9 時 1 分にログインし、午前 9 時 2 分にこの AWS ロールを引き受け、午前 9 時 3 分にこれらの異常な API 呼び出しを実行した」といった内容を平易な表現で示すアイデンティティチェーンを構築します。
この相関作業は、手作業で行うには非常に時間がかかることで知られています。アナリストは多くの場合、CloudTrail ログを検索し、セッションの詳細を取得し、タイムスタンプを Okta や Entra ID のログと比較する必要があります。エクサフォースはこれを即座に実行し、数時間に及ぶログの突合作業を単一のアイデンティティに集約します。
アクター分析とコンテキスト強化
次に、エクサフォースはセッションの背後にいるアクターを調査します。そのアクティビティが企業の IP アドレスから実行されたのか、想定外の場所から実行されたのかを判断します。また、そのプリンシパルが過去に同じ地域で認証したことがあるかどうかを検証します。さらに、脅威フィードに基づき、送信元 IP のレピュテーションが悪いものと関連付いているかどうかも確認します。エクサフォースはこれらを自動で判断し、GuardDuty の生の「Actor」フィールドをコンテキストインテリジェンスで強化します。
また、同じ時間帯に同じプリンシパルによる他のログインがあったか、同じ IP から他のアイデンティティがアクティブになっていたかも横断的に確認します。通常、これらの問いに答えるには、GuardDuty、CloudTrail、IdP の監査ログを行き来する必要があります。エクサフォースはそれらを構造化された Q&A 結果として統合し、アナリストが何が起きたかだけでなく、その状況が企業全体のアイデンティティアクティビティの文脈で妥当かどうかまで確認できるようにします。
必要に応じて、エクサフォースはユーザーおよびそのマネージャーに連絡し、このプレイブックの「プリンシパルに関連する人物に連絡する」セクションに沿って、アクティビティの妥当性を確認します。
リソースとアクションの検証
エクサフォースは、実際に何が影響を受けたのかを詳しく調査します。GuardDuty の「Anomalous APIs」を影響を受けたリソースにマッピングし、それらの呼び出しが成功したかどうかを検証します。S3 バケットが操作された場合、エクサフォースは、どのキーが変更されたのか、そのプリンシパルが過去にそのバケットへアクセスしたことがあるのか、異常なデータ移動が発生したのかを特定します。EC2 が関与していた場合は、インスタンスへの直近のログインを確認し、それらを同じセッションに相関させます。
エクサフォースは単に「異常な API 呼び出しが発生した」と示すのではなく、監査対応可能なエビデンスパッケージを生成します。
すべてを統合する
エクサボットは、アクター、セッション、リソース、アクションを 1 つのビューに自動的に関連付け、過去のアラートや調査から得た履歴コンテキストで強化します。アナリストが「前回は何が起きたのか」を思い出そうとしたり、古いチケットを手作業で相互参照したりする代わりに、エクサボットはその履歴を現在の分析に直接組み込みます。
そこからエクサフォースは、「誤検知」または「調査が必要」のいずれかの明確な判定を提示します。各結論には、裏付けとなるエビデンスと推奨される次のステップが含まれており、アナリストは生のログの山ではなく、意思決定にすぐ使えるパッケージを受け取ることができます。通常であれば、ログの突合や組織内の知見の確認に数時間かかる作業が数分に短縮されるため、チームは情報の組み立てではなく、対応そのものに集中できます。
さらなる分析と調査
パッケージ化された結果から新たな疑問が生じた場合、アナリストはコマンドセンター内で copilot モードに切り替えることができます。ここでは、自由形式の自然言語で質問でき、エクサボットが設定、CloudTrail、IdP などを横断してクエリし、正確でコンテキストに富んだ回答を提供します。
このインタラクティブモードにより、プレイブックは静的な手順を超えて拡張されます。アナリストは必要に応じて手掛かりを深掘りし、調査の軸を切り替え、仮説を検証できます。エクサフォースは、複数のコンソールや生のログをかき分けて確認する代わりに、これらすべての情報を 1 つのコンソールに集約します。
成功につなげる初動の高速化
プレイブックの Part 1 に戻ると、エクサフォースは最も時間のかかる障壁を取り除きます。ログを手作業で照合する代わりに、エクサフォースは、関連するすべてのイベント、プリンシパルのアイデンティティチェーン、アクターのロケーション分析、リソースへの影響、関連する設定不備や脅威の検出結果を含む、事前構築済みのエビデンスパッケージを提供します。アナリストが得るのは生データだけではありません。統合されたサマリーに加え、そのアラートが誤検知である可能性が高いかどうかの結論まで提示されます。
この例では、証拠収集とアイデンティティ相関に半日かかっていた可能性のある作業が、数分で完了します。SOC は、そのアクティビティが承認されたものかどうかを迅速に検証し、必要に応じて封じ込めと修復へはるかに早く移行できます。
手作業から AI 主導へ
AWS プレイブックは、ベストプラクティスを定義し、対応のための明確なチェックリストを提供する有用なテンプレートです。しかし、アラート量の多い環境では、手作業での実行は持続可能ではありません。月次でさえ再発する検出については、理想的には組織が対応するプレイブックを用意しておくべきです。しかし、IaaS および SaaS 環境全体では、これはすぐに数百本のプレイブックへと膨らみ、開発コストが高く、保守もほぼ不可能になります。必要な工数は、多くの SOC の対応能力を超えています。
エクサフォースはこのギャップを埋めます。脅威の検出結果には、最も関連性の高いプレイブックの質問と回答が自動的に付加されます。これは、本来であれば手作業の相関に数時間を要するエビデンスです。検出、トリアージ、調査に真剣に取り組むあらゆる組織にとって、これは大幅なコスト削減につながります。SOC は、貴重な時間をプレイブックの作成や更新に費やす代わりに、エクサボットに重い作業を任せることで、一貫性と再現性のある調査を運用に組み込むことができます。
これにより、エクサフォースは GuardDuty アラートを、手作業で時間のかかる対応から、高速化された自動プロセスへと変えます。その結果、MTTI と MTTC が短縮され、アナリストの疲労が軽減されます。また、アイデンティティデータやクラウドデータが複数のシステムに分散している場合でも、見逃しがないという確信を高めることができます。
