サイバー脅威インテリジェンスを計算可能な検出パターンに変換するための構造化されたワークフロー

サマリー

ここでは、サイバー脅威インテリジェンスレポートのファイルパス、レジストリキー、コマンドラインインジケーターから、セキュリティ情報およびイベント管理(SIEM)検出ルールの検証済み正規表現に変換するプロトコルを紹介します。これは、大規模言語モデル(LLM)を用いたアンサンブル抽出とグラフ支援コンポーネントラベリングを用いてです。

要約

セキュリティオペレーションセンター(SOC)は、サイバー脅威インテリジェンス(CTI)レポートを運用検知コンテンツに変換するのを日常的に行っています。このワークフローにおける持続的なボトルネックは、抽出された侵害インジケーター(IOC)、特にファイルパス、レジストリキー、コマンドライン文字列を、セキュリティ情報およびイベント管理(SIEM)相関ルールに埋め込むのに適した展開可能な正規表現(regexe)に変換することです。従来の研究では自動インジケーター・オブ・コンフェーディング(IOC)抽出が向上していますが、抽出された文字列を検証済み正則表現パターンに変換するのは主に手作業であり、専門的な専門知識を要し、誤りも起こりやすいです。このプロトコルの目的は、IOCから正規表現への変換のための標準化され再現可能な手順を提供することです。ワークフローは5つの段階で構成されています:(1) 異種なCTIレポートを統一されたMarkdown表現に解析すること;(2) 複数の大規模言語モデル(LLM)を用いた合意投票を用いたIOC抽出;(3) 抽出されたIOCのルールベースの正規化、分類、重複除去;(4) IOCコンポーネントのグラフ支援によるラベリング(keep-group)またはdiscard(非-キャプチャ-グループ);(5) 元のIOC文字列に対する診断検証を伴う反復正則式生成。有用性を評価するために、ワークフローは3,156件のCTIレポートに適用され、得られた正則表現は10のMITRE対抗戦術、技術、常識(ATT&CK)評価シナリオから独立に収集された2,400以上のグラウンドトゥルース文字列と比較され、平均ヒット率99.1%、クロスIOCミスマッチ率0.8%を得ました。したがって、プロトコルはIOCから正則表現への変換の再現可能な実装を文書化し、その現在の範囲、運用上の前提、既知の失敗事例を明示的に示しています。

概要

サイバー犯罪は、公共・民間セクターの組織に依然として大きな運営的・財政的負担を課しています。2023年には、米国におけるサイバー犯罪による損失が125億ドルを超え、悪意のある活動の規模と持続性を浮き彫りにしました。この状況の中で、セキュリティオペレーションセンター(SOC)は、リアルタイムで脅威を検出、分析、対応する主要な運用ユニットとして機能します。
多くのSOCワークフローにおける検出ロジックは、セキュリティ情報・イベント管理(SIEM)プラットフォーム内のルールベースのメカニズムを通じて実装されており、これらは解釈可能で決定的であり、既存のSOCワークフローと互換性があるため広く利用されています。さまざまなルールタイプの中で、相関に基づくSIEMルールは、複数のイベント、ホスト、タイムウィンドウにまたがる攻撃行動を特定する上で特に重要です。これらのルールの中で、正則表現(正則表現)は再利用可能な検索プリミティブとして機能します。分析者は、自己完結型検出器として展開するのではなく、フィールド制約、プラットフォーム固有のフィルター、イベント相関ロジックを追加する広範な検出ルールに組み込むことができます。

実際には、SOCアナリストはセキュリティベンダー、独立研究者、またはMITRE Adversarial Tactics, Techniques, and Common Knowledge(ATT&^{CK)のような}公開知識ベースが公開したサイバー脅威インテリジェンス(CTI)レポートから派生したインジケーターオブコンブレインテリジェンス(IOC)からルール開発を始めることが多いです。これらのIOC文字列には、ファイルパス、コマンドラインの断片、レジストリキー、または攻撃時に観察されたその他の構造化アーティファクトが含まれ^{る可能性があります。}これらの文字列をSIEM相関ルールに適した正則表現パターンに変換することは、ルール作成のワークフローで繰り返し行われる作業です。

この翻訳ステップは実用的な運用上のボトルネックとなっています。意味のある変化を捉えつつ、意図しないマッチを避けるために精密な正則表現パターンを作成するには専門的な専門知識が必要です。小さな構文ミスや、どの成分を保持するか一般化するかの誤った判断が、有用な検出ルールを無効化することがあります。この作業は手動で繰り返し、細部にこだわるため、新たな脅威の検知展開を遅らせたり、経験豊富なアナリストによるレビューが必要となり、運用SOC^設定4,5におけるアナリストの業務負担が増える可能性があります。

