SIEM、EDR、XDR間の検出ルール可搬性

検出ルールの移植性とは、SIEM、EDR、およびXDRプラットフォーム間で完全な書き直しを行わなくても、「脅威検出」のロジックを記述および管理する手法です。

新しいSIEMプラットフォームに移行した場合、検出ルールはどうなりますか？

プラットフォーム固有のクエリ言語で書かれたルールは移動しません。SPLはSplunkにとどまり、KQLは Microsoft Sentinelにとどまります。YARA-LはGoogle SecOpsにとどまります。移行時には、それらのルールを宛先プラットフォーム用に書き直すか翻訳する必要があります。

翻訳の精度は構造に依存し、言語ペアには依存しません。2つの劣化軸がどれが保存されるかを決定します。

軸1: フィールドマッピング。 ソースフィールドの分類法（CIM, ASIM, ECS, OCSF, Sysmonネイティブ, ベンダーネイティブ）は不完全にマップされます。マップされていないか名前が変更されたフィールドは、ルールの狭小化または破損を静かに引き起こします。

軸2: 構造意味。 集約およびタイムウィンドウの意味、シーケンスまたはトランザクションのロジック、正規表現の方言、および評価/ルックアップ/結合スタイルの関数は、多くの場合、ターゲットプラットフォーム上で部分的にしか類似しません。この軸が書き直しの一部を担います。

Sigma ルールは翻訳を前提に設計されています。一度作成され、バックエンドごとに pySigma, sigma-cli、または Uncoder経由で翻訳されます。

翻訳は保存とは異なります。翻訳された各ルールは、信頼される前に宛先の解析されたフィールドに対するバックエンド固有の検証を必要とします。構文的に正しい翻訳でも、新しいプラットフォームが埋め込まないフィールドを参照していることがあります。

テレメトリパイプラインのルーティングは別のメカニズムです。ログストリームを新しい宛先にルーティングしても、その上で動作していた検出ロジックを移植することはありません。どこにログが置かれてもSPLはSPLのままです。

ベンダー固有の検出ルールとベンダー非依存の検出ルールの違いは何ですか？

ベンダー固有のルールはプラットフォームの資産です。ベンダー非依存のルールはチームの資産です。

次元	SPL (Splunk)	KQL (Microsoft Sentinel)	YARA-L (Google SecOps)	Sigma
ネイティブで実行されます	Splunk	Microsoft Sentinel	Google SecOps	直接的にはありません。これらすべてとIBM QRadar、Elastic、CrowdStrike、その他に翻訳されます。
それを移動するには	対象言語での書き直しが必要です	対象言語での書き直しが必要です	対象言語での書き直しが必要です	pySigma/sigma-cliまたはUncoder経由の翻訳、その後フィールドマッピングの検証
所有者	Splunkのデプロイ	Sentinelのワークスペース	SecOpsのテナント	バージョン管理でのチーム
マルチプラットフォームのコスト	Nコピーを書きます	Nコピーを書きます	Nコピーを書きます	バックエンドごとに一度翻訳し、バックエンドごとに一度検証します

コストの差は、移行時とマルチプラットフォーム操作時に現れます。ベンダー非依存の検出ロジックは、スタック全体で移植性を保ちます。

SplunkからMicrosoft Sentinelに検出コンテンツを移行するにはどうすればよいですか？

6ステップ。SPLとKQLはデータモデル、フィールド命名、関数の意味が異なるため、この言語ペアは困難な部類に入ります。

SPLルールのインベントリを作成します。 保存された検索、アラート、相関検索をすべてエクスポートします。各ルールのデータモデル依存性（sourcetype、index、フィールド名）を記録します。

構造タイプ別に分類します。 ルールを3つのバケットに分類します: 通常の選択ロジック（きれいに移植される）、フィールドマッピング依存（マッピング作業が必要）、相関/ステートフルロジック（手作業での書き直しを期待する）。

Sigmaを通して翻訳します。 SPLルールをSigmaに変換し、その後Microsoft Sentinelのバックエンド、sigma-cli、またはUncoderを使用してSigmaをKQLに翻訳します。これにより構文が処理されます。フィールドマッピングは処理しません。

Sentinelスキーマに対してフィールドをマッピングします。 CIMフィールド名をASIMの同等品に合わせます。Microsoftはスキーマを learn.microsoft.comに文書化しています。翻訳されたルール内のすべてのフィールドは、宛先テーブルのカラムに対応している必要があります。

Sentinelテーブルでテストします。 翻訳された各ルールを実際に取り込まれたデータに対して実行します。スキーマが変更された後も一致を検証できるように、各ルールにテストイベントを保持します。

切り替える際は並行運用ウィンドウを設定します。 両方のプラットフォームを同じログソースで運用します。アラート出力を比較します。同じイベントでKQLバージョンが発火するまではSPLバージョンを退役させません。

切り替え前に、両プラットフォームの導入されたルールを MITRE ATT&CK 技術にマッピングし、2つのマップを比較することで、移行で落とされた技術が、切り替えの後ではなく前に発見されるようにします; SOC Primeの MITRE ATT&CK監査は、ATT&CKをサービスとしてデプロイされた検出およびデータソースにマッピングします。

