Here it is with formatting preserved:
寄稿者：Andrew Green、企業向けITリサーチアナリスト
LLMは、SOCにおける数十年にわたる課題を最終的に解決する可能性を秘めています。しかし、統計的にもっともらしいテキスト文字列を生成する能力は、AI SOCを構成する要素のごく一部にすぎません。新しく、注目度が高く、経営層からのAI活用要請にも応えられる存在として、LLMはAI SOCにおいて脚光を浴びています。
まず、LLMが得意とする領域を確認しましょう。
- LLMの推論プロセスは、テキストベースの形式で人間のような推論を模倣するため、人間のエージェントの行動を代替する用途に利用できます。
- また、読み解きにくい大量のデータを要約し、人間が理解できるインサイトへ変換できます。
ただし、上記のいずれの能力も、データがLLMに適した形式で整備されていることが前提となります。本ブログでは、この点について取り上げます。
なぜSOCはLLMを活用した自動化に適した領域なのか
当然ながら、これらの能力は、現在SOCで使用されているテクノロジースタックが抱える課題に直接対応します。具体的には、アナリストが複数のツールを使用し、複数のデータソースを分析しながら、インシデントの調査と対応を手作業で行っているという課題です。
これにより、SOCで最もよく指摘される課題である、アラート過多、ツール統合、人員不足が生じています。SOARなどのツールは、決定論的な自動化を用いて、アラート過多や人員不足に関する課題に対処しようとしてきました。しかし、スクリプトやワークフローは、それらが設計されたユースケースに対してのみ有効です。一方、LLMベースの自動化は、ロジックを事前定義しなくても、調査や対応に適用できます。
ツール統合については、一般的にセキュリティ運用プラットフォームの導入が中心となります。これらは通常、UEBA、XDR、SOARを買収または自社開発したSIEMプロバイダーによるものです。しかし、こうした取り組みには多大な工数とコストがかかるため、多くの組織にとって導入の障壁となることがあります。LLMは自然言語インターフェース機能を備えているため、異なるツール群を横断するオーバーレイとして機能できます。
こうしたLLMの能力を活用するには、ChatGPTのような体験、つまりアナリストが送信したプロンプト経由でログを単一のLLMに取り込ませるだけでは不十分です。LLMはエージェントとして設計される必要があります。LLMとエージェントの違いは、LLMを取り巻くサービスにあります。これには、メモリ、RAG、推論と思考連鎖、出力解析などが含まれます。さらに、エージェントはマルチエージェントとして設計されます。これは、調整を担う1つのマスターエージェントまたはオーケストレーターと、エンドポイント対応エージェント、クラウドログ解釈エージェント、他のエージェントの出力の妥当性を評価する評価エージェントなど、複数の目的特化型エージェントで構成されます。このアーキテクチャにより、LLMエージェントはSOCワークフローの複雑さ、規模、反復的な性質に対応しやすくなります。
SOCでLLMを使用する際の制約
LLMはSOCの最も差し迫った課題の一部を解決するうえで有望ですが、制約がないわけではありません。主な制約は以下のとおりです。
コンテキストの劣化と忘却 - LLMのコンテキストウィンドウには限りがあります。会話が長くなったり、大規模なデータセットを処理したりすると、古い情報がモデルのアクティブメモリから押し出されます。SOCの調査では、数週間または数か月分のログを分析することがあります。そのような場合、正確な結果を得るために必要な過去の調査結果やコンテキストを、LLMが「忘れる」可能性があります。
マルチエージェントの引き継ぎにおける解像度の低下 - マルチエージェントアーキテクチャでは、エージェント間の引き継ぎが障害点となります。データがエージェントチェーンを通過する過程で、重要なコンテキスト、ニュアンス、中間的な調査結果が除外されたり、要約によって失われたりする可能性があります。
モデルドリフト - 出力が長くなるほど、ドリフトが発生しやすくなります。LLMが長い回答や分析を生成するにつれて、元のクエリから徐々に逸脱したり、特定のセキュリティコンテキストへの焦点を失ったりする傾向があります。これは、冗長な回答を生成する会話型LLMでは特に問題になります。
時系列分析 - LLMはテキスト内のパターン認識に優れていますが、数値や計算を処理するようには設計されていません。SOC業務では、統計的な外れ値の検出や、時間の経過に伴うユーザー行動の微妙な変化の特定が重要です。こうしたタスクには、専門的な統計モデルや機械学習アルゴリズムの方が適しており、その結果をAIエージェントに渡すことができます。
ハルシネーション - LLMは、入力内容に基づいてもっとも自然と思われる文章を生成します。その出力は事実性を保証するものではないため、もっともらしく見えても事実とは異なる内容を生成する可能性があります。また、一度発生したハルシネーションが後続の応答にも引き継がれる場合があります。
上記はLLM全般の制約だと考えるかもしれません。しかし、SOCのユースケースでは特に重要です。これは、扱う情報の機密性が高く、障害に対する許容度が低いだけでなく、セキュリティスタック自体にも理由があります。例えば、Entra ID、Google Workspace、Oktaなどを含むIAMログソースを考えてみましょう。
Entra ID
{
"time": "2025-01-15T14:30:25.123Z",
"operationName": "Sign-in activity",
"category": "SignInLogs",
"resultType": "Success",
"userPrincipalName": "john.doe@company.com",
"ipAddress": "203.0.113.100",
"location": "New York, US"
}Google Workspace
{
"id": {"time": "2025-01-15T14:45:30.456Z", "uniqueQualifier": "abc123"},
"actor": {"email": "jane.smith@company.com"},
"events": [{"name": "login", "type": "login"}],
"ipAddress": "198.51.100.25"
}Okta
{
"uuid": "def456-ghi789-jkl012",
"published": "2025-01-15T15:00:45.789Z",
"eventType": "user.session.start",
"actor": {"alternateId": "bob.wilson@company.com"},
"client": {"ipAddress": "192.0.2.50"},
"outcome": {"result": "SUCCESS"}
}各ログの構文を見ると、同じイベントタイプであっても、ログソースごとにフィールドやフィールド名が異なることが容易に分かります。この情報を解釈するには、人間はもちろんAIであっても、各ソースにおけるイベントのニュアンスを理解する必要があります。それができなければ、情報が誤って解釈され、誤った分析につながる可能性があります。情報の正規化とカノニカル化がなければ、脅威を理解し、調査に役立つインサイトを提供するための一貫した価値を抽出することは困難になります。
LLM前段のデータ処理と分析
データ取り込みからマルチエージェントアーキテクチャ、LLM後の検証と評価に至るまで、スマートなエンドツーエンドのパイプラインを構築することで、LLMが正確な出力を生成できる可能性を最大化できます。
LLM前段のデータ処理レイヤーは、上記の制約、特にハルシネーションに関する制約を回避するうえで、おそらく最も重要なレイヤーです。このLLM前段のレイヤーは、しばしばセマンティックレイヤーと呼ばれ、生のデータをLLMに適した形式へ変換する役割を担います。ここでいうLLMに適した形式とは、すべてのソースにわたって一貫性があり、明示的なスキーマを持つ形式を指します。
これは一般的に、データの正規化、重複排除、サニタイズ、変換によって行われます。これにより、例えばEntra ID、Google Workspace、Oktaのログを同じように読み解けるようになります。別の方法として、データソースごとに明示的なスキーマ定義を行い、そのソースがどのような形式であり、どのように解釈すべきかをLLMに示すこともできます。
前述の時系列分析と同様に、行動分析はLLMの得意領域ではありませんが、LLM前段のセマンティックレイヤーには非常に適しています。統計分析などの確立された手法は、UEBAなどのソリューションでよく採用されています。しかし、その出力は、別のアラートまたは単純な決定論的自動化スクリプトのいずれかであることが一般的です。AI SOCでは、これらをエージェントに転送し、さらなる調査、解釈、検証に活用できます。
AI SOCはLLMを超えて拡張される必要がある
ここまで、LLMに内在する制約と、それがAI SOCにおける唯一の構成要素にはなり得ない理由を見てきました。確かにLLMは、人間のアナリストに匹敵する高度な調査を、わずかな時間で実行できます。しかし、それを正確に行えるのは、適切な種類のデータが適切な形式で与えられ、その出力が評価・検証される場合に限られます。
したがって、データは単に機械可読であるだけでなく、人間が解釈できる形にする必要があります。結局のところ、LLMは人間が次に言いそうな内容を予測するように最適化されているのであり、ビットから真実を確立するように最適化されているわけではありません。ログを正規化し、重複排除し、エンリッチし、一貫したセマンティック構造へ整形するレイヤーは、任意の要素ではありません。基盤となるものです。
このセマンティックレイヤーは、断片化されたマルチソースのセキュリティデータを、論理的かつ理解しやすい形式へ変換することで、LLMがSOC環境で適切に機能するための判断基盤を提供します。