IOCから正則式への変換における中心的な課題は、IOCのどの部分が安定的で攻撃者に関連する動作をエンコードし、したがって保持すべきか、またどの部分が環境やホスト固有の変動を反映し一般化すべきかを判断することです。例えば、HKEY_CLASSES_ROOT\CLSIDのような標準的なレジストリルート、System32のようなシステムディレクトリ、rundll32.exeのような既知の実行ファイル名は通常明示的に設定する必要がありますが、ユーザープロファイルパス、ホスト固有のセキュリティ識別子(SID)、グローバル一意識別子(GUID)は通常抽象化されるべきです。異種なIOC型間でこれを一貫して行うことが、翻訳タスクを非自明なものにしています。このプロトコル全体では、前者は保存群または捕獲群成分、後者は抽象的または非捕獲群成分と呼んでいます。

これまでの研究では、自然言語処理およびエンティティ^{抽出技術を}用いて非構造化テキストから脅威インテリジェンスを自動的に抽出する方法が探求^{されています。}近年では、大規模言語モデル(LLM^)を用いてCTIレポートから検出ルールを直接生成する方法を調査する研究もいくつか行われています。これらのアプローチは、ルール作成ワークフローの一部が言語モデルによって支援できることを示していますが、キャプチャグループの意味を保持し、下流のSIEM展開に適した正則表現パターンを生成するという特定の運用課題には通常焦点を当てていません。補完的な研究分野では、TINKER⁹のような知識グラフベースの表現や、非構造化CTIをSIEM相関ルールに埋め込むのではなく、構造化知識やドメイン固有のクエリ言語に変換するThreatRaptor¹⁰のようなCTI駆動のログハンティングクエリを生成する方法があります。

並行して、例に基づく手法、ニューラル翻訳、生成・修復手法(11,12,13,14,15,16)を用いた自動正則表現合成の研究も行われています。しかし、これらの手法は一般的に、IOC駆動の検出文脈ではなく、代表的な例や自然言語の記述を大量に依存する環境向けに設計されています。SOCワークフローでは、IOC文字列はしばしばスパースで構造的に異種であり、運用セマンティクスと密接に結びついています。この不一致は、既存の正則表現生成手法が広く不十分だという主張ではなく、IOCから正則表現への変換に特化したワークフローを動機付けています。

ここで提示されるプロトコルは、特にSOC検出ワークフローのIOCから正則への変換段階に焦点を当てています。IOC抽出は、手動解析、自動化ツール、またはその両方の組み合わせから来る上流の入力として扱われます。プロトコルは完全なSIEMルールを生成しようとはしません。代わりに、IOC文字列を構文的に妥当で意味的に解釈可能で、運用展開に適した正則表現パターンに変換する体系的な手順を提供します。現在のIOCスコープは意図的です。ファイルパス、レジストリキー、コマンドラインインジケーターには安定構造コンポーネントと可変構造コンポーネントの両方が含まれており、正則表現の一般化が恩恵を受けます。一方、IPアドレス、ドメイン、ハッシュなどの原子インジケーターは、正確なマッチ条件や評判スタイルの検索によってより自然に操作されるため、プライマリスコープの外に位置します。これらの枠内で、プロトコルは入力フォーマットやツールの前提条件を共有するSOC環境間で移植可能であることを意図しています。

プロトコル

以下の5段階ワークフローを使って、CTIレポートを検証済みの正則表現パターンと追跡可能な中間出力に変換します(概要は 図1 参照)。

1. システム設定

1. 前提条件を設置しましょう。
   1. Python 3.8以降をインストールし、requirements.txtに記載されているすべてのPython依存関係、そしてNeo4jグラフデータベースをインストールしてください。
      1. 選択した大規模言語モデルに対して1つ以上のアプリケーションプログラミングインターフェース(API)へのアクセスを確認し、Neo4jサービスがローカルマシンから実行可能であることを確認します。
   2. 材料表が完成しているか確認してください。
      1. Pythonインタプリタバージョン、パイプライン依存関係、Neo4jバージョン、ポータブルドキュメントフォーマット(PDF)テキスト抽出バックエンドなど、ランタイム依存関係が一覧化されているか確認してください。
      2. LLMの設定オプションがリストされているか、例えばLLMプロバイダー、モデル名やバージョン、温度、推論努力オプション、アンサンブル投票設定などを確認してください。
      3. 入力および出力フォーマットが一覧化されているか、サポートされる入力ファイル形式やサポートされるエクスポート形式が含まれているか確認してください。
