使用Databricks上的專業代理擴展安全警報分類

安全團隊面臨的一個常見難題是：低嚴重性的安全警報因數量龐大且噪聲過高，往往被擱置不處理。Databricks的安全團隊也不例外，但他們決定改變這一現狀。他們構建了一套基於AI代理的自動分類系統，專門針對低嚴重性警報進行精準分流。

最初，他們採用了一個簡單的方案：將所有警報數據放入一個提示中，讓基礎模型決定是否升級。結果升級率高達50%，這實際上是另一種形式的噪聲，而非有效的分類。問題在於缺乏上下文——每個警報源都有獨特的假陽性模式和行為基線，單一模型無法區分。於是，他們轉向了專用代理架構。

團隊構建了17個源特定的分類代理，每個代理針對一個具體的檢測源（如端點安全、雲活動日誌等）進行調優。這些代理在Databricks的Spark Structured Streaming上實時運行。處理流程分為幾個關鍵環節：

• 確定性過濾：通過程序化規則匹配警報標題和上下文，壓制已知良性信號（例如受信任的IAM角色執行常規操作），這部分處理了30%到95%的警報量，完全不依賴LLM調用。
• 上下文豐富：在LLM介入之前，代理會提取受影響實體的近期警報歷史，並可以調用共享的威脅情報代理來查詢IP或域名的背景信息。
• 專用提示函數：每個警報類型映射到特定的提示函數，例如對S3異常訪問使用IAM偵察評估指令，對權限提升使用角色假設模式判斷。如果無匹配，則使用通用回退提示。
• 共享工具：當需要額外上下文時，代理可以調用工具獲取原始雲審計日誌、跨源關聯警報或身份提供商標歷史。LLM根據證據的模糊性決定是否及何時調用這些工具。
• LLM推理與決策：模型分析證據包，輸出結構化的處理決定（升級、監控或關閉），並附上支持性分析。

成本管理方面，系統設定了三重控制：首先，確定性過濾防止良性警報到達LLM；其次，批次成本追蹤器在達到設定上限時自動停止處理；第三，每日警報上限限制總成本。此外，每個警報內還有按類別劃分的工具調用預算，防止無限的上下文查詢循環。

每個代理的決策都會被MLflow記錄，包括輸入、中間步驟和最終輸出。當分析師審查升級的工單時，他們的確認或否決成為評估基準。這些標註數據構成標準數據集，用於評估未來的提示變更。團隊計劃使用Databricks Review App進一步擴展覆蓋範圍，包括非升級警報的標註。

在30天的運行中，系統處理了超過18,000個警報，升級率僅為3.2%。被升級的低嚴重性警報的真陽性率比傳統高/中優先級警報高出約10倍。中位分類時間為10.5秒，節省了超過6,500分析師小時。值得注意的發現包括：將某個警報源的假陽性率從72%降至3.4%，識別出22個可疑域名，並捕獲了一個用户下載並使用破解軟件的案例。

團隊總結的經驗包括：LLM在高熵安全數據（如哈希值、隨機域名）上容易產生幻覺，因此應僅用於推理，具體值通過工具調用從權威源獲取；上下文是性能提升的關鍵，添加歷史警報數據和行為模式大幅提高了準確性；應儘可能自動化可預測的部分，讓LLM只處理不確定性高的環節。整個系統完全基於Databricks平台，利用Spark Structured Streaming實現實時數據攝入，Delta表進行持久化，MLflow Tracing進行端到端追蹤，以及Review App供分析師標註。