Sigma検知ルールの56%は改訂される｜研究解説

「検知ルールは一度作り込めば安定する」——この前提は、公開リポジトリのデータで見る限り成り立っていません。SigmaとSplunk Security Contentの6,859件のルール改訂履歴を追った研究（arXiv、査読前）によると、約56%のルールが検知ロジック自体を書き換えられており、しかもその変更は一方向に洗練されていくのではなく、条件を足したり削ったりを行き来する「非単調」な動きを見せていました。検知ルールの運用は「完成」ではなく「終わりのないトレードオフ調整」だ、というのがこの研究の含意です。

この記事でわかること

  • SigmaとSplunk Security Contentとは何者で、自社のSIEM/EDRとどう関係しているか
  • 6,859件のルール履歴を分析して何がわかったのか（具体的な数字）
  • なぜルールは「行ったり来たり」するのか、その運用上の理由
  • 情シスが自社の検知ルール運用に持ち帰れる論点

SigmaとSplunk Security Contentとは何者か

本題に入る前に、研究対象になった2つのリポジトリを押さえておきます。「うちは使っていない」と思っている方こそ、実は間接的に使っている可能性があります。

Sigma：SIEM非依存の「検知ルールの共通言語」

Sigmaとは、ログイベントから脅威を検知するための条件を、SIEM製品に依存しない共通のYAML形式で記述・共有するためのオープンな検知フォーマットです。公式サイトは「セキュリティチームが、関連するログイベントをシンプルかつ共有可能な形で検知できるようにする、汎用的でオープンな構造化検知フォーマット」と定義しています。

用途は明確で、「この攻撃はこのログのこの条件で見つかる」という検知ノウハウを、ベンダーをまたいで流通させることです。書いたルールはコンバータを通してSplunk、Elasticsearch、IBM QRadarなど各SIEMのクエリに変換されます。SigmaHQが公開するメインのリポジトリには3,000本超の検知ルールが、汎用検知・脅威ハンティング・新興脅威などに分かれて収録されています。

そして重要なのが、この「組み込まれ方」です。Sigmaを自分で導入した記憶がなくても、VirusTotal、Security Onion、LimaCharlie、MISP、Joe Sandboxといったツール群や、各種EDR・XDR製品の内部でSigmaルールが取り込まれて動いていることがあります。自社SOCの検知ロジックの一部が、実は外部コミュニティが日々書き換えているルールに由来している、という構図はごく普通に起こり得ます。SIEMの検知ルール設定画面に「Sigma」「community rules」といった表記があれば、まずそこを確認してみてください。

Splunk Security Content（SSC）：ベンダーが管理する検知コンテンツ

Splunk Security Contentとは、Splunk社の脅威リサーチチームが管理・公開している検知ルールとアナリティックストーリー（TTP解説付きのユースケース集）のリポジトリです。MITRE ATT&CKにマッピングされた検知内容、マクロ、ルックアップ、プレイブックなどが含まれます。

こちらもユーザーが意識せず使っているケースが多い代表格です。配信経路はES Content Update（ESCU）で、Splunk Enterprise Securityに同梱される形、あるいはSplunkbaseのアプリ（DA-ESS-ContentUpdate）として自動的に更新が降ってきます。つまり、Splunk ESを運用している組織では、この研究が分析したのと同じルール群が、更新のたびに自社環境の検知ロジックとして入れ替わっていることになります。

どんな研究か

Minjun Long氏とDavid Evans氏による「Evolution of Log-Based Detection Rules in Public Repositories」（arXiv:2605.05383）です。ログベースの検知ルールが時間とともにどう変化するかを、リポジトリの改訂履歴から縦断的に分析した初めての研究だと著者らは位置づけています。

手法上の工夫は「表面的な書き換えと、検知ロジックの実質的な変更を区別した」点にあります。ルールのYAMLは、インデントやフィールドの並び順を直しただけでも差分が出ます。そこで研究チームは述語グラフ中間表現（predicate graph intermediate representation）という形式にルールの論理構造を正規化したうえで、木構造のアライメント手法で版と版の間の変化を追い、「条件が1つ増えた／減った」といった意味レベルの変更だけを抽出しました。さらに、その変更が「検知範囲を広げるため」なのか「誤検知を減らすため」なのかという運用上の意図を、LLMによる推定と人手検証を組み合わせて分類しています。

何がわかったのか

観点 分析結果
分析対象 SigmaとSSCの6,859件のルール改訂履歴
検知ロジックが改訂されたルール 約56%が1回以上
変化の方向性 大半が非単調。半数超のルールが条件の追加と削除の両方を経験
差し戻し（reversion） 繰り返し観測される（一度入れた変更を後で戻す）
「拡大」と「誤検知削減」を往復するルール およそ4分の1〜3分の1

「非単調」とはどういう状態か

検知条件が一方的に精密化されていくのではなく、広げては絞り、絞ってはまた広げる、という揺れ動きが続いている状態です。ルールが安定した最終形に収束していくという直感的なイメージは、データ上は支持されませんでした。著者らはこれを「安定への収束ではなく、継続的な運用上のトレードオフの反映」と表現しています。