2. ウェブユーザーインターフェース(UI)を起動します。
   1. ターミナルを開き、参照実装のルートディレクトリに移動し、ドキュメント化された起動コマンド(参照実装ではcd langchain_pipeline、続いてstreamlit run app_v2.py)を使ってアプリケーションを起動します。
   2. アプリケーションが http://localhost:8501 で読み込まれ、サイドバーの設定パネルが見えるか確認してください。
3. LLMプロバイダーを設定してください。
   1. サイドバーのLLM構成セクションでLLMプロバイダーを選択し、モデル名を入力し、有効なアプリケーションプログラミングインターフェース(API)キーを入力します。
   2. 提供者、モデル名、モデルバージョン、温度、推論・労力オプション、および材料テーブルへのアクセス日を記録します。
      注意。リファレンス実装では、単一LLMのIOC抽出は、Materials Tableに記載された主要な商用LLMをデフォルトで使用し、温度=0.0となります。正則表現生成は温度=0.3にデフォルトです。
4. アンサンブル投票を有効にしてください(任意ですが、結果の再現性のために推奨されます)。
   1. サイドバーのアンサンブル投票オプションを有効にし、最低投票数(最低投票数≥2票推奨)を満たすIOCのみを保持できるようにしてください。
   2. プロバイダー名、モデル名、APIキー、モデルごとの実行回数を指定することで、追加のLLMインスタンスを追加できます。
      1. 各提供者の繰り返し回数と選択した最低投票閾値を記録します。
         注意。 アンサンブル投票は任意です。無効化すると、パイプラインは単一LLM抽出を行い、コンセンサスフィルターはスキップされます。デフォルトのアンサンブル設定は、設定モデルごとに繰り返し=1回、min_votes=2回です。
