論文「From IOCs to Regex: Automating CTI Operationalization for SOC with LLMs」の技術的サマリー

本論文は、サイバー脅威インテリジェンス（CTI）レポートから抽出された「侵害の指標（IOCs）」を、セキュリティオペレーションセンター（SOC）で実際に運用可能な「正規表現（Regex）」へ自動的に変換するシステムIOCRegex-genを提案するものです。大規模言語モデル（LLM）を活用しつつ、セキュリティ特有の課題を克服するための革新的なアプローチを提示しています。

以下に、問題定義、手法、主要な貢献、評価結果、そして意義について詳細をまとめます。

1. 問題定義 (Problem)

現代の SOC では、CTI レポートから得られる IOCs（ファイルパス、レジストリキー、コマンドライン引数など）を基に、ログデータから攻撃痕跡を検出するための正規表現を手動で作成しています。しかし、このプロセスには以下の重大な課題があります。

• 手動プロセスの非効率性とスケーラビリティの欠如: CTI レポートの増加に伴い、アナリストが手動で IOCs を抽出し、それを正規表現に変換する作業は時間がかかり、ボトルネックとなっています。
• 文脈のギャップ: CTI レポートに記載された IOCs は特定の環境（OS バージョン、パス区切り文字、大文字小文字など）に依存しており、そのままでは異なるシステム環境のログにマッチしません。正規表現はこれらの変異を吸収するために必要ですが、手動での作成は誤りやすく、専門知識を要します。
• 既存の自動化手法の限界: 近年、LLM を用いた IOC 抽出の研究は進んでいますが、抽出された IOCs を「生文字列」のまま出力するにとどまり、「運用可能な正規表現」への自動変換という最終ステップが未解決です。また、既存の LLM による正規表現生成は、構文エラー、意味の不一致、あるいは検出能力を失うほど広範すぎる（Over-generalized）パターンを生成する傾向があります。
• キャプチャグループの識別難易度: 正規表現において、どの部分を「キャプチャグループ（抽出すべき固定部分）」とし、どの部分を「非キャプチャグループ（変化する部分）」とするかの判断は、OS の構造や攻撃者の手口に関する深いドメイン知識を必要とし、LLM 単体では困難です。

2. 手法 (Methodology)

提案システム IOCRegex-gen は、抽出された IOC を入力として受け取り、構文が正しく、意味的に正確な正規表現を生成する 2 つの主要フェーズから構成されます。

2.1. キャプチャグループの特定 (Capture Group Finding)

このフェーズでは、IOC 文字列内のどの部分が「固定（キャプチャ）」され、どの部分が「可変（非キャプチャ）」かを自動的に判断します。

• 知識強化型グラフデータベース: Windows の標準ファイルパス、レジストリキー、コマンドライン引数の階層構造を Neo4j グラフデータベースに格納しています。
• アルゴリズムによる識別:
  • ファイルパス/レジストリキー: 入力文字列をスラッシュで分割し、グラフデータベース上の隣接ノードを探索します。OS 標準のディレクトリ構造（例: C:\Users\Public）に一致する最長の連続したサブストリングを「キャプチャグループ」として特定し、攻撃者によって変更されやすい部分（例: ファイル名 11.bat）を除外します。
  • コマンドライン引数: コマンド（例: schtasks）とそのパラメータ（例: /create, /tn）の階層関係をグラフで定義し、標準的なコマンドとパラメータをキャプチャグループとして抽出します。
• 誤検知フィルタリング: キャプチャグループを含まない IOC は、抽出段階の誤り（False Positive）として除外されます。

2.2. 推論ベースの正規表現生成 (Reasoning-based Regex Generation)

LLM を用いて正規表現を生成し、多段階の検証ループを通じて品質を担保します。