ライブラリを移行しますか？SOC Primeの Primeアーキテクトを探索し、クロスプラットフォームのルール翻訳、脅威の調査、および検出エンジニアリングワークフローを利用します。

営業に問い合わせる

SPLをKQLに翻訳するためのベストプラクティスは何ですか？

構文ではなくロジックを翻訳します。文字ごとのポートは、宛先が埋め込まない可能性のあるフィールドを参照する脆弱なルールを生成します。

宛先スキーマに対してフィールドをマッピングします。 フィールド名が引き継がれると想定しないでください。Splunk CIMとSentinel ASIMは異なる契約です。移行作業はそれらの間のマッピングに依存します。
ルールごとにテストイベントを保持します。 既知の悪いイベントと既知の無害なイベントのペア。翻訳されたルールが悪をマッチし、無害を拒否しないなら、翻訳で何かが壊れています。
トランスレーターがフラグを立てたものをすべて確認します。 自動翻訳ツールは、通常の選択ロジックをうまく処理します。相関ルール、プロプライエタリ関数、および複雑な集約には人間の確認が必要です。
ツールの名前を指定します。 Primeアーキテクト Sigmaを 65の検出言語に翻訳し、ネイティブクエリ言語（例えばSPLやKQL）の間で移行し、接続した環境用のフィールドマッピングプリセットを適用し、ガバナンスのあるルールリポジトリからサポートされたターゲットプラットフォームへのデプロイを行います。オープンソースの Uncoder IO は、翻訳ステップをカバーし、自分のホスト（GitHubでのソース）で実行できます。これらのツールはどれもフィールドマッピング検証を無効にしません。

例: イベントコード=4688とNew_Process_Name（Splunk CIM）のシンプルなプロセス作成ルールがEventID == 4688とNewProcessName（Sentinel SecurityEventテーブル）に翻訳されます。同じ事実でも、プラットフォーム契約ごとにフィールド名が異なります。

SPLのトレーリング・アンカー付きワイルドカードはKQLのendswithオペレーターに変わります。このペアは1つのイベントフィールドの一致であるため有効です。相関ルールはこのようにはクリーンに翻訳されません。

ルールライブラリの移行にはどのくらい時間がかかり、何がそれを駆動しますか？

3つの駆動要素が努力を決めます。

ルールの数。 ルールが多いほど検証サイクルは増加します。翻訳された各ルールは、宛先で取り込まれたデータに対してテスト実行が必要です。

カスタムフィールドとデータモデルの依存関係。 ベンダー固有のフィールド、カスタム抽出、またはルックアップテーブルを参照するルールには、フィールドごとのマッピング作業が必要です。ソースのカスタマイズが多いほど、移行には多くの手作業が必要です。

検証努力。 翻訳されたすべてのルールは、宛先プラットフォームの解析されたフィールドに対して検証されなければなりません。構文的に正しい翻訳は、ターゲットスキーマが参照されたフィールドを埋め込まない場合、静かに失敗する可能性があります。

移行評価からの正直な成果物は、ルールごとの分類です: クリーンに移植される/ マッピング作業が必要/ 手作業の書き直しが必要。ライブラリ全体の単一の時間見積もりは、努力の分布を誤って伝えます。

次回のロックインを回避する方法は何ですか？

3つのプラクティスです。

Sigmaで作成します。 最初からベンダー非依存の検出ロジックを記述します。Sigmaルールはすべての主要なSIEM、EDR、およびXDRプラットフォームに翻訳されます。Sigmaで既にソースされている検出コンテンツ（例えば、SOC Prime’s CoreにあるSigmaルール）は、最初のルールからライブラリの移植性を維持します。 SOC Prime’s Core, keeps the library portable from the first rule.

バージョン管理でロジックを保持します。 検出ルールを、各ターゲットバックエンドに対するフィールドマッピングおよびテストイベントと共にGitに保存します。ルールはプラットフォームではなくチームと共に移動します。

配備時に翻訳します。 pySigma、sigma-cli、またはUncoderを使用して、配備時にプラットフォームネイティブのクエリを生成します。ソースは移植可能なままです。コンパイルされた出力は使い捨てです。

この分離により、プラットフォームの移行は翻訳のターゲットを変更しますが、検出ロジックを変更することはありません。

テレメトリをパイプライン経由でルーティングすることは、検出を移植可能にするのと同じですか？

いいえ。テレメトリパイプライン（Criblや類似のツール）はデータを移動します。検出ロジックを移動しません。

SplunkからMicrosoft Sentinelへのログストリームをパイプライン経由でルーティングすることは、イベントを新しい宛先に送ります。ただし、Splunkでそのイベントに対して実行されたSPLルールは従いません。SPLはSPLのままです。したがって、宛先プラットフォーム用にロジックを翻訳または書き直す必要があります。

パイプラインのルーティングはデータ配信の問題を解決しますが、検出の移植性はロジック翻訳の問題を解決します。それらは独立しています。テレメトリを新しいSIEMにルーティングしても検出が移植されなければ、新しい場所にデータはあるものの、それにマッチするルールは存在しません。