5. Neo4jに接続してください。
   1. サイドバーのNeo4j Connectionセクションで、接続番号URI(例:bolt://localhost:7687)、ユーザー名、パスワードを入力します。
   2. インターフェースが接続成功を報告しているか確認してください。アクティブな接続なしで進まないでください。
6. すべての認証情報を安全にしてください。
   1. LLMのAPIキーとNeo4jのパスワードは機密の認証情報として扱いましょう。ソースファイルやエクスポート済みレポート、スクリーンショットではなく、環境変数やシークレットマネージャに保存し、漏れが疑われた場合はキーを迅速に回転させてください。
      注意。 このソフトウェアプロトコルは、化学換気フード、バイオセーフティキャビネット、その他の物理的封じ込め装置を必要としません。機密のCTIレポートや認証情報を、機関のデータセキュリティポリシーに従って取り扱います。

2. ステージ1:文書解析

1. 手続き。
   1. メインインターフェースの「処理」タブに移動します。
   2. 対応形式(.pdf、.docx、.md、.txt、または.html)でCTIレポートをアップロードしてください。
   3. 「次の段階を実行」をクリックするとステージ1を実行、「すべての段階を実行」をクリックするとパイプライン全体を順番に実行できます。
2. ステージ1のチェックポイントを確認しろ。
   1. 入力文書のMarkdownプレビューが表示されているか確認してください。
   2. プレビューでファイルパス、レジストリキー、コマンドラインの断片、セクション境界がそのまま残っているか確認してください。
   3. 技術的な文字列が切断されたりフォーマットが省略された場合は、ソースファイルを修正するか、外部コンバーターで事前処理してから再アップロードしてください。

3. 第2段階:IOC抽出

1. 手続き。
   1. LLMの設定(およびアンサンブル投票が有効なら)を確認しましょう。
   2. 「次のステージを実行」をクリックしてステージ2を実行してください。
2. ステージ2のチェックポイントを確認しろ。
   1. インターフェースがJavaScriptオブジェクト表記(JSON)形式でIOCコレクションを表示し、最上位キーはファイルパス、コマンドライン、レジストリキーの3つで表示されます。
   2. アンサンブル投票が有効になった場合、各保留IOCごとに投票数と寄与モデルのメタデータが記録されているか確認してください。
      注意。 逐語的なステージ2システムと人間のプロンプト、そしてステージ5の生成および最適化プロンプトは補 足ファイル1 (Supplemental_File_1_Prompts.txt)として公開されます。

4. 第3段階:IOC解析と分類

1. 手続き。
   1. 「次のステージを実行」をクリックしてステージ3を実行してください。
2. ステージ3のチェックポイントを確認しろ。
   1. 各保持されたIOCが標準化されたカテゴリ、ソースタグ、利用可能な場合は元の抽出キーでリストされているか確認してください。

5. 第4段階:Neo4j補助IOC正規化

1. 手続き。
   1. Neo4j接続が有効かどうか確認してください。
   2. 「次のステージを実行」をクリックしてステージ4を実行してください。
   3. パー・IOC正規化出力を確認し、パスおよびコマンドラインコンポーネントのキープ/ディスドロップラベルが生成されていること、レジストリキーが連続した標準的サブストリングを生成するかを確認しましょう。
2. ステージ4のチェックポイントを確認しろ。
   1. 各IOCタイプ(ファイルパス、レジストリキー、コマンドラインインジケーター)ごとに正規化されたIOCテーブルが作成されていることを確認しましょう。
   2. 各エントリに元の値、正規化値、そして保持または破棄とラベル付けされた要素/ステータスペアのコンポーネントリストが含まれているか確認してください。
      注意。 詳細なNeo4jスキーマ、暗号クエリ、決定ルール、レジストリキー正規化手順は 補足ファイル2に記載されています。作業例は代表結果に掲載されています。

6. ステージ5:正規表現生成とスコアリング

1. 手続き。
   1. 「次のステージを実行」をクリックしてステージ5を実行してください。各正規化されたIOCとその禁止トークンリストが正則表現生成および決定論的検証のために提出されていることを確認しましょう。
   2. 候補が検証に失敗した場合は、準拠候補が生成されるか反復上限に達するまで、最適化ループが正規表現を精緻化するのを待ちます。
   3. 最終的な正則表現が準拠から最高得点の部分一致(used_fallback = Trueとして記録)にフォールバックしたIOCの診断出力、最適化履歴、反復数を調べます。
2. ステージ5のチェックポイントを確認しろ。
   1. 各保持されたIOCごとに最終的な正則表現が作成されていることを確認しましょう。
   2. 候補スコア、最適化履歴、問題リスト、反復回数が記録されているか確認してください。
   3. 推定トークン使用量やレイテンシを含む各IOCテレメトリーが記録されているか確認してください。
      注意。 詳細な正則表現検証ルール、スコアリング式、反復制御パラメータは 補足ファイル2に記載されています。

7. 分析と検証

1. Analyticsタブを開き、IOC分布、アンサンブル投票結果(有効時)、正則表現品質の要約、最適化統計を確認できます。これらの要約を使って、抽出の不均衡や繰り返しの最適化失敗などの異常を検出してください。

8. 輸出結果

1. エクスポートタブでエクスポート形式(プレーンテキスト、JSON、またはYAML)を選択し、正則表現セットをダウンロードします。エクスポートされた正則表現に関連するスコアや分類メタデータが含まれているか確認してください。
2. 解析済み文書、抽出されたIOC、正規化表現、候補正則表現、最終出力を含む完全なJSONレポートを作成・ダウンロードできます。このレポートは再現性記録として保存してください。

9. トラブルシューティング

1. ステージ1で切り詰められたり空になったPDFコンテンツが返された場合は、外部コンバーターや光学文字認識ツールで文書を事前処理し、再アップロード前に技術的なアーティファクトがマークダウンプレビューに残っているか確認してください。
2. ステージ2でコンセンサスIOCが少なすぎる場合は、閾値を変更する前にプロバイダー、モデル、APIキー、リピートカウント、最小投票設定を確認してください。幻覚と過度に厳格な投票を区別するために排除された候補者を検査しました。
3. ステージ4ですべてのコンポーネントが破棄としてラベル付けされている場合、Neo4jの接続性を確認し、分析対象のIOCタイプに関連するパス、レジストリ、またはコマンドラインインターフェース(CLI)語彙がグラフに含まれていることを確認します。
4. ステージ5でコンパイルはできるがマッチングに失敗したり過度に一般化された場合は、最適化履歴、診断失敗位置、過剰一般化チェックを検査してから候補を再生成してください。

10. 最終プロトコル出力を確認する。

1. 解析されたMarkdownファイル、IOCセット(アンサンブル投票が有効時はコンセンサス検証、無効化時はシングルモデル)、分類されたIOCテーブル、グラフ正規化されたIOC表現がすべて揃っているか確認してください。
2. SIEM互換の正則表現セット、分析サマリー、完全なJSONレポートがすべて揃っているか確認し、JSONレポートを再現性レコードとしてアーカイブしてください。

結果

このセクションでは、IOCから正則表現へのプロトコルによって生み出された代表的な成果を提示し、その運用適用性を評価するために用いられた参照評価を要約します。リファレンス評価では、MITRE ATT&CK技術に関連する3,156件のCTIレポートを処理し、23万文以上を解析し、6万3,000以上のIOC候補を抽出し、10のMITRE ATT&CK評価シナリオから独立して収集された2,400以上のグラウンドトゥルース文字列に対して生成された正述式を評価しました。これらのグラウンドトゥルースストリングは、MITRE AT&CK評価演習中にサイバーセキュリティベンダーが独立して報告した専門家が厳選した攻撃成果物であり、人間のアナリストやベンダーが実際に記録する構造的パターンを反映しています。以下の結果は、運用ログ分析および検出ワークフローに関連するワークフローの挙動、構造的正しさ、評価結果に焦点を当てています。

エンドツーエンドパイプラインの概要は 図1に示されて...

ディスカッション

非構造化CTIレポートを実行可能な検出ロジックに変換することは、運用上のセキュリティワークフローにおいて依然として時間がかかりエラーが多い作業です。これまでの取り組みでは、IOC抽出や高レベルルール生成レベルでの自動化が探求されてきましたが、実務者は抽出したIOC文字列を構造的に正確で意味的に正確、かつ下流SIEM用途に適した正則表現に変換する上で依然として大きな課題に直面しています。ここで提示されるプロトコルは、各フェーズが明確に定義された中間アーティファクトを生成し、結果を次の段階に渡す前に明示的な検証を行う段階的なワークフローを通じてそのギャップを埋めています。 図14 は、デファング化され、白空間が乱れたファイルパスを特定し、修正し、正規化し、コンパイル用の正則表現に変換するケースを示しています。プロトコルのノイズ入力処理と現在の範囲については、以下に列挙する制限事項と一つにまとめて論じます。

このプロトコルの中心的な貢献の一つは、ワークフローを段...

材料

この記事で使用された材料の一覧

名前	会社	カタログ番号	コメント
コンピューター (CPU)	—	≥ 4 コア推奨	GPU 不要
LangChain	LangChain	≥ 0.1.x	LLM オーケストレーションフレームワーク
LLM (IOC 抽出、単一モデル)	OpenAI	gpt-5.1	アンサンブル投票が無効の場合、IOC 抽出 (ステージ 2) に使用されます。温度 = 0.0; 最大ワーカー = 5。アクセス日: 2025 年 12 月 15 日。
LLM (正規表現生成)	OpenAI	gpt-5.1	正規表現生成 (ステージ 5) に使用されます。下流検証前温度 = 0.3。アクセス日: 2025 年 12 月 15 日。
LLM (スケーラビリティ特性評価)	OpenAI	gpt-5.1	代表的な結果で報告された 6,000 IOC のスケーラビリティ実行に使用されます。アクセス日: 2025 年 12 月 15 日。
メモリー (RAM)	—	≥ 16 GB 推奨	文書処理に必要
Neo4j	Neo4j, Inc.	≥ 5.x	IOC 正規化用グラフデータベース
Neo4j Python ドライバー	Neo4j, Inc.	≥ 5.x	Neo4j への Python インターフェース
オペレーティングシステム	Microsoft / Apple / Linux	Windows、macOS、または Linux	クロスプラットフォームサポート
PDF 解析 — プライマリバックエンド	Microsoft	MarkItDown ≥ 0.0.x	ステージ 1 バックエンド; PDF/DOCX/HTML/TXT 入力を Markdown に変換します。解析出力は LLM 処理前に 4,000 文字ごとに分割されます。アクセス日: 2025 年 12 月 15 日。https://github.com/microsoft/markitdown
パイプラインの設定 (ステージ 2 — IOC 抽出)	—	リファレンスデフォルト	単一 LLM モード: 温度 = 0.0, 最大ワーカー = 5。アンサンブル投票モードのデフォルト: 各モデルあたり繰り返し = 1、最小投票数 = 2。
パイプラインの設定 (ステージ 5 — 正規表現生成)	—	リファレンスデフォルト	生成温度 = 0.3。検証: IOC ごとに 5 つの決定論的ネガティブサンプルをランダムに生成します。反復の制限: 最大反復回数 = 10、デバッグループ制限 = 5、検証無効制限 = 5。
Python	Python Software Foundation	≥ 3.8	必要なランタイム環境
正規表現エンジン	Python 標準ライブラリ	re モジュール	正規表現の検証とテストに使用
Streamlit	Streamlit Inc.	≥ 1.25	ウェブベースのユーザーインターフェース
リファレンス実装ソースコード	著者 / GitHub | GitHub リポジトリ		Streamlit インターフェース、LangChain パイプライン、Neo4j 支援正規化、正規表現生成、検証ユーティリティ、および設定ファイルの例のソースコード。https://github.com/SOCautomatic/cti-ioc-regex-pipeline で入手可能。アクセス日: 2026 年 6 月 11 日。