CyberAlly 論文閱讀分析：把 Knowledge Graph 與 LLM 真的放進藍隊 Incident Response 工作流
論文基本資訊
- 論文標題：CyberAlly: Leveraging LLMs and Knowledge Graphs to Empower Cyber Defenders
- 作者：Minjune Kim 等
- 年份：2025
- 來源：WWW Companion 2025 Demo Track / arXiv:2504.07457
- 論文連結：https://arxiv.org/abs/2504.07457
- DOI：10.1145/3701716.3715171
- 主題：Blue Team、Incident Response、Knowledge Graph、LLM、SOC、SIEM、KG-RAG、Cyber Range
如果前幾篇 sectools.tw 追的主線，重點多半放在 CTI benchmark、情資知識、agentic investigation、偵測規則生成，那這篇 CyberAlly 的價值在於把焦點移到更貼近藍隊現場的一層：當告警洪流已經出現、分析師正在 Slack 裡協作、SIEM 不斷丟出事件時，LLM 與知識圖譜能不能真的幫忙減少告警疲勞、補上上下文、加速 incident response？
這篇論文不是又做一個泛泛的資安聊天機器人，而是把系統放進 cyber range + SIEM + Slack + case management 的實際工作流裡，讓 AI 不只回答問題，而是跟著藍隊一起處理告警、提出建議、解釋理由，甚至幫忙建立 ticket。從研究脈絡看，它很像是把「知識圖譜輔助 LLM」從靜態問答，推進到人機協作式 incident response。
這篇論文想解決什麼？
作者一開始就點出三個 SOC 與藍隊工作最痛的地方：
- 告警重複且雜訊很多：大量 benign 或重複 alerts 會造成 alert fatigue。
- 告警缺乏上下文：單一 alert 往往不足以支撐分析師快速判斷下一步。
- 現場缺少能真正融入協作流程的 AI：不是只會分類，而是要能在對的時間給出對的建議。
作者把研究場景設定在 Red vs. Blue Team cyber range，而且特別聚焦在海事／港口相關的 IT 與 OT 混合環境。這一點很重要，因為這代表他們不是在理想化的純 IT demo 網路裡測試，而是在更接近關鍵基礎設施的情境下思考 incident response。也因此，CyberAlly 的目標不是取代分析師，而是把 AI 放進藍隊決策迴路裡，協助做三件事：
- 過濾重複與低價值告警
- 把靜態與動態知識串起來，補足上下文
- 在實際協作介面裡給出可執行的建議與理由
CyberAlly 的整體架構在做什麼？
如果把整個系統流程濃縮成一條線，大致可以寫成：
Wazuh SIEM alerts
↓
重複告警過濾
↓
良性 / 可疑二元分類
↓
Knowledge Graph + RAG 擷取上下文
↓
LLM 生成建議、說明與處置方向
↓
Slack 互動呈現
↓
必要時建立 Cydarm case ticket
↓
藍隊採納、執行、回饋這個設計最值得注意的地方，是它不把 LLM 當作單點模型，而是放在一個完整工作流中。也就是說，CyberAlly 的價值不只來自 GPT-4o 本身，而是來自它前面有 alert filtering，後面有 knowledge graph、Slack 協作、ticket 建立與人類決策。這種系統觀點，比單純拿 benchmark 分數更接近真正可落地的 SOC 輔助工具。
一、先解決告警洪流：Alert Filtering 與 Classification
作者先處理最現實的問題：如果 AI 連大量重複告警都沒辦法先消化，後面的建議再漂亮也沒有用。
CyberAlly 的第一層是文字嵌入驅動的兩階段 alert handling：
- Duplicate filtering：先把 alert message 映射到向量空間，用 cosine similarity 找出高度相似的重複告警。
- Binary classification：再把剩下的 alerts 分成 benign 與 suspicious。
論文中採用的是相對務實的方法，而不是堆很重的模型：去重後的分類器使用 kNN（k=15），並搭配 30 分鐘 time window 與惡意樣本上採樣處理 class imbalance。這裡其實透露出一個很重要的工程訊號：作者不是把焦點放在「做出最花俏的模型」，而是放在能否先穩定降低藍隊看到的噪音。
在資料規模上，作者提到一次 2 天的訓練事件中蒐集了 超過 6 萬筆 alert messages，其中只有大約 2,500 種 distinct alert types。這個數字本身就已經說明為什麼去重重要：真正困擾分析師的，往往不是資訊太少，而是大量重複訊號遮蔽了真正該看的事。
二、這篇論文真正的核心：Knowledge Graph-Enhanced RAG
如果說前面的 alert filtering 是降噪，那 CyberAlly 的靈魂就是後面的 KG-RAG。
作者不是只做一般 RAG，而是設計了兩個子圖：
- Static graph：來自過去 Red vs. Blue Team 事件、歷史經驗、既有基礎設施知識。
- Dynamic graph：反映目前這一場演練／事件中的 alerts、Blue Team 行動、case management ticket、change management ticket，以及當下系統狀態。
這個設計很漂亮，因為它解決了很多 security AI 系統的老問題：只靠歷史知識不夠新，只靠即時訊號又不夠懂脈絡。 CyberAlly 想做的，是把「過去怎麼處理過類似事件」和「現在這一刻系統正在發生什麼事」一起餵給模型。
換句話說，CyberAlly 裡的知識圖譜不是展示品，而是扮演真正的上下文樞紐：
- 把 alert 與系統架構關聯起來
- 把目前事件與過往事件關聯起來
- 把分析建議與 case handling 流程關聯起來
對 incident response 來說，這比單純「把 MITRE ATT&CK 文件塞進 RAG」更有價值。因為藍隊真正需要的，往往不是一般知識，而是這個 alert 在這個環境裡代表什麼、之前怎麼處理過、接下來該不該開 ticket、該先動哪個系統。
三、LLM 在這裡扮演什麼角色？
作者在實作上使用 GPT-4o，但我認為這篇最值得學的地方，不是「用了哪一個模型」，而是他們讓模型輸出什麼。
CyberAlly 在 Slack 介面中提供三類核心輸出：
- Alert summary：幫分析師快速補齊情境與背景
- Recommended actions：提出可執行的處置建議，甚至包含 command-line 方向
- Explanation and reasoning：解釋為什麼會給出這些建議，讓分析師能判斷是否採納
這一點非常關鍵。很多安全 AI 工具敗在只給結論、不給脈絡。CyberAlly 則明確把「建議」和「理由」綁在一起。對藍隊來說，這不是 UX 細節，而是信任問題：如果 AI 不能說明它為什麼建議你封鎖、調查、建立工單，那在高風險環境裡很難被真正採納。
四、Slack 與 Cydarm 整合：這篇不是單純做模型，而是在做 workflow
CyberAlly 另一個很強的地方，是它沒有把系統停留在研究原型頁面，而是直接整合到藍隊本來就在用的協作介面。
在論文描述中，系統會：
- 監控 Wazuh 丟進 Slack 的 alerts
- 對可疑事件產生摘要與建議
- 提供 reasoning 供分析師判斷
- 必要時協助在 Cydarm case management system 建立 ticket
- 最後蒐集使用者回饋
這種設計代表作者真正理解 incident response 的工作單位不是「單一模型輸出」，而是協作、交接、記錄、追蹤與回饋。也就是說，CyberAlly 比較像一個嵌入藍隊工作台的 AI teammate，而不是一個外掛聊天室。
五、這篇論文真正的亮點：Human-AI Teaming，而不是全自動取代
我認為這篇文章最成熟的地方，是它從頭到尾都沒有把論述做成「AI 全自動接管 SOC」那種過度承諾。相反地，作者很清楚地把 CyberAlly 定位為：
一個知識圖譜增強的 incident response assistant，用來增強藍隊效率與判斷品質。
這種 framing 很重要，因為在資安現場，真正有價值的通常不是 fully autonomous replacement，而是：
- 先減少低價值工作量
- 再把上下文補齊
- 最後讓人類把時間花在高價值判斷
從這個角度看，CyberAlly 與其說是在展示 LLM 很強，不如說是在展示：如果把 LLM、知識圖譜、SIEM 與 case management 用對方式接起來，人機協作確實可以比單純人工更有效。
六、限制在哪裡？
當然，這篇也有幾個應該保留的地方。
1. 這是一篇 Demo Track 論文，不是大規模長期實證
這代表它的貢獻比較偏向系統展示與可行性驗證，而不是經過長時間、多組織、多環境的嚴格量化評估。所以我們應該把它看成很有價值的原型與方向證明，而不是已經完成產業級驗證的產品報告。
2. 評估資料高度來自特定 cyber range 與演練場景
這使得系統上下文很豐富，但同時也意味著外部泛化能力還需要更多證明。真實企業 SOC 的告警型態、工單流程、基礎設施複雜度，通常會比研究型演練環境更混雜。
3. alert filtering 與建議品質仍仰賴底層資料品質
若 SIEM 規則品質不佳、事件關聯缺漏、知識圖譜維護不完整，後面的 LLM 再強也很難穩定輸出好建議。這再次證明：資安 AI 的瓶頸常常不是模型本身，而是資料與流程工程。
4. command-level 建議雖然實用，但也提高了治理要求
當系統開始提供 shell-based mitigation suggestions 時，組織就必須更認真面對審核、權限隔離與人類覆核機制。這不是缺點，而是所有 AI-for-operations 系統都必須正視的控制面問題。
這篇論文對實務者的啟示
如果你在做 SOC、CSIRT、cyber range、AI assistant 或 SecOps automation，CyberAlly 給的啟示非常具體：
- 先處理 alert overload，再談 AI 智慧化：沒有前面的降噪，後面的 assistant 很容易只是更吵。
- 單純 RAG 不夠，最好把環境關係顯式建模：知識圖譜的價值，在於把過去事件、系統架構、目前狀態與處置流程串起來。
- AI 建議一定要附 reasoning：否則分析師很難信任，也難以在高壓場景中採納。
- 把 AI 放進現有協作工具，而不是另開孤島介面：Slack 與 case system 整合，是 CyberAlly 很實際的成功點。
- 真正可落地的方向是 human-in-the-loop：不要迷信全自動，先把分析師的決策速度與品質提升起來，通常更有價值。
總結
CyberAlly 雖然不是那種用龐大 benchmark 打分數的論文，但它非常值得放進最近的 CTI / AI / SOC 主線裡看。原因很簡單：它回答了一個比「模型答題準不準」更實際的問題——在藍隊真的忙著處理告警時，知識圖譜增強的 LLM 能不能作為 incident response 協作夥伴發揮作用？
作者給出的答案是偏正面的，但前提很清楚：這個系統要建立在alert filtering、KG-RAG、工作流整合、可解釋建議與人類最終判斷之上。也就是說，CyberAlly 的價值不是「又一個安全聊天機器人」，而是把 AI 真正塞進藍隊處置鏈裡，嘗試讓它成為可用的工作同伴。
如果前幾篇 benchmark 類論文在回答「模型懂不懂 CTI」，那 CyberAlly 更像是在回答下一個層次的問題：
當告警真的來了、票真的要開、分析師真的要做決策時，AI 能不能在正確的位置補上上下文與建議，而不是只會做一場離線 demo？
免責聲明
本文由 AI 產生、整理與撰寫。 內容主要依據公開論文、arXiv 頁面與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文僅供研究交流與知識分享參考；實際技術細節、系統設計與最終結論，仍應以原始論文、正式出版版本與作者公開資料為準。