Databricks上の特化型エージェントによるセキュリティアラートトリアージのスケール化

重要度「低」が、優先度「低」を意味しないとしたらどうでしょうか？

Databricksは、エンドポイントセキュリティツール、クラウドアクティビティログ、脅威インテリジェンスフィードなど、さまざまなソースからペタバイト規模のセキュリティログをセキュリティレイクハウスにインジェストしています。当社の検知アーキテクチャは、悪意のあるアクティビティがないか、このデータを継続的に監視しています。特定されたすべてのシグナルは中央集約されたアラートテーブルに格納され、インシデント対応（IR）アナリストによる確認を待ちます。

毎日発生する何千ものセキュリティアラートの中から本物の脅威を見つけ出すことは、まさに「干し草の山から針を探す」ようなものです。多くのチームは、アラートを重要度順に優先順位付けすることで、この負荷に対処しています。HIGH（高）やMEDIUM（中）のアラートをトリアージし、リソースに余裕ができたときにLOW（低）のアラートに対応します。

Databricksでは、IRチームがこれら3つの優先度レベルすべてにわたるセキュリティアラートに対応しています。これまでは、LOWアラートの量が多く、精度が低かったため、チームはHIGHおよびMEDIUMのアラートを優先的に処理していました。規模の大きいセキュリティチームはどこも、同じトレードオフに直面しています。アナリストの人数を増やすか、アラートのしきい値を上げて見落としを許容するか、あるいはプロセスを自動化する方法を見つけるかです。私たちは後者を選択し、大規模に推論と判断を実行できるエージェントを活用することにしました。

特化型エージェントが必要な理由

エージェントがセキュリティアラートを確実にトリアージし、エスカレーションできるかどうかを検証するため、まずは重要度の低いアラートから開始しました。私たちの目標はシンプルで、さらなる調査が必要なアラートを特定することでした。

最初は単純なアプローチをとり、関連するすべてのアラートデータを1つのプロンプトに入力し、基盤モデルにエスカレーションすべきかどうかを判断させました。しかし、このアプローチではエスカレーション率が50%に達してしまいました。アラートの半分をアナリストに送ることはトリアージとは言えず、単に別のノイズを生み出しているだけでした。

問題はコンテキストでした。単一のエージェントがすべてのアラートに対して推論を行うだけでは、ソースごとに何が異常であるかを区別する方法がありません。アラートを正確にトリアージするために必要なすべての要素（誤検知パターン、行動のベースライン、関連するエンリッチメント情報など）は、ソースごとに固有のものです。そのコンテキストがなければ、モデルは一般的なサイバーセキュリティの知識だけで判断せざるを得ず、それでは正確なトリアージを行うには不十分でした。

アーキテクチャ：エージェント群（フリート）

正確なトリアージに必要なコンテキストはソースに強く依存するため、私たちは17のソース特化型エージェントを中心にパイプラインを再構築しました。各エージェントは単一の検知ソースにチューニングされています。1つのソースから数十の異なる検知が発生することもありますが、それぞれの専用エージェントがそのすべてを処理します。

また、重要度の低いアラートをトリアージするエージェント群と並行して動作する、専用の脅威インテリジェンス（TI）エージェントも用意しています。このTIエージェントは、詳細な調査が必要なインジケーターや挙動に遭遇した際、どのエージェントからでも呼び出すことができます。TIエージェントは当社の脅威インテリジェンスソースにクエリを実行し、「このアーティファクトは既知の悪意あるものか、不明か、あるいは無害か」という構造化された評価を返します。生の侵害インジケーターはコンテキストなしでは意味を持たないため、これは非常に重要です。IPアドレスは単なる数字にすぎません。しかし、その同じIPアドレスに「過去14日間のC2インフラに関連、高確度」という情報がエンリッチメントされれば、エージェントは即座に対処できるようになります。

Databricks上のStructured Streamingを使用することで、重要度の低いアラートはトリガーされると同時にインジェストされ、TIエージェントによって追加のコンテキストがエンリッチメントされた後、レビューのために適切なサブエージェントにルーティングされます。

各エージェントは、同じ設計原則に従っています。

決定論的フィルタリング。プログラムによるチェックがアラートのタイトルやコンテキストフィールドと一致することで、既知の無害なシグナル（信頼できるIPリスト、サービスアカウントのアクティビティ、想定されるツールの動作など、環境固有のニュアンス）を抑制し、LLMを呼び出すことなく即座に処理を決定します。これにより、ソースに応じてアラート量の30〜95%が処理されます。「既知の安全なIAMロールが想定通りの操作を実行している」や「管理者のメールアドレスが日常的なワークスペースガバナンスを行っている」といったケースがこれに該当します。フィルタリングは、検知レイヤー、またはトリアージロジックの直前で行うことができます。

