MSSPおよびMDRプロバイダーのためのマルチテナント検知操作

マルチテナント検知業務は、ベンダー非依存の検知ロジックを1つのソースから管理し、各テナントごとに翻訳・調整することで、異なるSIEMプラットフォームを実行する顧客群が一つの統制されたソースから一貫性を保ち、チューニングでき、レポート可能にする手法です。

数十のテナント向けに検知を運用するMSSPが直面する構造的な問題は、各顧客が個別に検知ルールを持つのか、それとも1つの統制されたソースが各テナントごとに翻訳・調整するのか、という点です。この答えは運用コスト、カバレッジ報告の精度、及び共有ロジックに対する変更が即座に反映されるのか、手作業のパッチの待ち行列に入るのかを決定します。

このページは、そのモデルの検知コンテンツ層をカバーしています。これは、ベンダー非依存の検知ロジックの1つのソースを中央で管理し、各テナントごとに翻訳・調整するものです。Huntersは、MSSPやMDRプロバイダー向けにSOCとSIEMの代替プラットフォームとして、分析と運用の層で動作します。ContraForceは、ケース管理と配信ワークフロー層で動作し、Microsoftセキュリティスタック（Microsoft Sentinelと Defender XDR）に向けています。ここで説明する検知コンテンツのソースは上流に位置し、実行、調査、レポーティング層が使用するベンダー非依存の検知ロジックを供給します。

範囲: SIEMプラットフォーム（Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, CrowdStrike）。EDRの展開ターゲットは、プラットフォームサポートの確認がされるまで範囲外です。

MSSPはそれ自体でも規制対象の組織です。 委員会実施規則 (EU) 2024/2690は、2024年11月7日以降発効しており、NIS2の下で管理されたセキュリティサービスプロバイダーに対するモニタリングとロギングの要件（付録セクション3.2）を設定しています。MSSP自身の証拠義務が、テナントだけでなく、検知コンテンツの管理と報告方法を駆動します。

異なるSIEMプラットフォームを実行する顧客環境で、マルチテナントSOCが検知ロジックをどのように一貫性を保つことができるでしょうか？

検知ロジックをベンダー非依存のフォーマット（Sigma）で一度記述します。それを各テナントのSIEMに翻訳し、ソースを中央で管理します。

共有された基本アーティファクト

基本は単一の検知ロジックアーティファクトです。そのロジック条件は、テナントの生ログフィールドに対してではなく、共通で正規化されたスキーマに対して評価されます。これにより、Splunk、Microsoft Sentinel、Google SecOps、Elastic、CrowdStrikeなどで検知ロジック自体を再作成することなく、同じルールを利用できるようになります。

正規化は、ソースに特化したフィールドを共有されたスキーマにマッピングし、セマンティクスを保持します。正規化されたフィールドauth.resultに対して書かれたルールは、どのアイデンティティプロバイダーがイベントを生成したかにかかわらず、同じ意味を持ちます: auth.resultは、命名されたセマンティック契約に従い{成功、失敗、挑戦}に解決され、顧客のIdPがそのフィールドをどう呼ぶかに依存しません。

テナントごとのオーバーレイ

各テナントにはオーバーレイがあります。オーバーレイは、そのテナントの生ソースフィールドを共有の正規化スキーマに翻訳するフィールドマッピングと、そのテナントの環境に合わせたチューニングパラメータ（しきい値、時間ウィンドウ、ノイズ除外）を持ちます。基本とオーバーレイは別々にバージョン管理されます。

基本へのロジック更新は、必要なフィールドをマッピングするオーバーレイを持つすべてのテナントに伝播します。1つのテナントのオーバーレイへの調整変更は、そのテナントにのみ影響します。

共有対テナント特異

共有されるもの: 検知ロジック条件、ロジックが依存するセマンティック契約定義、 MITRE ATT&CK 手法タグ、バージョンと変更履歴。

テナント特有のもの: 生から正規化へのフィールドマッピング、ランタイムでの契約検証ステータス（ルールの静的特性ではなく、各テナントの実際のイベントストリームに基づき合格または不合格が評価される）、プラットフォームターゲット翻訳、及びチューニングパラメータ。

数十の顧客環境での検知コンテンツを顧客ごとにフォークせずに管理するにはどうすればいいですか？

