技術概要：セキュリティログのパーサ不要なクエリ処理

問題定義

セキュリティアナリストは、脅威の検出やインシデント調査のためにシステムログを日常的にクエリ処理しますが、ログ形式の多様性が重大なボトルネックとなっています。ログは生成コストは低いものの、利用コストは高いです。なぜなら、各ソース（ファイアウォール、認証サービス、エンドポイントエージェント）がそれぞれ独自の準構造化形式を使用しているからです。

業界標準のアプローチは、分析前にログを構造化スキーマ（例：OCSF）に正規化するために、ソースごとのパーサを構築することです。これは強力な手法ですが、形式が変化するにつれてパーサを維持するための継続的なエンジニアリング努力を必要とします。例えば、Google SecOps は約 1,000 個のアクティブなパーサを維持しており、月間 200 回以上の更新が行われています。一方、パーシングを省略し、grep やその場限りのスクリプトなどのツールで生ファイルを直接検索するアプローチは、維持コストを回避しますが、負担をアナリストに転嫁します。この手動アプローチは、特定のメッセージバリエーションに関する深い知識を必要とし、状態管理、グループ化、集約を必要とする複雑な複数行の時間的クエリ（例：「60 秒以内に 2 つの異なる IP アドレスからログインしたユーザーを検出」）を表現するのが困難です。

どちらのアプローチも、同じ理由で失敗します。つまり、ソースログの構文と意味論に関する事前知識を必要とする点です。構造化パイプラインはこれをパーサにエンコードしますが、生テキストワークフローではアナリストが手動でこれを再構築する必要があります。

手法：Sieve システム

著者は、事前構築されたパーサや正規化されたスキーマを必要とせず、自然言語のセキュリティ質問から実行可能なクエリコードを生成するシステム「Sieve」を提案します。Sieve は、軽量で自動的に抽出されたログ形式のコンテキストを用いて大規模言語モデル（LLM）をグラウンディング（実世界に接続）することで動作します。

パイプラインの概要

Sieve は 4 つの段階で動作します。

1. プロンプト構築: システムは、自然言語クエリ、ログファイルのパス、および「コンテキスト戦略」（ログテンプレートの例または生行）を含むプロンプトを組み立てます。また、制約（例：コードは Python または Bash で、ネットワーク/ファイルへの書き込みは禁止）と出力仕様も含まれます。
2. コード生成: LLM（主に Gemini 3.1 Pro Preview または OpenAI GPT-5.4）がクエリごとに 1 回呼び出され、自己完結型の Python または Bash スクリプトを出力します。モデルは、確実な抽出を確保するためにコードを JSON ラッパーで返すよう指示されます。
3. サンドボックス実行: 生成されたコードは、ネットワークアクセスなしでファイルシステム権限が制限されたサブプロセスで実行されます。eval、exec、rm などの拒否を含む安全性チェックと、出力形式の検証の対象となります。
4. リトライ機構: 実行が失敗した場合、スクリプトが例外を投げた場合、または出力形式が違反された場合、エラーメッセージが LLM にフィードバックされ、リトライが行われます。最大 4 回までリトライが許可されます。

コンテキスト戦略

LLM を特定のログ形式にグラウンディングするために、Sieve は 5 つの戦略を評価してコンテキストを提供します。

• マトリョーシカテンプレート: オフラインの LLM パイプラインを使用して、名前付きフィールドプレースホルダーを持つ高品質な意味テンプレートを生成します。
• Drain3: 単一パスで汎用ワイルドカード付きのテンプレートを抽出するストリーミングパーサです。
• 頻度ベースのテンプレートジェネレーター: IPLoM に着想を得た軽量ヒューリスティックアルゴリズムで、トークンを正規化し、長さでグループ化し、変数位置を特定して、LLM 呼び出しなしで 10 秒未満でテンプレートを生成します。
• ランダムサンプル: 明示的なテンプレートなしで、100 行のランダムにサンプリングされたログ行を提供します。
• コンテキストなし: 単一のサンプル行のみを提供し、モデルの事前学習済み知識に依存します。

このシステムは LLM をコンパイラとして扱います。抽出ロジックを 1 回生成し、結果として得られるスクリプトが、ログ全体に対して通常のプログラム速度で決定的に実行されます。