差し戻しが繰り返し観測された点も見逃せません。一度加えた絞り込み条件を後で撤回している——つまり、その絞り込みで検知漏れが起きたか、環境が変わって前提が崩れたかのどちらかが起きている、ということです。

なぜ検知ルールは行ったり来たりするのか

研究が示した構図は、現場の実感とよく一致します。検知ルールの調整は、常に相反する2つの圧力の間に置かれています。

  • 検知漏れを減らしたい圧力：亜種や別の実行経路を拾うため、条件を緩めたい。攻撃者側は検知回避のために手口を少しずつ変えてくるので、放置すると効かなくなる。
  • アラート量を減らしたい圧力：正規の業務ツールや運用スクリプトが同じ挙動をするため、除外条件を足したい。アラートが多すぎればアナリストが見なくなり、結局は検知漏れと同じ結果になる。

厄介なのは、この均衡点が組織ごと・時期ごとに変わることです。新しい業務システムを導入すれば除外条件が必要になり、そのシステムをやめれば除外は不要になる。公開リポジトリのルールが往復運動をしているのは、多数の環境からのフィードバックを1本のルールに集約しようとしているからだと考えると理解しやすくなります。

情シスはどうすべきか

この研究から実務に持ち帰れるのは、対策リストというより運用設計の論点です。

1. 「検知ルールは資産であり、劣化する」と前提を置き直す

導入時にチューニングして終わり、という運用になっていないかを点検してください。コミュニティやベンダーが管理する公開ルールですら、半数以上が書き換えられているという事実は、自社固有のカスタムルールがメンテナンスなしで有効性を保てる根拠がないことを示しています。ルールにも棚卸しの周期が要ります。

2. 除外条件の「理由」を記録する

差し戻しが頻発するという知見は、逆に言えば「なぜこの条件を入れたのか」が失われると、安全に戻せなくなることを意味します。誤検知を減らすために足した除外条件は、数か月後には誰も理由を説明できなくなりがちです。ルールのコメント欄やチケット番号で、除外の根拠（どの業務システムの、どの正常動作を除外したのか）を必ず残す運用にしておくと、後の見直しコストが大きく下がります。

3. 自動更新されるルールの変更を把握する経路を持つ

ESCUのようにベンダー配信で自動更新される検知コンテンツは、気づかないうちに自社の検知範囲が変わっている可能性があります。更新のリリースノートを見る担当と周期を決めておくだけでも、「あの攻撃が検知されなかった理由が、実は数か月前のルール更新だった」という事態を減らせます。

4. 検知が効いているかは演習で確かめる

ルールの健全性は、書かれた内容を眺めるだけでは判定できません。実際に検知が上がるか、上がったアラートを人が正しく捌けるかを確認する必要があります。IPAはセキュリティインシデント対応 机上演習教材を無償公開しており、検知から報告・判断までの流れを組織で点検する起点として使えます。あわせて、アラートの起点になる利用者側の行動を変えるという意味で、IPAの「対策のしおり」のような啓発資料を使った地道なユーザ教育も、結局は誤検知・実検知の両方を減らす方向に効きます。

現場目線の所感

この論文で一番刺さったのは、56%という数字よりも「差し戻しが繰り返される」という観察のほうでした。誤検知が多いという苦情を受けて除外条件を1行足し、数か月後に「なぜこの除外があるのか誰も知らない」状態になり、棚卸しで消したら今度は大量のアラートが復活する——この往復を、世界中のセキュリティチームが同じようにやっている、というのがデータで見えてしまった格好です。

限られた人員でSIEMを回していると、ルールのチューニングはどうしても「今鳴っているうるさいアラートを黙らせる」方向に偏ります。それ自体は正しい判断なのですが、その積み重ねが検知範囲を静かに削っていくことに気づく仕組みは、たいていの組織にありません。ルールの変更履歴を「劣化のログ」として読み返す時間を、四半期に一度でも確保できているか。この研究は、そこを突いてきます。

限界と留意点

  • 査読前の研究です。arXivに公開されたプレプリント（v1は2026年5月6日、v4は2026年8月20日）であり、結果や解釈は今後変わり得ます。
  • 分析対象は公開リポジトリのルールです。各組織が自社環境で運用しているカスタムルールの改訂傾向がこれと同じとは限りません。公開ルールは多数の環境の要求を1本に集約する性質上、往復運動が起きやすい可能性もあります。
  • 変更意図の分類にLLMを使っています。人手検証を併用しているとはいえ、「検知範囲の拡大」「誤検知の削減」といった意図の推定には誤りが含まれ得ます。4分の1〜3分の1という数値は幅を持って読むべきです。
  • 本記事は公開されている要旨とリポジトリの公式情報に基づいています。手法の詳細は原論文を参照してください。

まとめ

  1. 公開検知ルールの約56%は、検知ロジックそのものが書き換えられている。ルールは「完成品」ではなく、継続的に手を入れ続ける対象である。
  2. 変化は一方向ではなく非単調で、差し戻しも頻発する。検知範囲の拡大と誤検知の削減という相反する要求の間で、往復運動が続いている。
  3. 自社の運用に効くのは「除外条件の理由を残す」「自動更新の変更を追う」「演習で効果を確かめる」の3点。ルールの棚卸しを定例業務に組み込むことが出発点になる。

関連記事

出典

タイトルとURLをコピーしました