1つの検知ごとに統制されたアーティファクトを持ち、顧客ごとにフォークしないこと。

顧客ごとにルールファイルをフォークするということは、本来統制された1つのアーティファクトであるべきものを独立したコピーとして維持することを意味します。ロジックの修正や新しい回避技術の更新は、すべてのフォークに手作業で再適用しなければなりません。フォークは分散し、単一のバージョン変更履歴は消えてしまいます。

監査人や顧客から「このルールを誰がいつ、なぜ変更したのか」と聞かれたときに、その答えは1つのタイムラインを追跡できる必要があります。異なるコピーが同じ修正を反映しているかどうかわからない状態では、この質問に答えられません。それはガバナンスと変更管理の失敗であり、監査人が依存する証拠の証跡を直接損ないます。

基本とオーバーレイのモデルは1つのアーティファクトを統制される形に維持します。

レイヤー	含まれるもの	範囲
基本（共有）	検知ロジック条件、セマンティック/時間/相関契約定義、MITRE ATT&CK手法タグ、バージョンと変更履歴	すべてのテナント
オーバーレイ（テナントごと）	生から正規化へのフィールドマッピング、プラットフォームターゲット翻訳、しきい値、時間ウィンドウ、ノイズ除外	1つのテナント

基本ロジックへの1つの変更は構造的に伝播します。マッピングとチューニングのみがローカルに留まります。これは、 検知をコードとして マルチテナントの運用では、ルールの変更がバージョン管理され、レビューされ、コードアーティファクトとして追跡される操作手法のことです。展開の自動化は、更新された基本をそのオーバーレイが対応しているすべてのテナントに運びます。

契約のバージョン管理は基本を統制します。変更はバージョン化される必要があり、破壊的な変更には新しい契約IDが必要です。そのため、すべてのテナントが静かに壊れることなく調整可能なアップグレードパスを得ることができます。

SOC Primeは、MDRと協力してSIEM検出からPrime DetectによるSIEMボリューム削減までの検知エンジニアリング作業を設計します。

営業に問い合わせ

共有ルールを壊さずに顧客ごとにどのようにチューニングするのですか？

オーバーレイでチューニングします。基本ルールは固定したままです。

オーバーレイは2つの部分から成るテナント特有の構成を含みます。

フィールドマッピング。 各テナントのソース製品は、生ログで同じ事実を異なる名前で表記するため、オーバーレイはそれらの生フィールドを共有された正規化スキーマに翻訳します。このマッピングは、他のすべてのテナントが共有するのと同じセマンティック契約を独立して満たす必要があります。

具体的な失敗の理由はこれが重要であることを示します。1つのテナントのオーバーレイが、そのアイデンティティプロバイダーの「MFA保留中」という結果を「挑戦」ではなく「失敗」に正規化値にマッピングします。共有されたMFAバイパス検知ロジックは、挑戦イベントが先行しない成功したログインを探しますが、そのテナントには「挑戦」値が表示されません。すべての成功したログインがバイパスとしてフラグされ、その1つのテナントに対して大量の誤検知が発生します。一方、同じルールはその他のテナントのオーバーレイが列挙を正確にマッピングしている限り正しいです。

ルールは一度も変更されていません。失敗は完全にオーバーレイの中にあり、オーバーレイエラーがルールバグとして偽装しています。

チューニングパラメータ。 関連イベントをリンクするための相関許容時間、認証シーケンスのセッションタイムアウトと猶予期間ウィンドウ、及びノイズ除外。許容が厳しすぎると実際の相関が見逃され、緩すぎると無関係なイベントを結合します。これらのウィンドウは、そのテナントのクロック同期とレイテンシー特性に合わせてテナントごとに調整が必要です。

基本ルールの検知ロジック条件は、正規化フィールドを評価する際、単一のテナントに対して変更されることはありません。契約検証ステータスは、実行時にテナントごとに評価される必要があり、ルールまたはソースタイプからは推測されません。

各顧客に対して異なるログソースを送信するときに、MITRE ATT&CKの検知カバレッジをどのように報告しますか？

そのテナント自身の優先順位付けされた手法セットに対してテナントごとにカバレッジを計算します。異なるテナント全体で1つのライブラリ数として報告しないでください。MITRE ATT&CKの検知カバレッジの測定に関する伴侶ページで説明されている完全な測定方法を参照してください。

