Evolution of Log-Based Detection Rules in Public Repositories

あなたは、特定の種類の犯罪者を捕まえようとしている探偵だと想像してください。あなたは、その人物を見分けるための指示、つまり「ルール」を書き留めます。例えば、そのルールはこうなります。「もし赤い帽子を被り、かつ青いバッグを持っている人を見かけたら、警報を鳴らせ。」

サイバーセキュリティの世界では、これらの「ルール」は**ログベースの検知ルール（log-based detection rules）**と呼ばれます。これらは、セキュリティチームが何百万ものコンピュータ記録（ログ）をスキャンして悪党を見つけ出すために使用する指示です。

この論文は、これらの探偵の指示が時間の経過とともにどのように変化するかを調査した長期的な研究です。研究者たちは、セキュリティの専門家がルールを共有している2つの巨大な公開ライブラリ、Sigmaプロジェクト（コミュニティ主導のグループ）とSplunk Security Content（精査されたプロフェッショナルなコレクション）を調査しました。彼らは、進化の過程を見るために、10年近くにわたって数千のルールを追跡しました。

以下に、その発見を簡単な比喩を用いて説明します。

1. ルールに「完成」はない

一度探偵がルールを書いたら、それは永遠に変わらないと思うかもしれません。しかし、研究者たちは56%のルールが少なくとも一度は書き直されていることを発見しました。

これらのルールを、スープのレシピだと考えてみてください。

• 最初、あなたはレシピを書きます：「塩とコショウを加える。」
• その後、塩が強すぎると気づき、こう書き換えます：「塩を減らす。」
• 次に、ニンニクを入れ忘れたことに気づき、ニンニクを加えます。
• さらに、ニンニクを入れると辛すぎると気づき、それを取り除きます。

研究によると、ルールは絶えず微調整されています。ルールは単調に「良くなっていく」のではなく、材料を加えたり取り除いたりしながら、常に上下に変動しているのです。

2. 「シーソー」効果

最も驚くべき発見は、これらのルールが落ち着くことが滅多にないということです。代わりに、これらはシーソーのように動きます。

• サイドA（カバレッジ/網羅性）： 時には、探偵はより多くの犯罪者を捕まえたいと考えます。彼らはルールを広げます：「もし赤い帽子、あるいは青いバッグ、あるいは緑のスカラップを見かけたら、警報を鳴らせ！」 これにより、より多くの悪党を捕まえられますが、同時に罪のない人々まで誤って捕まえてしまいます（誤検知）。
• サイドB（偽陽性/誤検知）： 次に、探偵は誤って捕まった人々に対して苛立ちを感じます。そこでルールを厳格にします：「赤い帽子を被り、かつ青いバッグを持っている場合のみ、警報を鳴らせ。」 これにより誤検知は止まりますが、今度は本物の犯罪者を見逃してしまう可能性があります。

研究では、約3分の1のルールが、数年間にわたってこれら2つのサイドの間を揺れ動いていることが分かりました。彼らは完璧な中間点を見つけてそこに留まることはありません。代わりに、悪党を捕まえることと、誤検知でセキュリティチームを煩わせないことのバランスを取ろうとして、絶えず振動し続けているのです。

3. どのように変化を研究したか

研究者たちは、ルールの変化を理解するために、単にテキストを見るだけでは不十分だと考えました。なぜなら、セキュリティの専門家は同じロジックを異なる表現方法で書き直すことがあるからです（例：文章をよりフォーマルな響きにするなど）。

そこで彼らは、**「述語グラフ（Predicate Graph）」**と呼ばれる特別なツールを考案しました。

• 比喩： 複雑な文章を、家系図のような図に変換することを想像してください。
  • 「AND（かつ）」や「OR（または）」という言葉が「枝」になります。
  • 「赤い帽子」や「青いバッグ」といった具体的な詳細は「葉」になります。
• これらの「木」を比較することで、テキストの乱れを無視して、ルールの「構造」を見ることができました。これにより、ルールがいつ新しい枝を追加したか、いつ葉を取り除いたか、あるいは構造全体を組み替えたかを正確に把握することが可能になりました。

4. 変化の背後にある「理由」

研究者たちは、AI（大規模言語モデル）を使用して、変更内容を読み取り、専門家がなぜその変更を行ったのかを推測させました。ルールが変わる主な理由は以下の3つです。

• 「綱引き」（振動）： 時には、チームが「より多くの人を捕まえること」と「誤検知を減らすこと」の間で決断を下せずにいます。あるバージョンを試し、その結果に不満を持ち、別のバージョンに切り替え、またその結果に不満を持ち、また元に戻す……という状態です。これは、温度が変動し続けるシャワーの最適な温度を探しているようなものです。
• 「セット販売」（結合された変更）： 何か新しいものを捕まえるために追加すると、何か別のものを除外することが「強制」される場合があります。
  • 例： 新しいタイプのウイルスを捕まえようと決定すると、偶然、似たような挙動をする無害なプログラムまで捕まえてしまうかもしれません。そのため、その無害なプログラムを除外するためのルールを、全く同時に追加しなければなりません。片方にはもう片方が不可欠なのです。
• 「翻訳ミス」（証拠不足）： 時には、監視しているコンピュータシステム側の言語が変わったために、ルールが変わることがあります（例：フィールド名が "user_name" から "username" に変わった場合）。ルール自体は機能していますが、テキストだけでは、それがより多くの人を捕まえているのか、あるいは減らしているのかを判断できません。これは、本の言語が変わったようなものです。ストーリーは同じですが、使われている言葉が異なります。

5. 大きな教訓

この論文の主要な結論は、セキュリティルールは静的な設計図ではなく、生きている、呼吸しているものであるということです。

ルールは、完璧で安定した形へと進化していくのではありません。むしろ、それらはセキュリティチームの継続的な葛藤を反映しています。彼らは常に、以下のトレードオフの間でバランスを取ろうと苦闘しています：

1. 悪党を見逃さないこと。
2. 誤検知によって周囲を煩わせないこと。

論文は、これらのルールは非常に複雑で絶えず変化しているため、セキュリティチームを支援するより優れたツールが必要であると主張しています。私たちは、単なるテキストではなく、ルールの「ロジック」を理解するシステムや、毎回ルール全体を書き直すことなく、難しいトレードオフを行うのを助けてくれるツールを必要としています。

要するに、セキュリティルールを書くことは、ラジオのチューニングをするようなものです。最もクリアな信号を見つけようとダイヤルを何度も左右に回し続けますが、放送局自体が少しずつズレていくため、常に調整し続けなければならないのです。