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

サマリー

ここでは、サイバー脅威インテリジェンスレポートのファイルパス、レジストリキー、コマンドラインインジケーターから、セキュリティ情報およびイベント管理(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に示されており、キャプチャ群の探索段階と正則表現生成段階をまとめており、代表的な結果の残りをまとめています。

ステージ1:ドキュメント解析出力

図2はステージ1の出力を示しており、入力されたCTIレポートが統一されたMarkdown表現に解析されます。実行が成功すると、インターフェースはセクション境界や関連性インジケーターを含む構造化されたプレビューを表示します。

正しい実行は、ファイルパス、レジストリキー、コマンドライン断片などの技術的アーティファクトの一貫した段落分割と保存によって示されます。この段階での過度な切断やフォーマットの喪失は、下流解析に影響を与える可能性があるため、進める前に対処すべきです。

第2段階:合意に基づくIOC抽出

図3 は、複数LLMアンサンブル投票を用いて候補IOCを抽出するステージ2の出力を示しています。その結果、JSON形式のIOCコレクションには投票数と寄与モデルが注釈付きで表示されます。

構成された最小合意閾値を満たすIOCのみが保持されます。この段階で除外されるIOCは通常、モデル特有の幻覚や曖昧なテキスト断片を反映しています。彼らの排除は予想され望ましい結果であり、アンサンブル投票が正しく機能していることを示しています。

第3段階:IOC分析と分類

表2は 各プロトコル段階における期待される出力、自動検証ステップ、アナリスト向けの品質管理チェックをまとめています。

図4 は、ステージ2のアンサンブル投票でコンセンサス閾値に達しなかったIOC候補者と、アナリストによる検査のためにインターフェースが表面化したものを示しています。このような候補は、モデル特有の幻覚や曖昧なテキスト断片を反映することが多いです。したがって、 図4 と 図5 は、同じステージ3プロセスの別の見解ではなく、異なる段階出力に対応しています。すなわち、ステージ2から廃棄されたセットとステージ3で保持されたセットです。

図5 は、JSON解析、ルールベースの分類、IOC重複除去を経て、ステージ3で作成された保持されたIOCテーブルを示しています。保持される各IOCごとに、ステージは標準化されたカテゴリ、ソースタグ、利用可能な場合は元の抽出キーを記録し、その後IOCを下流正規化に渡します。

第4段階:IOCタイプをまたぐグラフ支援によるIOC正規化

図6、図7、図8は、本研究で扱われている3つのIOCカテゴリ、すなわちファイルパス、レジストリキー、コマンドラインインジケーターの代表的な正規化結果を示しています。各カテゴリごとに、図はCTIレポートから抽出された元のIOCとグラフ支援解析で得られた正規化された表現を比較しています。

すべてのIOCタイプにおいて、プロトコルは各IOCを意味的コンポーネントに分解し、グラフデータベースに符号化された構造化された知識を用いて階層的関係を解決します。現在の実装では、Neo4jは正規化されたパス、レジストリ、CLIノードを保存し、隣接関係を使ってコンポーネントが認識されたチェーンに属しているかどうかをテストしています。この役割は、検出工学²における構造化されたATT&CK知識の使用に類似しています。

重要なのは、この正規化ステップがIOCコンポーネントを「保持」または「破棄」とラベル付けし、解析レコードから無言に削除するのではなく、明示的な意味役割を記録することです。正規化された文字列は主にkeepコンポーネントから再構成され、discardコンポーネントは下流の正則表現生成および検証のためのメタデータとして残されます。

この段階の正しい実行は、意味のある構造的文脈を保持し、異なるIOCタイプ間で一貫したキャプチャーグループラベリングを示す正規化されたIOCによって示されます。元の表現と正規化された表現の視覚的比較は、キャプチャグループ解像度が一貫して適用され、意図しない情報損失なしであることを検証するための実用的な品質管理メカニズムを提供します。

第5段階:補助制約ベース選択を用いた正則表現生成

図9 はステージ5の出力を示しており、プロトコルは正規化されたIOCから反復検証ワークフローを通じて構造的に準拠な正則表現を生成します。実装は、初期生成プロンプト、候補がIOCに合わなかった場合の診断再プロンプト、破棄認識検証、制限付き再試行ループを組み合わせています。

正規化されたIOCとそれに関連するkeep/disportコンポーネント仕様が与えられると、ワークフローはまず初期の正則表現候補を生成します。候補はIOCに対してテストされ、マッチング失敗時には診断的に再提示され、禁止された破棄トークンのチェック、そしてランダムな負の文字列を用いた過度の一般化の評価が行われます。

複数の候補が基本的な検証チェックを満たす場合、プロトコルは補助制約ベースの選択機構を適用し、下流使用のために代表的な正則表現を保持します。現在の実装では候補者に「Score = n_cg - n_wc」と評価されます。ここで「n_cg」は代表されるキープコンポーネントの数、「n_wc」は正則表現に含まれる破棄または未マッピングトークンの数です。

選択関数は次のように定義されます:

スコア = n_cg − n_wc

これはより一般的な形 Score = α·n_cg − β·n_wcの等重み特化(α = β = 1)です。ここで、n_cgは表現されたキープ成分の数を示し、正則表現によって再導入された破棄コンポーネントやマッピングされていない余分なトークンの数n_wcを示します。実装では、各IOCの反復回数、発行リスト、推定トークン消費量、キャッシュ使用量、レイテンシーテレメトリーも記録します。等重み設定は参照実装の単純な決定論的デフォルトとして使われました。欠損キープコンポーネントと再導入された破棄コンポーネントを同様に望ましくないものとして扱うため、偽陰性と偽陽性が異なる運用コストを伴う展開文脈では、他の重み付けが好まれることがあります。

最終的な正則表現は、これらの制約を最もよく満たす候補として選ばれます。例えば、必要なキャプチャ群コンポーネントをオプションの構造(例えば ...)?に収める正則表現は、意味の一貫性を弱めるため選択から除外されます。この選択ステップは生成プロセスの補助的なものであり、単独の品質指標として機能することを意図していません。

CTI処理の分析概要

図10 は、処理済みすべての文書におけるCTI分析結果の概要を示しています。リファレンス評価では、3,156件のCTIレポートからIOC抽出を行い、63,000以上のIOC候補が生成されました。その中には12,195のファイルパス、2,302のレジストリキー、10,286のコマンドラインインジケーターが含まれ、残りの候補は非正則表現ターゲットのIOCタイプに属していました。

これらのカウントは、抽出された指標が現在のプロトコルで対象となる3つのIOCカテゴリに集中していることを高レベルで検証しつつ、多くの抽出されたアーティファクトが正則表現生成範囲外であることを示しています。ワークフローを再現する際は、処理されたCTIレポートの正確な数、総IOC候補数、カテゴリ別カウント、抽出時に使用した提供者、モデル、モデルバージョン、温度、リピート数、コンセンサス閾値を報告してください。

参照評価では、生成された正述式を10のMITRE AT&CK評価シナリオから独立に収集した2,400以上のグラウンドトゥルース文字列と照合し、平均ヒット率99.1%、平均クロスIOCミスマッチ率0.8%を記録しました。本論文では、ミスマッチ率を意味論的特異性の指標として用いています。すなわち、あるIOCで生成された正則表現が、別のIOCに関連付けられたグラウンドトゥルース文字列と一致する場合にミスマッチが生じます。この量はエンドツーエンドの運用アラート誤検知率として解釈すべきではなく、これは下流のルールロジックや展開の文脈にも依存します。

この分布はCTIコーパスの構造的構成を反映しており、抽出された指標が期待されるIOCタイプと整合していることをユーザーが検証できるようにします。予想される割合から大きく逸脱した場合は、上流の解析や抽出の問題を示す可能性があり、下流正規化や正則表現生成に進む前に確認すべきです。

正則表現最適化アクションの解析

図11 は、正規表現の生成と精緻化中に行われる動作を要約しています。この分布には、初期正述式生成、LLM駆動の最適化ステップ、再試行ベースの再生の3種類のアクションが含まれます。

LLM駆動の最適化は、観測された全アクションの51.7%を占めています。この普及率は、初期生成だけでは捕獲群制約や排除要件を満たす正述式を生成するにはしばしば不十分であることを示しています。代わりに、候補正則式を洗練するために反復最適化を積極的に繰り返し適用します。

この分布は非効率を反映するのではなく、複雑なIOC入力から構造準拠の正則式を生成する際に最適化ワークフローがプロトコルの必要かつ不可欠な要素であることを示しています。

スケーラビリティテストLLMで生成された6,000のIOCのランダムサンプル(材料表参照)では、中央値レイテンシが1 IOCあたり2.95秒、平均レイテンシが23.18秒と報告されました。同じ特徴付けでは、構文有効正則表現のコンパイル率は99.56%に達し、全体の生成成功率は99.4%に達し、平均推定トークン使用量は1IOCあたり約3,986トークン、ワークフローには平均して約7.89回のLLMコールが必要でした。マッチデバッグループで初回通過成功率は56.46%、非キャプチャグループ検証ループで72.92%でした。これらの測定は、バッチ利用における計算コストと運用スループットの特徴付けに役立ちます。

現在の参照特性評価におけるモデル再学習には、サンプル出力部分集合の専門家レビューは使用されませんでした。報告された結果は、自動パイプライン実行および上記の下流評価データセットを反映しています。

運用証拠と失敗処理。図12は、プロトコルによって生成されたエクスポートされたSIEM正則表現ファイルの構造と、代表的なファイルパス、レジストリキー、コマンドラインパターンに関するルールレベルの検証証拠を示しています。図13は対応する完全なJSONレポートを示しており、すべてのステージ出力(抽出、解析、正規化されたIOCと生成された正則表現パターンおよびIOCごとの検証フラグを含み)を公開し、下流ツールが消費する主要なアーティファクトとなっています。図14はノイズの多いCTI入力に対するプロトコルの処理を示しています。解析段階でデファング処理され、ホワイトスペースが乱れたファイルパスがフラグ付けされ、修正され、標準的な%TEMP%テンプレートに正規化され、コンパイルされ対応する正則表現に変換されます。この作業例は、図12および図13の運用的証拠を補完し、生のIOCテキストが標準形から逸脱した際のプロトコルの挙動を示しています。

図1:IOCから正則表現へのプロトコルの全体アーキテクチャ。 図はエンドツーエンドのパイプラインをまとめたものです。上流のIOCエクストラクタによって生成された候補IOC文字列は分解され、Windowsドキュメントから入力されたNeo4jグラフ内の参照ノードと比較されます(ステップ1)、これにより既知のパス、レジストリ、コマンドラインコンポーネントが取得されます(ステップ2)。変数や環境固有のフラグメントは破棄としてラベル付けされ、正規化再構築から除外されますが、コンポーネントメタデータに保持され、正規化されたIOCとコンポーネントレベルの保持・破棄ラベルが得られます(ステップ3)。これらの正規化されたIOCはLLMベースの正則表現生成段階(ステップ4)に渡され、候補正則表現が生成されます。これらはスコアリングされ、キャプチャグループ制約や破棄トークンルールに対して反復的に最適化され(ステップ5)、最終的な正則表現が選択されます(ステップ6)。 この図の拡大版はこちらをクリックしてご覧ください。

図2:ステージ1ドキュメント解析出力。元のCTIレポートと解析済みドキュメントプレビューの並べ比較。左のパネルにはPDF形式の元のCTIレポートが表示され、右のパネルにはパーサーによって生成された統一されたMarkdown表現が示されています。この図の拡大版はこちらをクリックしてご覧ください。

図3:マルチLLMアンサンブル投票を用いた合意に基づくIOC抽出。 インターフェースはアンサンブルベースのIOC抽出プロセスとその中間結果を示しています。赤いボックスは、IOC抽出に参加している設定済みのLLMインスタンス、選択したプロバイダー、各モデルで繰り返し実行された抽出回数を示します。青いボックスはユーザー定義の合意閾値を示し、IOCを保持するために必要な最小発生回数を示します。すべてのモデルと重複で抽出結果を集約した後、閾値より少ない回数の候補IOCは破棄されます。オレンジのボックスは、コンセンサス基準を満たし、下流の解析段階に渡される最終的な保持IOCのセットを示します。 この図の拡大版はこちらをクリックしてご覧ください。

図4:ステージ2でアンサンブル投票で廃止されたIOC。 アンサンブル投票で設定された最低得票閾値を満たさなかったIOC候補者の並べて見て、分析者の検査のために公開されています。破棄された候補は、モデル固有の幻覚や曖昧なテキスト断片を反映し、ステージ3の分類段階には進みません。 この図の拡大版はこちらをクリックしてご覧ください。

図5:標準化された分類で保持されたIOCセット。 ステージ3処理後に保持されたIOC候補は、標準化されたカテゴリ、ソースタグ、利用可能な場合は元の抽出キーとともに表示されます。この表は正規化段階で使用される構造化されたIOC入力を提供します。この図の拡大版はこちらをクリックしてご覧ください。

図6:グラフ支援解析を用いたファイルパスIOC正規化。 元のファイルパスIOCとその正規化された表現の並べて比較。グラフベースのトラバーサルクエリは、正規化された名前で知られるパスコンポーネントを、各コンポーネントを保持または破棄にラベル付けします。したがって、ドライブ識別子や可変ファイル名の断片はコンポーネントレコードで破棄マークされ、正規化されたフォームは主に下流パターン構築に必要な保持された構造セグメントから再構築されます。 この図の拡大版はこちらをクリックしてご覧ください。

図7:グラフ支援解析を用いたレジストリキーのIOC正規化。 階層的レジストリ構造のグラフ支援によるレジストリキーIOCの正規化。略化されたルートキーは標準レジストリのハイブに拡張され、アナライザーはホストのプレースホルダー、SID類似の値、GUID類似のトークンをスキップしながら、最も長く連続した既知のレジストリ部分文字列を抽出します。出力は各保持コンポーネントのラベルを保持・破棄し、下流処理のための標準的なレジストリパスを生成します。 この図の拡大版はこちらをクリックしてご覧ください。

図8:グラフ支援解析を用いたコマンドラインIOC正規化。 元のコマンドラインIOCとその正規化表現の比較。このプロトコルは、引用された文字列を保持しつつコマンドラインをトークン化し、可能な限りNeo4jルックアップでリードコマンドトークンを正規化し、埋め込まれたパス様またはレジストリ様の断片を再帰的に解析します。安定したコマンド関連コンポーネントはkeep、変数引数はdiscardとラベル付けされ、最終的な標準的なコマンド構造は保持された要素から再構成されます。 この図の拡大版はこちらをクリックしてご覧ください。

図9:正則表現候補の制約ベース選択。 各正規化されたIOCごとに複数の正則表現候補が反復検証ワークフローを用いて生成されます。制約駆動のスコアリング機構を用いて、指定されたキャプチャグループ成分を保持しつつ、不要な変数部分文字列を制限する最終的な正則表現を選択します。 この図の拡大版はこちらをクリックしてご覧ください。

図10:抽出されたIOCのCTIレポート分布。 CTIレポートから特定されたインジケーターの総数と、ファイルパス、レジストリキー、コマンドラインインジケーター間での分布を示すIOC抽出結果の要約。このビューはCTIのコンテンツカバレッジと抽出挙動の高水準検証を提供します。 この図の拡大版はこちらをクリックしてご覧ください。

図11:正規表現生成中の最適化行動の分布。 正則表現生成中に行われるアクションの分解(初期生成、LLM駆動の最適化、再試行ベースの再生など)。LLM駆動の最適化は全アクションの51.7%を占めており、反復的洗練がキャプチャグループ制約を満たす正述式を生成するためのプロトコルの重要な要素であることを示しています。 この図の拡大版はこちらをクリックしてご覧ください。

図12:代表的なエクスポートされた正則表現ファイル。 プロトコルによって生成されるSIEM正則表現エクスポート(siem_rules.txt)のサンプル内容。各エントリにはソースIOC、推論されたカテゴリ(ファイルパス、レジストリキー、コマンドライン)、および検証済みの正則表現パターンが含まれます。付随する検証表は、各ルールタイプに対して正しさを確認するために用いられる期待される挙動とシステムエビデンスをまとめています。 この図の拡大版はこちらをクリックしてご覧ください。

図13:代表的な完全なJSONレポート。 代表的なCTIレポート上で5つのプロトコル段階すべてを実行した後に生成されたエンドツーエンドのパイプライン出力。JSONドキュメントは、ソースファイル、解析されたセクション数、カテゴリ別にグループ化された抽出済みIOC、ソースタグ付きのステージ3カテゴリズレコード、ステージ4正規化差分、ステージ5の正規表現パターンとIOCごとの検証フラグを記録します。また、報告書はトップレベルの成功およびエラーのメタデータを明らかにし、下流ツールが部分的な失敗を検出できるようにします。 この図の拡大版はこちらをクリックしてご覧ください。

図14:失敗またはノイズの多い入力:識別と修正。 プロトコルがノイズの多いIOCを識別し、回復する例です。生の入力 %T E M P%\malware[.]exeがフラグが立てられているのは、その環境変数トークンに挿入されたスペースが含まれており、ファイル拡張子がデファング化されているためです。補正ステップは挿入された空白を除去し、文字の点を復元します。第4段階の正規化では、%TEMP%を標準的なWindowsの一時ディレクトリテンプレートに拡張します。ステージ5は、修正された正規化されたIOCをコンパイルしマッチングする正規表現を生成します。この例は、ディスカッションで議論されたノイズの多い入力処理を示しています。 この図の拡大版はこちらをクリックしてご覧ください。

要素	種類	価値 / スキーマ	例	注記
ノードラベル	レーベル	:P	Windows、System32、cmd.exe	Windowsのファイルパスコンポーネントを格納します
ノードラベル	レーベル	:レジストリ	ソフトウェア、マイクロソフト、Windows NT	根の巣箱の下にレジストリキーコンポーネントを格納します
ノードラベル	レーベル	:CLI	powershell.exe、-ExecutionPolicy、バイパス	コマンドトークンとパラメータを格納します
ノードの性質	ストリング	名称	cmd.exe	オリジナルの薬莢;正規化出力での表示に使用されます
ノードの性質	ストリング	name_lower	cmd.exe	小文字の表記;すべてのMATCHクエリのルックアップキーとして使用
関係	有向辺	(a)-[:次]->(b)	(Windows)-[:NEXT]->(System32)	両端点は同じラベルを共有しています。Windowsシステムでのネイティブ隣接エンコード
制約	一意性	n.name_lower ラベルごとのユニーク	-	:P ath、:Registry、:CLI に適用しました
データソース	カバレッジ	Windows 8、10、11	-	グラフに入力されたクライアントOSです
データソース	カバレッジ	Windows Server 2012、2016、2019、2022	-	グラフに入力されたサーバーOSです

表1:IOC正規化に使用されるNeo4jグラフスキーマ(ステージ4)。 3つのノードラベル(パス、レジストリ、CLI)、共有プロパティスキーマ(名前、name_lower)、ネイティブ順序付けの辺に用いられる有向隣接関係、一意性制約、そしてグラフを埋めるWindowsクライアントおよびサーバーバージョンを一覧にします。

舞台	期待出力	自動検証	アナリスト向け品質管理
ステージ1:ドキュメント解析	統一されたMarkdownテキストで、LLM処理前に4,000文字のチャンクで処理されます。	—	ファイルパス、レジストリキー、コマンドラインの断片、セクション境界が解析後に残っていることを確認するためにMarkdownプレビューの視覚的チェック;テクニカル文字列が切り詰められた場合はバックエンドを切り替えます。
第2段階:IOC抜出	3つの最上位キー(ファイルパス、コマンドライン、レジストリキー)を持つJSON;アンサンブル投票が有効になった場合のIOCごとの投票数と寄与モデルのメタデータ。	コンセンサス閾値フィルター(min_votes)は、設定された閾値以下の投票数のIOCを除外します。	除外された候補者の検査を行い、幻覚と過度に厳格な投票を区別してから調整min_votes。
第3段階:IOC分析と分類	分類されたIOCリスト:各IOCには標準化されたカテゴリ、ソースタグ、利用可能な場合は元の抽出キーがペアリングされます。	正規表現ベースのルールとIOCパターンヒューリスティックによる標準化されたカテゴリマッピング;(IOC、カテゴリー)ペア重複除去。	曖昧またはノイズの多い候補に対して分類された出力のスポットチェック(図4A)。
ステージ4:Neo4j補助正規化	IOC単位の正規化形式で、コンポーネントレベルの保持/破棄ラベルを使います。	Windows参照グラフ上で(i)-(iii)を問い合わせる暗号;Neo4jが利用できない場合の決定論的前処理のフォールバック。	全破棄ケースの検査によるグラフカバレッジのギャップの特定;必要に応じてベンダーや環境固有の参照を組み合わせてグラフデータの拡張を行うこと。
第5段階:正則表現生成とスコアリング	候補スコア、最適化履歴、反復回数、IOCごとのテレメトリーを含むIOCごとの最終正則表現。	マッチテスト、静的品質チェック、境界認識禁止トークンチェック、5つの決定論的負サンプルに対する過剰一般化テスト;フォールバックは最高得点の部分マッチ(used_fallbackフラッグ)に切り替えます。	フォールバック正述式の最適化履歴レビュー;再生前に故障位置の故障診断検査を行います。

表2:ステージ出力および検証の概要。 各プロトコルステージ(1–5)を、その期待されるアーティファクト、パイプラインによって生成される自動検証証拠(正則表現コンパイル状況、ヒット率、クロスIOCミスマッチ率、最適化反復数)、および対応するアナリスト向けの品質管理チェック(視覚比較、廃棄候補の検査、カテゴリレビュー)にマッピングします。

補足ファイル1:逐語的なLLMプロンプト。 ステージ2のIOC抽出およびステージ5の正則表現生成・最適化に使用されるヴァーバティムシステムと人間のプロンプト。このファイルをダウンロードするには、こちらをクリックしてください。

補足ファイル2:ステージ4および5の実施詳細。 ステージ4のグラフ支援によるIOC正規化およびステージ5の正則表現検証、スコアリング、反復制御をサポートするアルゴリズムおよび実装の詳細。 このファイルをダウンロードするには、こちらをクリックしてください。

ディスカッション

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

このプロトコルの中心的な貢献の一つは、ワークフローを段階ごとに明示的に分解し、中間出力が検査可能な点にあります。実装は具体的に説明されています:文書解析でMarkdownおよびチャンクテキストが生成され、LLM処理が可能になります。IOC抽出はファイルパス、レジストリキー、コマンドラインインジケーターの構造化されたJSONを出力します。ルールベースのIOC解析は抽出した値を標準化し重複化し、Neo4j支援正規化は、各IOCコンポーネントを保持するか破棄するかに割り当てます。正則表現生成は候補選択前にマッチデバッグ、破棄検証、オーバージェラライゼーションチェックを適用します。

このプロトコルは、正則式生成を単発予測問題ではなく反復的な構築タスクとして扱います。実装では、初期生成プロンプト、自動マッチ診断、上限付き精錬ループ、コンポーネントベースのスコアリング関数を用いて、構造的に重要なIOC要素を保持しつつ、破棄またはマッピングされていない部分文字列にはペナルティを与えます。この反復設計と各ステップに適用される決定論的検証器は、大規模で異種な評価セットにおいて構造的に忠実な正述パターンの生成を支援します。リファレンス評価では、このワークフローが3,156件のCTIレポートに適用され、2,400以上の独立したグラウンドトゥルース文字列と比較して評価され、平均ヒット率は99.1%、クロスIOC間のミスマッチ率は0.8%でした。これらのグラウンドトゥルースストリングは、MITRE AT&CK評価演習中にサイバーセキュリティベンダーが報告した専門家が厳選した成果物であるため、この評価は暗黙のうちに、自動化生成されたものではなく、人間の分析者が記録したIOCパターンとプロトコルの出力を比較しています。

代表的な結果が示すように、ワークフローがネストされたファイルパスや長いコマンドライン文字列のような複雑なIOC構造を扱う場合、反復最適化が特に重要です。参照評価結果は、攻撃者がグラフデータベースに表現されていない、またはCTIレポートに明示的に記載されていないカスタム実行ファイルやパラメータを使用する場合に最も多い非マッチケースが発生します。運用上、これらの障害モードはサイレントエラーではなく予想される境界条件として扱い、グラフカバレッジ、ソースレポートの完全性、正則式デバッグテレメトリのレビューをトリガーすべきです。

このプロトコルは、3つの代替方法ファミリーと比較できます。まず、TransRegex¹¹やRegex+¹²のような例ベースの正述式合成手法は、厳選された正負の文字列例から正述式を学習します。これらの手法は、代表的な例セットが存在する場合には良好に機能しますが、CTIで報告される各IOCは通常単一の代表的な文字列として現れ、必要な一般化境界は例カバレッジではなく運用意味論によって決定されるため、SOC文脈には直接的に適用できません。第二に、Bartoliらが導入した遺伝的プログラミング手法は、進化演算子を通じて正述式^{空間を探索}し、通常は一致文字列と非一致文字列のラベル付きコーパスを必要とします。抽出パターンのバッチ構築には適していますが、非構造化のCTIナラティブを直接消費しません。第三に、最近の神経学的およびLLMベースのアプローチ^15,16は、自然言語の記述を直接正述列に翻訳します。これらの手法は、よく指定されたプロンプトには強力ですが、単発使用では構文的に妥当な正述が生成され、必要なキャプチャーグループの要素を欠いたり、無関係なIOCバリアント間で過度に一般化されてしまうことがあります。本プロトコルはこれらの指示を補完しており、(i) キュレーションされた例集合や自然言語クエリではなく非構造化CTIレポートを入力として受け取り、(ii) 各IOCをグラフ支援の正規化によってキープ・ディスカビュメントに分解し、(iii) 制限付き反復ループ内で決定的なマッチ、破棄、オーバー汎化チェックで候補レギュラを検証します。目標は、従来の手法を自社のベンチマークで上回ることではなく、その中間的な意思決定がSOCアナリストによって検査・監査可能な再現可能なIOCから正規表現へのパイプラインを提供することです。

プロトコルは入力されたCTIレポートの品質についていくつかの仮定をしています。これは、(i) IOC文字列が文書解析後に復元可能なテキスト形式で現れること、すなわちファイルパス、レジストリキー、コマンドラインインジケーターが画像、スクリーンショット、または難読化されたエンコーディングにのみ埋め込まれていないことを前提としています。(ii) CTIで報告されたIOCフラグメントは構造的アンカーを保持するのに十分に完全である(例えば、レジストリキーはハイブプレフィックスを保持し、ファイルパスはWindowsドキュメントグラフで認識可能な少なくとも1つのディレクトリアンカーを保持し、コマンドラインは呼び出し実行ファイルや既知のモジュール参照を保持する)。(iii) 報告されたIOCは、プロトコルが依存するキャプチャグループコンポーネントを除外する形で切り詰められたり、編集されたり、書き換えられたりしない。これらの前提を満たすCTIレポートには、ほとんどのMITRE AT&CK技術説明、ベンダーアドバイザリー、インシデント対応の報告、適切にフォーマットされた脅威速報が含まれます。主にスクリーンショットに頼るレポート、周囲の文脈を欠いた非常に簡略化されたIOCリスト、明示的なIOC文字列のないフリーテキストの言い換えは、意図された動作範囲外であり、抽出リコールの減少や忠実度の低下をもたらすことが予想されます。このようなレポートは、パイプラインに入る前に画像からテキストへの上流の前処理やアナリストによるレビューが有益になる場合があります。

このプロトコルを適用する際には、いくつかの制限を考慮する必要があります。まず、現在の実装はドメイン、メールアーティファクト、ユーザーエージェント文字列、動作シーケンスなどの広範なIOCカテゴリよりも、ファイルパス、レジストリキー、コマンドラインインジケーターに焦点を当てています。これは意図的な範囲選択であり、原子指標は一般的に完全一致のワークフローで十分に機能し、現在のプロトコルは正則表現の一般化が恩恵を受ける変数構造IOCを対象としています。それでも、現在グラフに表示されていないIOCタイプへの適用性は制限されます。次に、現在の障害シナリオは主に3つのカテゴリーに分けられます。すなわち、オペレーティングシステムグラフに欠如する非ネイティブパスやコマンドライン引数、関連するユーティリティや構造体のグラフカバレッジが不完全であること、そして重要なコマンドフラグメントやコマンドレットが報告されなかったCTIソース自体の不完全さです。第三に、参照評価で用いられたクロスIOCミスマッチメトリクスは、展開されたSIEMロジック下でのエンドツーエンドの誤検知ではなく、生成された正言式の意味特異性を測定します。

LLMの可変性とバージョン管理における再現性。IOC抽出および正則表現生成段階は商用LLMエンドポイントに依存しているため、再現性に影響を与える2つの変動要因があります。提供者側のモデルの時間経過による更新と、通話ごとのサンプリング確率性です。前者を軽減するために、Materials TableのすべてのLLM関連フィールドには正確なモデル識別子と参照評価で使用されたアクセス日が記録され、プロバイダーが特定のモデルスナップショットを公開した際にはピン留めを推奨します。後者を緩和するために、リファレンス実装ではIOC抽出温度を0.0に固定し、正則表現生成段階でのみゼロでない温度を使用し、ステージ2および5のアンサンブル投票と決定論的検証器が残差変動を吸収します。これらの結果を再現する際は、正確なモデルバージョン、アクセス日、温度、使用されたアンサンブル投票閾値を記録する必要があります。これらの軸のいずれかで大幅な逸脱があれば、命中率やミスマッチの指標が変動することが予想されます。

いくつかの回復可能な故障モードは、それらを生み出した段階レベルで対処可能です。 ステージ1の解析失敗 (例:スキャンされたPDFで空または乱れたマークダウンが出る場合):再アップロード前に光学文字認識または外部コンバーターで入力を前処理すること;解析セクション数と総文字数がゼロでないことを確認してから進めてください。 第2段階の抽出失敗 (IOCが返っていない、またはエントリが幻覚的に現れる):アンサンブル投票の閾値(最小投票数≥2)を上げる、追加のモデルインスタンスを有効にする、またはLLMの温度を下げる;API接続性を確認し、設定モデルがJSON形式の出力を受け入れていることを確認しましょう。 全破棄ラベルを用いた第4段階の正規化 (すべてのIOCコンポーネントは破棄ラベル付き):Neo4j参照グラフにベンダーまたは環境固有のパスコンポーネントとレジストリルートを拡張します。Cypherインポートスクリプトとkeep/discardの決定ルールは 補足ファイル2に記載されています。 ステージ5の正則表現失敗 (used_fallback = true、または繰り返しの破棄検証拒否):失敗した検証者を特定するために、IOCごとの最適化履歴フィールドを検査します。IOCに安定したkeepコンポーネントが本当に欠けている場合は、手動で正則表現の作成を行うか、自動ルール生成から除外しつつ、分類されたIOCテーブルに残してアナリストがレビューできるようにする方法を検討してください。

上記の制限に従い、生成された正行式は自給自足型検出器ではなく、より広範なSOC検出コンテンツ内の再利用可能な検索プリミティブとして扱うのが最適です。運用環境では、アナリストはプラットフォーム固有のフィールドロジック、ホワイトリスト、出所チェック、相関条件と組み合わせて、異常だが悪意のない経路から生じる無害なマッチを抑制できます。

将来の研究には、人間作成の正則表現との体系的な比較、追加のIOCカテゴリにわたる広範な評価、構造化されたアナリストフィードバック研究、攻撃者が作成したユーティリティやコマンドレットのグラフカバレッジ拡大、そして展開環境におけるエンドツーエンドのレイテンシとコストの詳細な報告が含まれる可能性があります。それでもなお、現行プロトコルはIOCから正規表現への翻訳の再現可能かつ運用上解釈可能な枠組みを提供し、その強みと現在の限界の両方を記録しています。

材料

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

名前	会社	カタログ番号	コメント
コンピューター (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 日。