カバレッジテンプレート:

カバレッジ（テナント） = [テレメトリ有効かつルール展開済みかつルールが作動することが証明された]技法 ÷ そのテナントの優先技法数。

技法がカバーされているとみなされる場合

技法がカバーされているとみなされるのは、これらすべてが一緒に保たれている場合のみです。

1. このテナントに対するテレメトリが有効である。 必須データソースが収集され、アクティブに取り込まれ、セマンティック、時間、および相関契約を通過し、品質SLO（ヌル率、新鮮さ）を満たしている。すべてのこれらは、このテナントの実際のイベントストリームに対して評価され、ソースタイプのデフォルトではありません。

2. 技法にマッピングされたルールが展開されている。 検知をコードとしてのインベントリ事実: どのルールが存在するか、そのMITRE ATT&CKタグを持つか、そのバージョン。

3. ルールが発砲の証拠を持っている。 ファイアレートベースライニング、カナリアイベント、または実際またはエミュレートされた活動に対してアラートを生成するルールを示す原子テストの検証。発砲の記録のない技法タグはラベルであり、証拠ではありません。

分母はそのテナント自身の命名された優先順位付けされた ATT&CK手法のサブセット。決して完全ではありません ATT&CK マトリックス。ベンダーのルールライブラリのサイズでもありません。

ギャップ状態の報告

ギャップ状態を1つの押し込められた数値ではなく明確に報告してください。

状態	意味	是正策
VALID	すべてのゲートが通過し、ルールが展開され、レポート日現在の証明ファイルが発砲された	カバレッドとして報告日に
INVALID	必要なソースが収集されていない、または取り込まれていない	ソースの有効化または取り込みの修復
DEGRADED	ソースが収集されているが、契約または品質SLOが失敗している	マッピング、パーサー、またはスキーマの修正
コンテンツギャップ	テレメトリが有効であるが、技法にマッピングされたルールがない	コンテンツ開発

INVALIDとDEGRADEDを1つの「ギャップ」ナンバーにはしないでください。異なる失敗モードは異なる是正策を必要とし、異なる顧客との会話を生み出します。

日付を付けて報告します。カバレッジは時点のものです。

コンテンツの再利用は利益率とアナリストのトレーニング負荷に何をしますか？

異なるテナントにわたるコンテンツの再利用は、顧客ごとの検知エンジニアリングコストを共有され、償却されるコストに変換します。基本の検知ロジックが一度作成され、テナントごとに翻訳されると、エンジニアリングコストは顧客帳簿に広がります。

利益率。 共有基盤を実行するすべてのテナントは、追加の検知エンジニアリング時間を回避します。利益率の改善は構造的です。SOC Primeの MDRパートナープログラム は、脅威研究と検知コンテンツのコーディングで年間4K時間の節約を示しています。

トレーニング負荷。 1つの検知をコードとしての方法論。1つの正規化スキーマ。1組の契約セマンティクス。アナリストは、顧客ごとのルールライブラリが異なる名前付け、構造、意図を持つのではなく、共有モデルに対してオンボードされます。アナリストが1つのテナントのキューから他のテナントに移動するとき、検知ロジック、スキーマ、契約はすでに馴染みがあります。

正直な異議。 共有検知コンテンツはMSSPの差別化を消しません。差別化はチューニング、応答、および報告に移動します。テナント特有のオーバーレイ、応答ランブック、お客様向け報告はMSSPの価値が現れる場所です。「共有コンテンツ」と聞いて「商品」と思う見込み客は、カスタム作業がどこにあるかを正確に知る必要があります。

規制ドライバー。 NIS2の下でのMSSP自身の証拠義務は、委員会実施規則 (EU) 2024/2690により、テナントだけでなくMSSP自身からのモニタリングとロギングの証拠を要求しています。共有モデルはその証拠生成を償却します。

これが成り立たない場合

基本とオーバーレイのモデルは、基本ルールが各テナントのソース製品が満たすことができる正規化スキーマに基づいて書かれていることを前提としています。このモデルは、次の条件下で破綻します。

