エクサフォース・ブログ | One LLM does not an AI SOC make

寄稿者:企業ITリサーチアナリスト、アンドリュー・グリーン

LLMは、SOCにおける数十年前の課題を最終的に解決する可能性を秘めていますが、統計的にありそうなテキスト文字列を生成できるかどうかは、AI SOCを構成するもののほんの一部にすぎません。LLMは新しく、かっこよく、経営幹部からの AI の要請に応えているため、AI SOC で脚光を浴びています。

まず、LLM がどのような点で優れているかを覚えておきましょう。

彼らの推論プロセスは、人間のような推論をテキストベースの形式で模倣し、人間のエージェントの行動の代わりに使用できます。
読みにくい大量のデータを要約し、人間が理解できる洞察に変換します。

上記のいずれの機能も、データが LLM に適した方法でフォーマットされている必要があります。これについては、このブログで取り上げます。

SOCがLLMを使った自動化に適した分野なのはなぜでしょうか？

当然のことながら、これらの機能は、SOCで使用されている現在のテクノロジースタックの課題を正確に解決します。つまり、アナリストが複数のツールを使って複数のデータソースを分析し、インシデントを手作業で調査して対応することです。

アラート過負荷、ツールの統合、スタッフ不足など、SOCで最も多く挙げられている問題は、このようにして発生しました。SOARなどのツールは、決定論的自動化を活用して、アラートの過負荷や人員不足の問題に対処しようとしてきました。ただし、スクリプトとワークフローは、本来の用途にのみ役立ちます。ただし、LLM ベースの自動化は、ロジックを事前に定義しなくても調査や対応を行うのに適しています。

ツールの統合では、通常、セキュリティ運用プラットフォームの導入が中心になります。これらのプラットフォームは通常、UEBA、XDR、SOARを買収またはネイティブに開発したSIEMプロバイダーです。これらは非常に手間がかかり、コストも高く、ほとんどの組織では法外な作業であることが多いです。LLM は自然言語インターフェース機能を備えているため、さまざまなツールを重ねて使うことができます。

これらのLLM機能を活用するには、ChatGPTのような経験を積むだけでは不十分です。つまり、アナリストが送信したプロンプトからログを取得するLLMを1つだけ使用します。LLM はエージェントとして設計する必要があります。LLMとエージェントの違いは、メモリ、RAG、推論と思考連鎖、出力解析などを含む、LLM に関連するサービスに関係しています。次に、エージェントはマルチエージェントに設計されます。マルチエージェントは、調整を担当する1つのマスターエージェントまたはオーケストレーターと、エンドポイントレスポンスエージェント、クラウドログ解釈エージェント、他のエージェントからの出力の有効性を評価する評価エージェントなどの複数の専用エージェントで構成されます。このアーキテクチャにより、LLM エージェントは SOC ワークフローの複雑さ、規模、および反復的な性質に対処するのに適しています。

SOC で LLM を使用する場合の制限事項

有望なLLMは、SOCの最も差し迫った課題のいくつかを解決するためのものですが、次のような制限がないわけではありません。

コンテキストの劣化と忘却- LLM のコンテキストウィンドウには限りがあります。会話が長くなったり、大規模なデータセットを処理したりすると、古い情報がモデルのアクティブメモリから押し出されてしまいます。SOC の調査には、数週間または数か月分のログの分析が含まれる場合があります。このような場合、LLMは、正確な結果を得るために使用する必要のある以前の調査結果やコンテキストを「忘れる」可能性があります。
マルチエージェントハンドオフによる解像度の低下- マルチエージェントアーキテクチャでは、エージェント間のハンドオフは障害点となります。データがエージェントチェーン内を移動するにつれて、重要なコンテキスト、ニュアンス、または中間調査結果が除外されたり、要約されたりすることがあります。
モデルドリフト- 出力が長いほど、ドリフトが発生しやすくなります。LLM では回答や分析が長くなるにつれて、元のクエリから徐々に逸脱したり、特定のセキュリティコンテキストに集中できなくなったりする傾向があります。これは特に、冗長な回答を提供するおしゃべりな LLM で問題になります。
時系列分析- LLMはテキスト内のパターン認識に優れていますが、数値や計算を処理するようには設計されていません。SOCの作業は、統計的な外れ値の検出や、時間の経過に伴うユーザー行動の微妙な変化の特定に大きく依存しています。これらのタスクは特殊な統計モデルや機械学習アルゴリズムに適しており、その結果を AI エージェントに送ることができます。
幻覚- LLMは、プロンプトとコンテキストに基づいて最も可能性の高いテキスト文字列のみを生成します。予測には真偽値がないため、実際には正しくない可能性が高い文字列が生成されることがあります。次の応答では、1 つの幻覚が引き継がれる可能性があります。

上記は全体として LLM の限界だと思われるかもしれませんが、SOC のユースケースでは特に重要です。機密性が高く、障害に対する許容度が低いだけでなく、セキュリティスタック自体もそのためです。たとえば、Entra ID、Google ワークスペース、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が効果的に運用し、SOCで真に価値を提供するために必要な基盤を提供します。