エージェント AI が GuardDuty インシデント対応プレイブックの実行を簡素化する方法
AWS のインシデント対応は、多くの場合、プレイブックから始まります。AWS は以下を公開しています。 リファレンスプレイブック、に基づくステップバイステップガイド NIST コンピュータセキュリティインシデント処理ガイド （特別刊行物 800-61 リビジョン 2）。セキュリティチームが GuardDuty によって検出されたアラートへの対応に使用できます。これらのプレイブックは、IAM ユーザーの異常行動などの一般的な脅威カテゴリを網羅するように作成されており、アナリストが調査の証拠の収集、検証手順、文書化を行う際の指針となっています。
ザの IAM 異常行動プレイブックたとえば、回答者に次のことを指示します。
- 影響を受けるリソースを特定する
- 影響の性質を確認
- 異常な API 呼び出しが成功したかどうかを判断する
- アクターを調査
- アイデンティティの関連づけ
- リソース所有者または管理者を雇う
これらのステップはどれも重要ですが、まとめると非常に手作業になります。アナリストは、GuardDuty の調査結果、CloudTrail ログ、AWS IAM コンソール、場合によっては Entra ID や Okta などの外部 ID プロバイダーを切り替えて、全体像をまとめる必要があります。「証拠の取得、保存、文書化」の最初のステップには数時間かかることがあります。特に、コーポレートアイデンティティと AWS セッションが適切に連携しない複雑な環境ではそうです。
見た目より難しい理由
具体例を見てみましょう。IAM ロールが通常のパターン以外の API 呼び出しに使用されたことを GuardDuty にフラグ付けしたとしましょう。プレイブックには、調査結果の「異常な API」セクションをチェックして、それらの呼び出しが成功したかエラーが返されたかを確認し、実際に誰がロールを引き受けたかを突き止めるようにと書かれています。つまり、CloudTrail を掘り下げてセッション ID を関連付け、引き受けたロールを元のロールまで追跡し、IdP 内の対応する ID を確認する必要があります。企業で Okta を使用している場合は、多くの場合、ログインログを調べて IP アドレスを比較し、同じユーザーがほぼ同時に認証されたかどうかを確認する必要があります。これをさまざまなログやコンソールにまたがると、このプロセスがすべてのインシデントのボトルネックになります。
そして、それはたった一つの発見です。理論的には、月に2回以上発生すると予想される検出については、レベル1のアナリストがトリアージと調査に使用できるプレイブックを文書化しておく必要があります。しかし、こうしたプレイブックの構築にはかなりのエンジニアリング時間を要し、既存のツールで完全に自動化することはほぼ不可能です。IaaS または SaaS サービスはそれぞれ、何十もの繰り返しアラートを生成します。つまり、成熟した組織では、基本を網羅する何百ものプレイブックが必要になるということです。ほとんどの SOC では、必要な規模と労力が単にキャパシティを上回り、一貫性、再現性、調査の質にギャップが残ります。
Exaforce がエビデンス収集を自動化する方法
アラートが生成されると、ExaforceのExabotエージェントはすぐに構造化された調査を開始し、GuardDuty、CloudTrail、IAMのほか、OktaやEntra IDなどのIDPやCrowdStrikeやSentinelOneなどのEDRツールまでデータを収集します。具体的に説明するために、このプロセスをアイデンティティの関連づけ、アクター分析、リソースとアクションの検証という 3 つのコアフェーズに分けてみましょう。
AWS と IdP 間のアイデンティティの関連づけ
IAM 異常行動プレイブックで最も難しいステップの 1 つは、AWS プリンシパルを実際のユーザーにマッピングし直すことです。Exaforce は、GuardDuty の調査結果で報告されたプリンシパル、引き受けた役割、セッションをトリガーしたオリジン ID など、セッションツリー全体を収集することでこれを自動化します。CloudTrail セッション ID と IdP サインインイベントを相互参照して、ルートセッションが Okta または Entra ID のログインに関連付けられているかどうかを確認します。次にExaforceは、このOktaユーザーが午前9時1分にログインし、午前9時2分にこのAWSロールを引き受け、午前9時3分にこれらの異常なAPI呼び出しをトリガーしたことを平易な英語で示すIDチェーンを構築します。
この相関関係は、手作業で行うには時間がかかることで知られています。多くの場合、アナリストは CloudTrail のログを検索してセッションの詳細を取得し、タイムスタンプを Okta または Entra ID のログと比較する必要があります。Exaforce はこれを瞬時に実行し、何時間にもわたるログステッチングを 1 つの ID にまとめます。
アクター分析とコンテキストエンリッチメント
次に、Exaforce はセッションの背後にいるアクターを調べます。アクティビティが企業の IP アドレスから実行されたのか、予期しない場所から実行されたのかを判断します。校長が以前にこの地域で認証を受けたことがあるかどうかが検証されます。また、脅威フィードに基づいて、ソース IP がレピュテーションの悪さに関連しているかどうかもチェックします。Exaforce はこれらに自動的に回答し、GuardDuty の未処理の「アクター」フィールドをコンテキストインテリジェンスで強化します。
また、同じ時期に同じプリンシパルに対する他のログインがあったかどうか、および同じIPから他のIDがアクティブであったかどうかを横方向に調べます。通常、これらの質問に答えるには、GuardDuty、CloudTrail、IdP の監査ログの間を行き来する必要があります。Exaforce はそれらを構造化された Q&A 結果に統合します。これにより、アナリストは何が起こったのかだけでなく、その状況が企業の ID アクティビティというより広い文脈で理にかなっているかどうかを確認できます。
必要に応じて、Exaforceはユーザーとそのマネージャーに連絡を取り、このプレイブックの「プリンシパルに関係する人に連絡する」セクションに従い、アクティビティを検証します。
リソースとアクションの検証
Exaforceは実際に影響を受けたものを掘り下げます。GuardDuty の「異常な API」を影響を受けたリソースにマッピングし、それらの呼び出しが成功したかどうかを検証します。S3 バケットにアクセスした場合、Exaforce はどのキーが変更されたか、プリンシパルが以前にそのバケットにアクセスしたことがあるかどうか、異常なデータ移動が発生したかどうかを識別します。EC2 が関与している場合、Exaforce はインスタンスへの最近のログインを検索し、それらを同じセッションに関連付けます。
Exaforceは、単に「異常なAPI呼び出しが発生した」とだけ述べるのではなく、監査対応のエビデンスパッケージを作成します。
すべてをまとめて
Exabotsは、アクター、セッション、リソース、アクションを1つのビューに自動的にリンクし、過去のアラートや調査からの履歴情報を表示します。アナリストが「前回何が起こったか」を思い出すのに苦労したり、古いチケットを手動で相互参照したりする代わりに、Exabotsはその履歴を現在の分析に直接織り込みます。
そこから、Exaforceは「誤検知」または「調査が必要」のいずれかを明確に判断します。それぞれの結論には、裏付けとなるエビデンスと推奨される次のステップが含まれ、アナリストは未加工のログの代わりにすぐに意思決定を行えるパッケージを入手できます。通常は何時間もかけてログをつなぎ合わせたり、組織的な知識を得たりしていたものが、数分にまとめられるため、チームは組み立てではなく行動に集中できるようになります。
さらなる分析と調査
パッケージ化された結果から新たな疑問が生じた場合、アナリストはコマンドセンター内でコパイロットモードに切り替えることができます。ここでは、自由形式の自然言語による質問をすることができ、Exabotsは構成、CloudTrail、IdPなどに対してクエリを実行して、正確でコンテキストに富んだ回答を提供します。
このインタラクティブモードでは、プレイブックを静的な手順の枠を超えて拡張できるため、アナリストは必要に応じてリードの調査、調査の方向転移、仮説の検証を行うことができます。Exaforce では、複数のコンソールや未処理のログを調べる代わりに、これらすべての情報を 1 つのコンソールにまとめることができます。
成功への第一歩を早める
プレイブックのパート1に戻ると、Exaforceは最も時間のかかる障壁を取り除きます。Exaforce では、手動でログを照合する代わりに、関連するすべてのイベント、プリンシパル ID チェーン、アクターの位置分析、リソースへの影響、および関連する構成ミスや脅威の発見を含む、事前に構築されたエビデンスパッケージを提供します。アナリストは生データだけでなく、アラートが誤検知である可能性が高いかどうかについての総合的な要約や結論まで得ることができます。
この例では、半日かけて証拠収集とアイデンティティの相関を行っていたものが、数分になります。SOC は、その活動が許可されたかどうかを迅速に検証し、必要であれば、封じ込めと是正にずっと迅速に移行できます。
手動から AI 主導へ
AWS プレイブックは、ベストプラクティスを定義し、対応のための明確なチェックリストを提供するための貴重なテンプレートです。しかし、ボリュームの多い環境では、手動での実行は持続可能ではありません。1 か月でも繰り返される検出については、組織は対応するプレイブックを用意しておくのが理想的です。しかし、IaaS 環境と SaaS 環境全体で、これはすぐに何百ものプレイブックになり、開発にコストがかかり、維持もほぼ不可能です。必要な労力は、ほとんどのSOCの能力を超えています。
エクサフォースはこのギャップを埋めます。脅威の検出結果には、最も関連性の高いプレイブックの質問と回答が自動的に追加されます。そうしなければ、手動で何時間もかけて相関させる必要のあるエビデンスです。これにより、検知、トリアージ、調査に真剣に取り組むあらゆる組織にとって、大幅なコスト削減につながります。SOCは、プレイブックの作成と更新に貴重なサイクルを費やす代わりに、Exabotsが面倒な作業を行うことで、一貫性のある反復可能な調査を実施できます。
これこそが、Exaforce が GuardDuty アラートを手動のスローグから迅速で自動化されたプロセスに変える方法です。その結果、MTTI と MTTC が速くなり、アナリストの疲労が軽減され、ID やクラウドデータが複数のシステムに分散していても、何も見逃さないという保証が強化されます。
