セキュリティ責任者が求める運用上のゴールは共通しています。何か不審な動きが検知されたとき、チームが「何が起きたのか」「その意味は何か」「影響範囲はどこまでか」「次に取るべき対応は何か」を迅速に判断できることです。さらに、その判断は監査やレビューに耐えられる証拠に裏付けられている必要があります。しかし、従来のSIEMプラットフォームは、LLMを追加しただけで、そのようなレベルの判断支援をプレッシャーのかかる状況で提供できるよう設計されているのでしょうか。
これこそが、SIEMの課題の本質です。SIEMのみに依存する多くのSOCワークフローは、依然としてイベントから始まり、最終的には担当者がアイデンティティ、クラウド、SaaS、エンドポイント、コラボレーションプラットフォームにまたがる情報を手作業で関連付けながら、インシデントの全体像を組み立てることになります。そして、この全体像を組み立てる作業こそが、多くのチームを疲弊させる原因となっています。また、影響範囲を確信を持って絞り込めないために対応範囲を過大に設定してしまったり、逆に影響を証明できないために対応範囲を過小に設定してしまったりするのも、この段階です。
SOCが今日のインシデントに対応できるよう構築されているかを評価する実践的な方法の一つは、ツールを切り替えることなく、どのような問いに迅速に答えられるかを確認することです。
#SIEMpossibleチャレンジに参加して、あなたのSIEMが他のセキュリティ実務者と比べてどの位置にあるかを確認しましょう。SOCの強みと、見えにくいギャップがどこでスピードを妨げているかを示す、パーソナライズされたベンチマークレポートをお届けします：exaforce.com/siem-possible
機密データの漏えいが疑われる場合、現在外部と共有されている機密ファイルはどれか、それらを公開したのは誰か、そして何人の外部ユーザーがアクセス権を持っているのかを把握できますか。アイデンティティの侵害が疑われる場合、そのアイデンティティの影響範囲を算出できますか。継承された権限や、そのユーザーがアクセス可能な本番環境のシステムまで含めて把握できるでしょうか。新たな脅威が大きく報じられた際、攻撃者がその脅威を武器化し悪用するまでの時間と同じスピードで、自社環境への潜在的な影響を迅速に評価できますか。アラートが発生した際、その直前に何が変更されたのか、そしてなぜその変更が重要だったのかを確認できますか。
エクサフォースは、こうした答えを大きな手間をかけることなく提供できるよう設計されています。そのため、Forcepoint、Replit、Invisible、Guardant Healthといった企業がエクサフォースを信頼しています。エクサフォースの導入により、お客様は調査時間を短縮し、大規模な誤検知のトリアージを自動化するとともに、重大なインシデントへの対応時間を改善しています。そして何よりも重要なのは、意思決定が最も重要となる場面で、根拠に裏付けられた答えを得られることです。お客様の声を、ケーススタディでぜひご覧ください。
あなたのSIEMは、それができますか？
SOC戦略について、少し違った視点で考えてみましょう。私たちの製品で何ができるかをご説明する代わりに、最近の攻撃キャンペーンの事例を取り上げ、それらの事例から、どのような情報を可視化できることが重要なのかをご紹介します。
1. 共有による機密データの漏えい
2023年9月、Googleは北米のある医療研究機関が所有するREDCapサーバーが侵害されたことを報告しました。脅威アクターは一定期間にわたり検知されることなく、特定の条件に一致したメールを、攻撃者が管理するアカウントへBCCで自動転送する設定を悪用していました。
このようなインシデントは、一つひとつは正当な操作として発生します。しかし、それらが組み合わさることでリスクへと変わります。例えば、共有リンクの設定変更、共同編集者の追加、フォルダへの権限継承、機密情報を含むメールの組織外への転送などです。こうした事象が積み重なることで、最終的には組織がアクセスを制御できない相手から機密データにアクセス可能な状態が生じます。
このような状況では、経営層はSOCに対して、Google Workspaceにおける具体的な露出状況の評価を求めます。現在、どの機密資産が外部からアクセス可能な状態になっているのか。誰がそのアクセスを有効にしたのか。どのような仕組みによるものなのか（公開リンク、外部ゲスト、継承されたグループ権限、共有委任ツールなど）。アクセス権を持つ外部ユーザーは何人いるのか。その範囲は限定的なのか、それとも広範囲に及ぶのか。そして最も重要なのは、その露出が現在も継続しているものなのか、それとも過去のものなのか、という点です。
このシナリオが従来のワークフローでは対応しきれない理由は、「実態」が単一のイベントには表れないためです。その答えはアクセスグラフの中にあります。イベントは何が起きたかを示しますが、現時点でどのようなアクセス関係や権限状態になっているかまでは必ずしも示しません。意思決定を担うリーダーに必要なのは、その「現時点の状態」に関する答えです。なぜなら、それによって影響範囲を限定した対応で済むのか、それとも広範囲に影響を及ぼす対応が必要になるのかが決まるからです。
答えを導き出すことを目的に設計されたプラットフォームであれば、現在の共有状態、その状態に至った経路、そして何がどこまで露出しているのかという範囲を迅速に把握し、封じ込めの判断に役立つ形で提示できる必要があります。
2. アイデンティティ侵害と影響範囲（Blast Radius）
Snowflakeに対するUNC5537による侵害事案のような攻撃は、単一のアイデンティティ侵害や認証情報の悪用が、数百万件規模の顧客レコードの漏えいにつながり得ることを示しています。2024年初頭から中頃にかけて、MandiantがUNC5537として追跡していた脅威アクターは、インフォスティーラーのログから入手した固定的な認証情報を使用し、Snowflakeの顧客テナントへ組織的に認証を試みていました。その結果、約1億1,000万件の顧客レコードに影響を及ぼす情報漏えいが発生し、37万ドルの身代金支払いにつながりました。
答えを起点とするSOCモデルでは、アイデンティティのマッピングと影響範囲（Blast Radius）の把握を中核的なアウトプットとして扱います。SOCは、根拠に基づいて、そのアイデンティティがどのようなアクセス権を持っているのか、実質的に管理者権限を有しているのか、どのリソースにアクセスできるのか、そしてなぜその状況が単なるノイズではなく高リスクなのかを明確に示せなければなりません。その可視性こそが、限定的な封じ込めと迅速な復旧を可能にします。
3. ネイティブ検出のカバレッジ
従来型のSIEMプラットフォームは、GitHubのような重要なデータソースを含むすべての重要データソースに対して包括的な検出カバレッジを提供していないため、多くのSOCチームはこの領域で課題を抱えています。新たな脅威が出現するたびに、チームはこれらのプラットフォーム向けの検出ルールを構築・維持するために、多大な手作業による労力を投じなければなりません。
効果的な検出カバレッジを実現するには、専門的なスキルとドメイン知識が必要であり、多くの場合、需要に対して人材が不足している専任の検出エンジニアが求められます。たとえ組織が適切な人材や体制を整えていたとしても、検出ロジックの維持は継続的な課題です。さらに重要なのは、静的な標準搭載ルールだけでは検出可能な脅威の種類が限定されるため、セキュリティチームが進化し続ける脅威環境に追随することが難しくなる点です。この課題を解決するには、ルールベース検出と異常検知を組み合わせた多層的な検出アプローチが必要です。また、ユーザーによる継続的なメンテナンスを必要としない事前設定済みのベースラインをプラットフォームに組み込むことも重要です。さらに、チームの介入なしに、大量かつ低精度なシグナルを、少量で高精度なアラートへと段階的に昇華できる階層型の仕組みが求められます。
4. アラートを引き起こした「変更」の特定
多くの実際のインシデントには、それを引き起こす設定変更が存在します。しかし、そのような設定変更の情報は、一般的なSIEMプラットフォームとは別のシステムに存在していることが少なくありません。設定変更を調査するには、CSPM（Cloud Security Posture Management）、SSPM（SaaS Security Posture Management）、またはCNAPP（Cloud Native Application Protection Platform）を確認する必要がある場合があります。こうした情報がSOCの運用基盤となるプラットフォームに直接統合されていないと、攻撃チェーン全体を把握するうえで不完全な状況把握しか得られません。
不審なアクティビティを可能にした何らかの変更が存在します。たとえば、ロールが引き受けられた、権限が付与された、トークンが作成された、OAuthアプリが承認された、ポリシーが変更された、インテグレーションが接続された、リポジトリの権限範囲が拡大された、あるいは共有設定が変更された、といったものです。
原因となった変更を継続的に特定できるSOCは、症状ではなく根本原因に対処できるため、より迅速かつ正確に封じ込めを実施できます。一方、それができないSOCは、根本的なアクセス経路が残ったままアラート対応に追われ、貴重な時間を浪費することになります。
このような場面では、「クエリを増やせば解決できる」というアプローチは機能しません。コンテキストが分断され、実行時データと構成データが別々のリポジトリに存在している状況では、クエリを重ねるだけで一貫性のある答えを確実に導き出すことはできません。必要なのは、両方のデータセットと、それらを関連付ける相関分析機能がプラットフォームに組み込まれていることです。そうすることで、調査の早い段階から「何が変更されたのか」というストーリーが自然に明らかになります。
5. AIエージェントと委任された操作
セキュリティリーダーは現在、非人間アイデンティティ（NHI）における新たなリスクとしてAIエージェントを認識する必要があります。これらのNHIは、ユーザーの代理として動作するケースが増えています。実行されるアクティビティは、人間によるもの、自動化によるもの、AIエージェントによるもの、あるいは委任された資格情報によるものなどさまざまです。リーダーは、実際に何が操作を実行したのか、どの権限が使用されたのか、その結果どのリソースやデータに影響が及んだのかを理解する必要があります。
このカテゴリーの事象は、すでにエンジニアリングチームの運用やデータアクセスの中で見られるようになっています。SOCが、人間による操作と代理実行された操作を明確な証跡に基づいて区別できなければ、検知や封じ込めが遅れるだけでなく、後から状況を解釈するしかなくなります。
回答を重視するアプローチでは、「誰が実行したのか」と「誰の代理として実行したのか」を、アナリストの推測ではなく、調査における基本的な分析要素として扱います。
セキュリティリーダーが実際に検証できる、エクサフォースの違い
多くのプラットフォームは、「AI」を表面的な機能として活用しています。しかし、セキュリティリーダーに必要なのは、単なるサマリー表示ではありません。必要なのは、一貫して意思決定に必要な答えとその根拠を提供できる運用モデルです。
エクサフォースのモデルはシンプルです。セキュリティ関連データを相関分析し、すべてのアラートがトリアージ済みかつ証拠を伴った状態で届くようにします。検知、トリアージ、調査、対応はすべて1つのプラットフォームで完結します。その結果、より広範なカバレッジ、より正確な答え、大幅な運用負荷の削減、そして総コストの低減を実現します。
ほとんどのSIEMは、単にログを保存するだけです。相関分析、調査、そして運用体制の整備は、お客様自身、あるいは期待した成果を提供できないMSSPに委ねられています。エクサフォースは、ログ、構成情報、アイデンティティ、リソースを含むすべてのセキュリティデータを継続的に相関分析することで、すべてのアラートをトリアージ済みかつ根拠情報付きの状態で提供します。検知、トリアージ、調査、対応はすべて単一のプラットフォーム上で実行されます。その結果、より広範なカバレッジ、より正確な判断、運用負荷の大幅な削減、そして総保有コストの低減を実現できます。また、お客様自身で運用することも、当社のMDRサービスをご利用いただくことも可能です。
エクサフォースはAgentic SOCプラットフォームであり、多くのお客様にとって主要なSIEMでありMDRでもあります。エクサフォースは、より多くのクエリではなく、証拠に裏付けられた答えを提供することを中心に構築されています。アナリストにシステム間の行き来や手作業によるストーリーの組み立てを求める代わりに、アクティビティ、アイデンティティ、アクセス、変更を結び付け、何が起きたのか、それが何を意味するのか、影響範囲はどこまでか、次に取るべきアクションは何かという、リーダーが最も重視する問いに答えるための調査を構成します。
エクサフォースでSIEMの新たな可能性を体感してください
SIEMの新たな可能性チャレンジは、リーダーにとっての課題です。リーダーは意思決定に責任を負っており、その意思決定には根拠をもって説明できる答えが必要です。そのことは、実務担当者が日々問いかける次のような質問からも明らかです。影響範囲はどこまでか、何が変更されたのか、何が共有されているのか、誰がアクセスできるのか、どの権限が継承されているのか、そして誰（または何）が誰に代わって行動したのか。
エクサフォースは、こうした問いに対する答えが自然に得られることを前提に設計されています。だからこそ私たちは、「クエリではなく答えから始める」と考えています。もしSOCが、時間的制約のある状況でも一貫して証拠に裏付けられた答えを提供できないのであれば、それは人材の問題ではありません。プラットフォームの問題です。
そして、その課題はエクサフォースで解決できます。