コンテキストのエンリッチメント。LLMがアラートを処理する前に、エージェントは影響を受けるエンティティの最近のアラート履歴、関連するアクティビティ、およびその他の関連シグナルを取得します。エージェントは、エンリッチメント中に他のエージェント機能を呼び出すこともできます。たとえば、アラートに調査対象のIPやドメインが含まれている場合に、専用の脅威インテリジェンスエージェントを呼び出すことができます。

特化型プロンプト関数。各アラートのタイトルは、特定のプロンプト関数にマッピングされます。たとえば、S3の異常アクセスアラートはIAM偵察を評価する指示を持つ関数に送られ、権限昇格アラートは想定内と想定外のロール引き受けパターンを識別できる関数に送られます。専用の関数がマッチしない場合は、汎用のフォールバックプロンプトがアラートを処理します。プロンプト関数は、確実なトリアージのために追加のコンテキストが必要かどうかに応じて、シングルターンモード（1回のLLM呼び出し）またはエージェントモード（マルチターンのツール呼び出しループ）で実行されます。

共有ツール。ツールの使用は任意であり、エージェントごとに固有です。トリアージにさらなるコンテキスト（生のクラウド監査ログ、ソースをまたぐ相関アラート、IdPのアクティビティ履歴など）が必要な場合、エージェントにそれらを取得するためのツールを装備させ、LLMが証拠の曖昧さに基づいてツールを呼び出すかどうか、またいつ呼び出すかを決定します。

共有ユーティリティ。複数のエージェントを維持管理するオーバーヘッドを抑えるため、共有ユーティリティコードを、エージェントの呼び出し、再試行、パフォーマンス評価を処理する共通フレームワークにリファクタリングしました。LLM呼び出しループ、処理のパース、ツールのディスパッチ、Deltaテーブルへの結果の永続化、トークンの追跡、MLflowのトレース、プロンプトインジェクションの検知など、データソース間で共通するすべてのロジックがここに集約されています。

LLMによる推論と処理決定。モデルは証拠パッケージを分析し、裏付けとなる分析結果とともに、処理決定（エスカレーション、監視、またはクローズ）を含む構造化された出力を返します。

コスト管理。支出を抑制するための3つのコントロールがあります。第一に、決定論的フィルタリングにより、既知の無害なパターンに一致するアラートがLLMに到達しないようにします。最も安価な呼び出しとは、決して行わない呼び出しのことです。第二に、コストトラッカーが各バッチの見積もり支出を累積し、設定可能な上限に達した場合は処理を停止し、残りのアラートを「スキップ」として記録します。第三に、1日のアラート上限を設定することで、流入量に関係なく1日の総コストに上限を設けます。各アラートにおいて、カテゴリごとのツール呼び出し予算を設定することで、LLMが追加のコンテキストを無制限に照会し続けるような、暴走した探索ループを防ぎます。

エージェントがエスカレーションを決定すると、アラートはIRキューのチケットになり、アナリストは生のアラートとエージェントの分析の両方を確認した上で、最終的なトリアージを決定します。アナリストがエージェントのエスカレーションに同意しない場合、チケットは誤検知としてラベル付けされ、そのフィードバックはエージェントのパフォーマンス調整に利用されます。その結果、エージェントによってエスカレーションされた重要度「低」のアラートは、既存の「HIGH」および「MEDIUM」として優先順位付けされたアラートよりも、真の陽性である確率が約10倍高いことがわかりました。

エージェントのすべての意思決定を支える人間のベンチマーク

人間のアナリストがエスカレーションされたチケットを確認する際、エージェントの判断を承認するか却下するかという決定が、評価のためのグランドトゥルース（正解データ）になります。固定された仕様に対してテストできる決定論的なプログラムとは異なり、エージェントは判断を行います。同じアラートであっても、実行ごとに異なる出力が生成される可能性があります。そのため、仕様に対してテストするのではなく、高品質なトリアージ決定がどのようなものであるかを熟知しているIRアナリストによって作成された標準データセットに対してテストを行います。