主要な貢献

1. Sieve パイプライン: 自然言語から実行可能なコードを生成し、クエリごとに 1 回の LLM 呼び出しの後に決定的な実行のみを必要とする、生セキュリティログの LLM 支援クエリ処理のためのオープンソースシステム。
2. ベンチマーク: 5 種類のログ形式（Linux Audit、SSH、cron、Puppet、DHCP）にわたる 133 のセキュリティクエリからなる新しいベンチマーク。クエリは単純なフィルタ（クラス 1–2）から、時間ウィンドウと状態を伴う集約を含む複雑な複数行の相関（クラス 3–4）まで多岐にわたります。すべてのクエリに対して正解が提供されています。
3. 設計空間の探索: ログクエリの最適な構成を決定するための、コンテキスト戦略、実行言語（Python vs Bash）、モデルファミリーの評価。
4. ベースライン比較: 人間ベースライン（10 分未満で単純な grep/Python スクリプトを作成するアナリスト）および自動化された構造化パーシングパイプライン（マトリョーシカ）との比較。

実験結果

評価は、5 種類のログ形式にわたる 133 のクエリに対して実施されました。

• 人間ベースラインとの性能比較: Sieve は単純なフィルタクエリでは人間の性能と同等ですが、複雑なクエリでは手動スクリプト作成を大幅に上回ります。複雑な作業負荷（ブルートフォース検出、セッション異常の特定、クロスイベント相関）において、Sieve は平均誤り率を0.34（人間）から0.10に削減し、約3.6 倍の削減を実現しました。最大の改善は、タイムスタンプの解析、共有識別子によるイベントの結合、およびローリングウィンドウ状態の維持を必要とするタスクで観察されました。
• 構造化パーシングとの性能比較: 単純なフィルタリング作業負荷において、Sieve（軽量な Drain3 コンテキストを使用）はマクロ F1 スコア0.981を達成し、マトリョーシカ構造化パーシングパイプライン（0.999）のノイズ範囲内に収まりました。これは、オフラインのパーサ生成ステップなしで、LLM 生成コードが完全にパースされた表現の精度に近づけることを示しています。
• コンテキスト戦略: テンプレートソースの選択は予想ほど重要ではありませんでした。LLM 呼び出しなしで数秒で実行される単純な頻度ベースのテンプレートジェネレーターは、高コストのマトリョーシカテンプレートと統計的に区別できない結果を生み出しました。重要な要因はテンプレート表現の洗練さではなく、メッセージバリエーションのカバレッジです。
• 言語選択: Python は複雑なクエリのデフォルトとして優れています。Bash は単純なフィルタでは同等の性能を発揮しますが、データ構造やタイムスタンプ算術の処理における制限により、状態を伴う時間的クエリ（例：DHCP の複雑なクエリでは、Python の 0.815 F1 から Bash の 0.446 へ低下）では大幅に失敗します。
• モデルの堅牢性: パイプラインはモデルファミリー間（Gemini 3.1 Pro と GPT-5.4）で転送可能ですが、この特定の構成では GPT-5.4 が複雑な状態を伴うタスクで低い性能を示しました。

意義と主張

本論文は、Sieve が構造化ログクエリの表現力と、生ファイルで直接作業する即時性の間のギャップを埋めると主張しています。その主な意義は、LLM 生成コードが継続的なパーサ維持の必要性を排除しつつ、構造化分析の精度を維持するジャストインタイムクエリプランとして機能しうることを実証している点にあります。

著者は、Sieve が SIEM の正規化スキーマの範囲外にあるアナリストクエリの「ロングテール」や、パーサ構築を許容しない時間的圧力下でのその場限りの調査において特に価値があると論じています。継続的なエンジニアリング（パーサの維持）からのコストを、限定されたクエリごとのコスト（1 回の LLM 呼び出し＋決定的実行）へ転換することで、Sieve は「まず正規化し、後でクエリする」というアーキテクチャに対するスケーラブルな代替案を提供します。結果は、複雑なセキュリティ調査において、十分なログ形式コンテキストでグラウンディングされていれば、自動化されたコード生成が手動スクリプト作成よりも実行可能であるだけでなく、優れていることを示唆しています。