例外として、検出自体を実行するパイプラインがあります: SOC PrimeのPrime Detectは、SIEMの前でパイプライン層にSigmaのルールを適用し、そのオープンソース版は GitHub.

にあります。

これが有効でない場合

Sigmaを使用しても、すべてを翻訳できるわけではありません。4つの構造クラスは宛先プラットフォームで手作業による書き直しが必要です。 相関およびステートフルロジック。
カウントと値の集約、一時的なシーケンス、マルチイベント相関。Sigmaはv2の仕様で相関ルールタイプを追加しましたが、バックエンドのサポートはpySigmaバックエンドごとに異なります。スケジュールとストリーミング実行もルールが表現できるものを変えます。プロプライエタリ関数。
Splunkトランザクション、評価式、ルックアップドリブンのエンリッチメント、マクロ。KQLの類似は部分的です。 いくつかの集約パターン。
ウィンドウを超えた閾値構造や、統計… by … span=のパターンは、プラットフォーム間で不均一に翻訳されます。 スキーマに依存するフィールド参照。

同じSigmaプロセス作成ルールは、パイプラインによって異なるフィールドに着地します。SysmonではImageです。Splunk Windows SecurityではNew_Process_Nameです。翻訳は実際に展開されたスキーマに対してのみ正確です。

これらの構造は、ルールごとの分類が最も重要です。手動検証が必要で、多くの場合、根本的な書き直しが必要です。

移行準備チェックリスト

[ ] フルルールインベントリのエクスポート（保存された検索、アラート、相関検索）

[ ] 各ルールを分類: ポートクリーン / マッピングと一緒に移植 / 書き直しが必要

[ ] フィールドマッピングテーブルの作成: ソーススキーマから宛先スキーマ

[ ] ポータブルルールのSigmaバージョンを作成してバージョン管理に保存

[ ] 翻訳ツールの選択 (pySigma/sigma-cli, Uncoder, またはその両方)

[ ] ルールごとに作成されたテストイベントペア（1つは既知の悪、もう1つは既知の無害）

[ ] 宛先テーブルでの翻訳されたルールの実際の取り込まれたデータによる検証

[ ] 手作業による書き直しが必要な相関およびステートフルルールの特定

[ ] プロプライエタリ関数のカタログ化（トランザクション、評価、ルックアップ、マクロ）

[ ] 並行運用ウィンドウの定義: 両方のプラットフォームが同じソースを取り込んでいる

[ ] アラート出力の比較基準の文書化

FAQ

新しいSIEMプラットフォームに移行した場合、検出ルールはどうなりますか？

プラットフォームネイティブのルールは移動しません。SPL, KQL, YARA-Lは宛先プラットフォーム用に書き直すか翻訳されなければなりません。Sigmaで作られたルールは各バックエンド用に一度翻訳され、翻訳された各ルールは依然として宛先の解析済みフィールドに対する検証が必要です。相関、ステートフルロジック、プロプライエタリ関数、およびいくつかの集約パターンは、クリーンに翻訳されません。

SplunkからMicrosoft Sentinelに検出コンテンツを移行するにはどうすればよいですか？

SPLルールをインベントリして、構造タイプごとに分類し、Sigmaを通してpySigmaまたはUncoderで翻訳し、SplunkスキーマからSentinelスキーマにフィールドをマッピングし、各ルールを実際に取り込まれたSentinelデータに対してテストし、その後並行運用ウィンドウで切り替えて、SPLバージョンを退役させます。MicrosoftはSentinelスキーマをlearn.microsoft.comで文書化しています。

ベンダー固有の検出ルールとベンダー非依存の検出ルールの違いは何ですか？

ベンダー固有のルールは、それが実行されるプラットフォームの資産です。Sigmaで作成されたベンダー非依存のルールは、バージョン管理に保持され、各バックエンドごとに翻訳されるチームの資産です。コストの違いは、移行時とマルチプラットフォーム運用時に現れます。

テレメトリをパイプライン経由でルーティングすることで検出が移植可能になりますか？

いいえ。テレメトリパイプラインはデータを新しい宛先に移動します。それが行われた検出ロジックは移動しません。SPLはログの着地場所に関係なくSPLのままであるため、ルールは依然として翻訳または書き直しが必要です。

SPLをKQLに翻訳するためのベストプラクティスは何ですか？

ロジックを翻訳し、構文ではなく宛先スキーマに対して各フィールドをマッピングします。ルールごとに1つの既知の悪と1つの既知の無害のテストイベントを保持し、トランスレーターがフラグを立てたものを確認します。相関ルールとプロプライエタリ関数は人間の確認が必要です。pySigma、sigma-cli、およびUncoderはSigma翻訳を処理し、いずれもフィールドマッピング検証を排除しません。

既存のSIEMカバレッジを評価し、遷移の計画を立てるために Prime Huntを使用します。Prime HuntはすべてのSIEMルールをレビューし、ギャップを特定し、SIEM移行前の重要な作業である完全なカバレッジに向けたコースを示します。