すべてのエージェントリクエストはMLflowを使用して記録され、入力、中間ステップ、および最終出力がキャプチャされます。IRアナリストが通常のワークフローの中でチケットにラベルを付けると、各ラベルは期待される応答として、対応するMLflowトレースに直接記録されます。これらのラベル付きトレースによって、アナリストの判断を大規模に反映したグランドトゥルースデータセットが構築されます。このデータセットは、将来プロンプトの変更をリリースする前に評価するためのベンチマークになります。

誤検知以外の要素も測定するため、アラートの確認とMLflowトレースのラベル付けを行うインターフェースであるDatabricks Review Appを使用する予定です。アナリストは、各アラートに対するエージェントの入力、推論、決定を確認し、期待される結果をトレースに直接記録できます。これにより、アナリストはエスカレーションされなかったアラートも確認できるようになり、エージェントが「監視」または「クローズ」を選択したアラートのグランドトゥルースのカバー率を高め、3つの処理決定すべてにわたる完全な基準を確立できます。

結果

現在、セキュリティエージェントは重要度「低」のアラートの100%を確認しています。主な指標は以下の通りです。

• エージェントは18,000件以上のアラートをトリアージし、エスカレーション率は3.2%でした。
• エージェントがエスカレーションした重要度「低」のアラートは、HIGHまたはMEDIUMの重要度のアラートよりも、真の陽性である確率が約10倍高くなりました。
• トリアージ時間の中央値：10.5秒
• 最初の30日間で6,500時間以上のアナリストの作業時間を削減

エージェントによってエスカレーションされた注目すべき発見：

• あるアラートソースの誤検知率を72%から3.4%に削減
• 22個の不審なドメイン、パーキングドメイン、または悪意のあるドメインを特定
• ユーザーがクラックされたソフトウェアをダウンロードして実行したケースを検出。エージェントは、ポリシー違反や悪意のある意図に合致する行動インジケーターにフラグを立てました。

学んだこと

LLMは、エントロピーの高いセキュリティデータに対してハルシネーションを起こします。ハッシュ、ランダムなサブドメイン、生成されたファイル名などは、言語モデルにとって苦手な分野です。言語にはパターンがあるため、モデルは言語について推論することを得意としています。ハッシュのようなセキュリティアーティファクトは意図的にパターンを排除して作られているため、まさにそれがLLMにとって難解な理由となっています。正確性を確保するため、モデルは記憶の想起ではなく、推論のために使用します。特定のアーティファクトの値は、モデルの記憶からではなく、信頼できる情報源へのツール呼び出しを介して取得されます。

コンテキストが最も重要です。最も大きなパフォーマンスの向上は、過去のアラートデータ、アラートタイプごとの誤検知率、および明示的な行動パターンを各プロンプトに追加したことによってもたらされました。アラートを処理する際、トリアージエージェントは影響を受けるユーザーの過去6か月分のアラート履歴を取得します。いくつかのケースでは、エージェントがアラートをエスカレーションしたのは、トリガーとなった個々のイベントの信頼度が高かったからではなく、同じユーザーからの3番目または4番目の不審なシグナルだったからです。このような行動の相関関係は、従来の決定論的な検知ルールでは捉えるのが困難だったものです。

予測可能なものは自動化し、予測不可能なものだけをエージェントに推論させます。可能な限り決定論的なワークフローを選択し、LLMが確認する必要のある範囲を制限します。指示が自由形式であればあるほど、誤検知率は高くなります。範囲を絞り込んだ段階的なエージェントへの指示は、大まかなプロンプトよりも一貫して優れたパフォーマンスを示しました。LLMがアラートを処理する前にルールベースのフィルタリングを適用することは、この最も効果的な例の1つです。

Databricks上に構築

このシステムはDatabricks上に構築されており、リアルタイムのアラート取り込みにはSpark Structured Streaming、アラートの永続化とレポート作成にはDeltaテーブル、エージェントのすべての意思決定をエンドツーエンドでキャプチャするにはMLflow Tracing、そしてアナリストがトレースにラベルを付け、本番データから直接グラウンドトゥルース（正解データ）を構築できるようにするためにDatabricks Review Appを使用しています。

Databricksでは、自分たちが使用するツールを自分たちで構築しています。これは、自社のプラットフォームがAIネイティブなセキュリティ運用をどのように強化しているかを示す一例です。次回は、Databricks GenieがどのようにSOCに自然言語による調査をもたらし、IRアナリストが会話形式でアラートデータをクエリし、コンテキストを探索し、脅威を調査できるようにするかをご紹介します。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事