Databricks上の専門エージェントによるセキュリティアラートトリアージの拡大

セキュリティチームはすべてのアラートを調査できるわけではなく、特に低重要度のアラートは量が多くノイズも多いため、ほとんど未調査のまま放置されがちです。Databricksのセキュリティチームはこの問題に対処するため、AIエージェントを活用した自動トリアージシステムを構築しました。

最初は単一のプロンプトにすべてのアラートデータを入れて基礎モデルに判断させる単純なアプローチを試みましたが、エスカレーション率が50%に達し、効果的なトリアージとは言えませんでした。問題はコンテキストの欠如でした。各アラートソースには固有の偽陽性パターンや行動ベースラインがあり、それを考慮しないと正確な判断は下せません。そこで、17のソース固有エージェントからなるアーキテクチャに移行しました。

各エージェントは特定の検出ソースに最適化されており、DatabricksのSpark Structured Streaming上でリアルタイムに動作します。処理は以下の段階を経ます：

• 決定論的フィルタリング：プログラムによるチェックで既知の良性シグナル（信頼できるIPリスト、通常のサービスアカウント活動など）を抑制します。これにより、ソースに応じて30%から95%のアラートがLLMを呼び出すことなく処理されます。
• コンテキスト拡張：LLMがアラートを確認する前に、エージェントは影響を受けるエンティティの最近のアラート履歴を取得し、必要に応じて専用の脅威インテリジェンスエージェントを呼び出してIPやドメインの背景情報を取得します。
• 専門化されたプロンプト関数：各アラートタイプに固有のプロンプト関数が対応します。例えば、S3の異常アクセスはIAM偵察評価用の関数に、特権昇格は役割引き受けパターン判断用の関数にマッピングされます。一致する関数がない場合は汎用フォールバックプロンプトが使用されます。
• 共有ツール：エージェントは必要に応じてクラウド監査ログやクロスソース相関アラート、IdP活動履歴などの追加コンテキストを取得するためのツールを呼び出すことができます。LLMは証拠の曖昧さに基づいてツール呼び出しのタイミングを決定します。
• LLM推論と処分：モデルは証拠パッケージを分析し、エスカレーション、監視、クローズのいずれかの処分をサポート分析とともに構造化出力として返します。

コスト管理には3つの制御があります。第一に、決定論的フィルタリングにより良性アラートがLLMに到達するのを防ぎます。第二に、コストトラッカーがバッチごとに推定コストを蓄積し、設定された上限に達すると処理を停止します。第三に、1日あたりのアラート上限により、着信量に関わらず総コストに上限を設定します。さらに、アラート内のツール呼び出しにはカテゴリごとの予算が設定され、無限の探索ループを防止します。

各エージェントの判断はMLflowを使用して記録され、入力、中間ステップ、最終出力がキャプチャされます。インシデント対応アナリストがエスカレーションされたチケットをレビューする際、その確認または却下がグラウンドトゥルースとして機能します。これらのラベル付きトレースは、将来のプロンプト変更を評価するためのベンチマークデータセットを形成します。

30日間の運用で、エージェントは18,000以上のアラートを処理し、エスカレーション率はわずか3.2%でした。エージェントがエスカレーションした低重要度アラートの真陽性率は、従来の高/中優先度アラートの約10倍でした。中央値トリアージ時間は10.5秒で、6,500時間以上のアナリスト時間を節約しました。注目すべき発見として、あるアラートソースの偽陽性率を72%から3.4%に低減し、22の不審なドメインを特定し、ユーザーがクラックされたソフトウェアをダウンロード・実行したケースを捕捉しました。

学んだ教訓として、LLMは高エントロピーなセキュリティデータ（ハッシュ値、ランダムサブドメインなど）に対して幻覚を起こしやすいため、推論にのみ使用し、具体的な値はツール呼び出しで取得すべきです。コンテキストが最も重要であり、過去のアラートデータや行動パターンを追加することでパフォーマンスが大幅に向上しました。予測可能な部分は自動化し、エージェントは不確実な部分のみを推論するようにすべきです。このシステムはDatabricksプラットフォーム上に構築され、Spark Structured Streaming、Deltaテーブル、MLflow Tracing、Review Appを活用しています。