どのセキュリティリーダーも、同じ運用上の成果を求めています。何か異常が見つかったとき、チームは「何が起きたのか」「それが何を意味するのか」「影響範囲はどこまでか」「次に何をすべきか」という4つの質問に迅速に答えられること。リーダーはまた、これらの回答が厳密な調査にも耐えうる証拠に裏付けられていることを望んでいます。しかし、LLMラッパーが後付けされた従来のSIEMプラットフォームは、プレッシャーのかかる状況下で、本当にそのレベルの確実性を提供できるように構築されているのでしょうか？
これこそが、SIEMが抱える課題の核心です。 SIEMのみに依存するほとんどのSOCワークフローは、依然としてイベントから始まり、ID、クラウド、SaaS、エンドポイント、コラボレーションプラットフォームにわたる情報を人が手作業で繋ぎ合わせてストーリーを組み立てることで終わります。この繋ぎ合わせの作業こそが、多くのチームを疲弊させる原因です。また、自信を持って範囲を絞り込めないために対応範囲を広げすぎたり、影響を証明できないために対応範囲を狭めすぎたりするのも、この段階で起こります。
今日のインシデントに対応できるSOCが構築されているかを評価する実用的な方法は、ツールを切り替えることなく、迅速に答えられる質問に注目することです。
機密データ漏洩が疑われる場合、今現在、どの機密ファイルが外部に共有されており、誰がそれを公開し、何人の外部ユーザーがアクセスできるかを答えられますか？ID侵害が疑われる場合、継承された権限やその人物がアクセスできる本番システムを含め、そのIDの影響範囲を計算できますか？新しい脅威がニュースになったとき、攻撃者がそれを武器化し悪用するのと同じ時間枠で、自社の環境への潜在的な影響を迅速に判断できますか？アラートが発報されたとき、その直前に何が変更され、その変更がなぜ重要だったのかを確認できますか？
Exaforceは、これらの回答を労力をかけずに提供できるように構築されています。Forcepoint、Replit、Invisible、Guardant Healthといった組織がExaforceを信頼しているのはそのためです。お客様は調査時間を短縮し、大規模な誤検知のトリアージを自動化し、重大なインシデントへの対応時間を改善しました。最も重要なのは、意思決定が最も重要となる場面で、証拠に裏付けられた回答を得られることです。お客様の声は、こちらから直接お聞きください： https://www.exaforce.com/case-studies
あなたのSIEMにそれができますか？
SOC戦略について、別の考え方をご紹介します。私たちが何ができるかを売り込む代わりに、最近の攻撃キャンペーンの例と、それらに基づいて可視性にとってどのような要素が重要かをご紹介します。
1) 共有による機密データ漏洩
2023年9月、 Googleが報告しました 北米の医療研究機関に属するREDCapサーバーが侵害されたことを。脅威アクターはしばらくの間検出されず、一致するメールを脅威アクターが管理するアカウントに密かに「BCC転送」していました。
このようなインシデントは、一連の通常の行動として現れますが、それらが集積するとリスクとなります。例えば、リンク設定が変更されたり、コラボレーターが追加されたり、フォルダーが権限を継承したり、誰かが組織外に機密情報を含むメールを転送したりすると、突然、管理下にない人物が機密データにアクセスできるようになるのです。
このシナリオでは、リーダーはSOCに対し、Google Workspaceにおける具体的な露出評価を求めています。今現在、どの機密アセットが外部からアクセス可能か？誰がそのアクセスを許可したのか？どのようなメカニズム（公開リンク、外部ゲスト、継承されたグループ権限、委任された共有ツール）を通じてか？何人の外部ユーザーがアクセスでき、その範囲は広いのか狭いのか？そして最も重要なのは、その露出は現在進行形なのか、それとも過去のものなのか？
このシナリオが従来のワークフローを破綻させる理由は、「真実」が単一のイベントにはないからです。それはアクセスグラフの中にあります。イベントは「何が起きたか」を教えてくれますが、今現在何が真実であるかを必ずしも教えてくれるわけではありません。リーダーは「今現在」の回答を必要としています。なぜなら、それが対応が的確なものになるか、それとも広範囲に影響を及ぼすものになるかを決定するからです。
回答のために構築されたプラットフォームは、そのアクセスに関するストーリーを迅速に組み立てられるべきです。現在の共有状態、それが作成された経路、そして露出しているものの範囲を、封じ込め決定をサポートする方法で提示できる必要があります。
2) ID侵害と影響範囲
例えば、 Snowflake UNC5537侵害 のような攻撃は、単一のIDと認証の悪用が、いかに数百万件もの顧客記録の漏洩につながるかを示しています。2024年の初頭から半ばにかけて、MandiantがUNC5537として追跡した脅威アクターは、インフォスティーラーのログから入手した静的認証情報を使用して、Snowflakeの顧客テナントに組織的に認証を行いました。これにより、約1億1000万件の顧客記録に影響を与える侵害が発生し、37万ドルの身代金が支払われました。
答えを優先するSOCモデルでは、IDマッピングと影響範囲を最優先の成果物として扱います。SOCは、そのIDがどのようなアクセス権を持っているか、実質的に管理者であるか、何にアクセスできるか、そして何が状況を高リスクにするのか、あるいは単なるノイズなのかを、証拠に基づいて説明できる必要があります。この明確さが、限定的な封じ込めと迅速な復旧を可能にします。
3) ネイティブな検知範囲
ほとんどのSOCチームはここで苦労しています。なぜなら、従来のSIEMプラットフォームでは、Githubのようなすべての重要なデータソースに対して包括的な検知範囲を提供していないためです。新たな脅威が出現するにつれて、チームはこれらのプラットフォームの検知ルールを構築・維持するために、多大な手作業を投入しなければなりません。
効果的な検知範囲を構築するには、専門的なスキルとドメイン知識が必要であり、多くの場合、不足している専門の検知エンジニアが求められます。組織が適切なリソースを確保している場合でも、検知の維持は継続的な課題です。さらに重要なことに、静的な既成ルールでは検知できる脅威の種類が限られており、セキュリティチームが進化する脅威の状況に追いつくことを困難にしています。解決策としては、ユーザーによるメンテナンスを必要としない事前設定されたベースラインを備え、ルールと異常検知を組み合わせた多層的な検知アプローチがプラットフォームに組み込まれている必要があります。これは、チームの介入なしに、大量の低信頼度シグナルを少量の高信頼度アラートに変換できる階層的なソリューションです。
4) アラートの背後にある「変更」
多くの実際のインシデントには、それを可能にする設定変更が伴います。しかし、これらの設定更新は、一般的なSIEMプラットフォームとは異なるシステムに存在します。設定変更を探す場所は、CSPM（Cloud Security Posture Management）、SSPM（SaaS Security Posture Management）、またはCNAPP（Cloud Native Application Protection Platform）かもしれません。これがSOCが運用するプラットフォームに直接統合されていないと、攻撃チェーンの全体像が不完全になります。
不審な活動を可能にした何らかの変更がありました。ロールが引き受けられた、権限が付与された、トークンが作成された、OAuthアプリが承認された、ポリシーが変更された、統合が接続された、リポジトリの権限が拡張された、または共有設定が変更された、などです。
きっかけとなる変更を一貫して見つけられるSOCは、症状ではなく根本的な原因を対象とするため、より迅速かつ正確に封じ込めを行います。それができないSOCは、根本的なアクセスパスが開いたままであるにもかかわらず、アラートを追いかけることに時間を浪費します。
ここで「より多くのクエリ」というアプローチは失敗します。コンテキストが断片化している場合、つまりランタイムデータと設定データが異なるリポジトリに存在する場合、クエリだけで信頼性の高い一貫した答えを導き出すことはできません。調査の早い段階で「何が変更されたか」という経緯が自然に明らかになるように、両方のデータセットとプラットフォームに組み込まれた相関関係が必要です。
5) AIエージェントと委任されたアクション
セキュリティリーダーは現在、非人間ID、すなわちAIエージェントという新たなリスクベクトルに直面しています。これらの非人間IDは、ますますユーザーに代わって行動するようになっています。一部のアクションは人間から、一部は自動化から、一部はエージェントから、そして一部は委任された認証情報から発生します。リーダーは、行動主体が誰であったか、どの権限が使用されたか、そしてその行動が何に影響を与えたかを理解する必要があります。
このカテゴリは、エンジニアリングチームの運用方法やデータへのアクセス方法にすでに現れています。もしSOCが、人間によるアクションと委任されたアクションを明確な証拠の痕跡をもって区別できない場合、検知と封じ込めが遅れ、事後的な解釈に頼ることになります。
回答先行型のアプローチでは、「誰が行動したか」と「誰のために行動したか」をアナリストの推測ではなく、調査の根源的な情報として扱います。
セキュリティリーダーが検証できる形でExaforceが異なる点
多くのプラットフォームが「AI」を表面的な機能として利用しています。セキュリティリーダーは、別の要約ボックスを必要としていません。彼らが必要としているのは、意思決定と証拠を一貫して生み出す運用モデルです。
Exaforceのモデルはシンプルです。セキュリティ関連データを相関させることで、すべてのアラートが、証拠が添付された状態で、すでにトリアージ済みで届くようにします。検出、トリアージ、調査、対応が1つのプラットフォームで完結します。その結果、より広範なカバレッジ、より正確な回答、大幅な作業量の削減、そして総コストの低減が実現します。
ほとんどのSIEMはログを保存するだけです。相関分析、調査、人員配置はユーザー任せか、期待に応えられないMSSPに任せています。Exaforceは継続的に すべての セキュリティデータ（ログ、設定、ID、リソース）を相関分析するため、すべてのアラートは証拠が添付された状態で、すでにトリアージ済みで届きます。検出、トリアージ、調査、対応は1つのプラットフォームで実行されます。より広範なカバレッジ、より正確な回答、大幅な作業量の削減、そして総コストの低減が実現し、ご自身で運用することも、弊社にMDRを運用させることも可能です。
ExaforceはエージェンティックなSOCプラットフォームであり、ほとんどのお客様にとって主要なSIEMでありMDRでもあります。Exaforceは、さらなるクエリではなく、証拠に基づいた回答を提供することを中心に構築されています。アナリストがシステム間を行き来して手動で状況を組み立てるのではなく、Exaforceはアクティビティ、ID、アクセス、変更を、リーダーが最も重視する質問（何が起こったのか、それが何を意味するのか、影響範囲、そして次の行動）に答えるように構造化された調査に結びつけます。
ExaforceでSIEMポッシブルチャレンジに挑戦しましょう
SIEMポッシブルチャレンジは、リーダーシップの課題です。リーダーは意思決定に責任を負い、意思決定には根拠を説明できる回答が必要です。実務家が日々尋ねる質問がそれを明確にしています。影響範囲は何か、何が変更されたか、何が共有されているか、誰がアクセス権を持っているか、何が継承されているか、そして誰が誰のために行動したか。
Exaforceは、これらの質問にデフォルトのワークフローとして回答できるように構築されています。だからこそ、私たちは「クエリではなく、回答から始めよう」と言っています。もしあなたのSOCが、時間的プレッシャーの中で証拠を伴う回答を一貫して提供できないのであれば、それは人材の問題ではありません。プラットフォームの問題です。
そして、それは解決可能です — Exaforceで。