1. 初期生成: IOC とキャプチャグループの情報を LLM に提示し、初期の正規表現を生成させます。
2. デバッグループ: 生成された正規表現が元の IOC にマッチするか検証します。マッチしない場合、デバッガが失敗箇所を特定し、その情報を LLM にフィードバックして修正を繰り返します。
3. 非キャプチャグループ検証: 意図しない非キャプチャグループが含まれていないか確認し、あれば修正を促します。
4. 過剰一般化チェック: 生成された正規表現が .* などのワイルドカードに依存しすぎて、無意味に広範なマッチングを行わないか、ランダムに生成された 10 文字列でテストします。過剰に一般的な場合は生成をやり直します。
5. スコアリングと選定: 複数の候補を生成し、以下のスコアリング式で評価して最適なものを選択します。
   • Score = α * (キャプチャグループ数) - β * (非キャプチャグループ数)
   • 必要以上に広範なマッチングを防ぐため、非キャプチャグループにはペナルティを課します。

3. 主要な貢献 (Key Contributions)

1. IOCRegex-gen の提案: CTI 運用ワークフローにおける「IOC 抽出」から「検出ルール作成」までの重要な欠落ステップを埋める、完全自動化された LLM ベースのシステムを初めて提案しました。
2. 新しい技術的アプローチ:
   • 知識強化型キャプチャグループ識別: グラフデータベースと OS 構造の知識を用いて、LLM 単体では困難な「固定部分」と「可変部分」の区別を自動化しました。
   • 反復推論と多段階検証: 構文の正当性、意味の正確性、一般化のバランスを保つための反復的な検証パイプラインを設計し、LLM の幻覚（ハルシネーション）や誤った一般化を抑制しました。
3. 大規模な実証評価: MITRE ATT&CK Evaluation フレームワークから収集した 3,000 件以上の実世界の CTI レポートと、2,400 件以上のグラウンドトゥルース（実際の攻撃ログ）を用いた包括的な評価を行いました。

4. 評価結果 (Results)

実験は、MITRE ATT&CK Evaluation で収集された 10 の攻撃シナリオ（LockBit, APT29 など）における 2,400 件以上のグラウンドトゥルース文字列に対して行われました。

• 検出率 (Hit Rate): 生成された正規表現は、グラウンドトゥルース文字列に対して**平均 99.1%**のヒット率を達成しました。一部のデータセットでは 100% を記録しています。
• 偽陽性率 (False Positive Rate): 平均**0.8%**と非常に低く抑えられています。
• 複雑性と一般化:
  • 生成された正規表現のスコア（構造的複雑さ）は平均 3 点以上であり、単純な文字列一致ではなく、適切なキャプチャグループを含む複雑なパターンであることが示されました。
  • 元の IOC との類似度は平均 0.4 程度であり、元の IOC の特徴を保持しつつ、環境変異に対応できる十分な柔軟性を持っていることが確認されました。
• アブレーション研究:
  • キャプチャグループ特定機能や推論ベースの生成プロセスを無効化した場合、ヒット率は 16.7% 以上低下し、偽陽性率は 23.3% 以上増加しました。これにより、各コンポーネントがシステム性能に不可欠であることが証明されました。
• モデル間の一貫性: GPT-4o, LLaMA3, DeepSeek-V3 といった異なる基盤モデルを使用しても、生成される正規表現の構造的類似性は非常に高く（0.97 以上）、システムがモデルに依存しない安定した出力を提供することが示されました。

5. 意義と結論 (Significance)

本論文は、CTI の実用化における最大のボトルネックである「手動の正規表現作成」を自動化する画期的な解決策を提供しています。

• SOC 運用の効率化: アナリストの負担を大幅に軽減し、脅威への対応時間を短縮します。
• 高精度な検出: 単なる IOC 抽出を超え、実際の攻撃ログの変異を捉えるための文脈を理解した正規表現を生成することで、検出精度を向上させます。
• セキュリティ AI の新たな方向性: 一般的な NLP タスクではなく、セキュリティ特有の「敵対的変異」や「ドメイン知識の必要性」を考慮した LLM の活用方法を確立しました。

結論として、IOCRegex-gen は、CTI レポートから即座に実行可能な検出ルールを生成する実用的なシステムであり、大規模な CTI 処理と自動化された脅威検出の実現に大きく寄与します。