1. 必要なデータを発行しないソース製品。 異なるソース製品、または同じ製品の異なるバージョンは、まったくデータコンポーネントを発行しない場合があります。オーバーレイでは構造的に欠けているフィールドは修正できません。これは無効なギャップであり、ソースの有効化またはアップグレードによって対応されます。

2. ソースの可用性。 テナントが必要なログソースをオンボードしていないか、取り込みが中断しています。ルール、マッピング、調整がすべて正しい可能性がありますが、ソースが再び流入するまで影響を受ける技法はカバーされません。

3. 相関許容ミスマッチ。 共有デフォルトの時間許容は、異常なクロック同期やレイテンシーを持つテナントにとって実際の相関を見逃す可能性があります。相関ウィンドウのテナントごとの調整が必要であり、選択肢ではありません。

4. ユニークな脅威モデルやデータレジデンシー制約。 本当にユニークな脅威プロファイルを持つテナントは、共有ベースに含まれていないカスタム検知ロジックを必要とするかもしれません。組織境界を越えて検知ロジックアーティファクトを共有することを禁止する制約も同様の効果を持ちます。

5. テナントの隔離は譲れません。 このモデルは、（ルールテキスト、契約定義）に関する検知ロジックをテナント間で共有します。テナントデータ、エンリッチメントキャッシュ、アラート状態、またはバリデーション結果をテナント境界を越えて共有しません。テナントのエンリッチメントルックアップやアラートキューが他のテナントに漏れるようなアーキテクチャは設計上の優先度1のインシデントです。ロジック共有とデータ共有は異なる主張です。

 

マルチテナント運用モデルのチェックリスト

基本ルールを作成し、管理する

• 正規化された、契約定義されたスキーマに基づいてベンダー非依存の形式（Sigma）で書かれた検知ロジック
• テナントオーバーレイから分離された基本ルール: 検知ロジック、契約定義、MITRE ATT&CKタグ、バージョン履歴が共有され続ける
• 各テナントに対するオーバーレイは、フィールドマッピング、プラットフォーム翻訳、およびチューニングパラメータのみを運び、基本とは別にバージョン管理される
• 基本ルールの変更は、構造的にすべてのテナントに伝播される
• 変更履歴は、各基本ルールごとに統制されたタイムラインをトレースし、オーバーレイの変更はテナントごとに追跡される
• 契約のバージョン管理の徹底: 破壊的な変更には新しい契約IDが伴う

マッピングとプラットフォーム翻訳を検証する

• フィールドマッピングはテナントごとに同じセマンティック契約を満たし、契約の検証は、各テナントの実際のイベントストリームに対して実行時に行われる
• プラットフォーム翻訳はターゲットSIEM（Splunk、Microsoft Sentinel、Google SecOps、Elastic Security、CrowdStrike）ごとに検証されている

テナントごとにカバレッジを計算する

• カバレッジはテナントごとに、そのテナントの優先されるATT&CK技法セットに対して計算される
• カバレッジの分子には、テレメトリ有効、ルール展開済み、ルールの発砲が証明されている、すべてが一緒に真である必要がある
• ギャップ状態の区別: VALID, INVALID (ソースが存在しない場合), DEGRADED (ソースが存在しているが、検証失敗の場合), コンテンツギャップ (テレメトリが有効であり、マッピングされたルールが存在しない)

チューニング、隔離、およびレポート

• テナントごとにクロック同期とレイテンシー適合性のために相関時間許容をレビューする
• チューニングはオーバーレイで調整し、ベースルールのフォークはしない
• テナントの隔离を徹底: テナント間において、共有データ、エンリッチメントキャッシュ、アラート状態、または検証結果を共有しない
• カバレッジは日時を添えて、テナントごとに報告され、帳簿全体のライブラリナンバーとして報告されることはない
• MSSP自身の規制証拠義務（NIS2実施規則2024/2690）は、テナントの義務と並行して対処されます
• アナリストトレーニングは、共有の検知をコードとしての方法論、正規化スキーマ、契約セマンティクスに合わせて調整される

営業に問い合わせ

関連読書

• Prime DetectのROI: パイプライン層での検知からの検証済みの節約 （2026年9月）
• MSSPとMDRがUncoder AIで脅威検知効率を最大化する方法 （2024年10月）
• SOC PrimeであなたのMDRの卓越性を加速する （2023年11月）