LLMs in the SOC 論文閱讀分析：真實分析師到底怎麼把 LLM 用進 Security Operations？

論文基本資訊

• 論文標題：LLMs in the SOC: An Empirical Study of Human-AI Collaboration in Security Operations Centres
• 作者：Ronal Singh、Shahroz Tariq、Fatemeh Jalalvand、Mohan Baruwal Chhetri、Surya Nepal、Cecile Paris、Martin Lochner
• 年份：2025
• 來源：arXiv:2508.18947v2
• 論文連結：https://arxiv.org/abs/2508.18947
• DOI：10.48550/arXiv.2508.18947
• 主題：SOC、Human-AI Collaboration、LLM、Security Operations、Analyst Workflow、NICE Framework

如果前面幾篇 sectools.tw 的文章，多半在問 LLM 會不會做 CTI、能不能做偵測規則生成、能不能幫忙 incident response，那這篇 LLMs in the SOC 值得接著讀的原因很直接：它不是再做一個新 agent，也不是再做一個 benchmark，而是回到更關鍵的問題——真實 SOC 分析師在日常工作裡，到底怎麼使用 LLM？他們把模型當成決策者、搜尋引擎、寫作助手，還是某種介於這些角色之間的 cognitive aid？

這篇論文的價值，在於它提供了少見的「場域內實證」。作者不是在實驗室裡叫受試者完成幾個指定任務，而是分析 45 位 SOC 分析師、10 個月、3090 筆真實查詢，觀察 LLM 是如何逐步滲進安全營運流程。對今天所有在談 SOC Copilot、AI Analyst、human-in-the-loop automation 的人來說，這篇的意義非常大，因為它回答的不是「模型理論上可以做什麼」，而是人真的拿來怎麼用。

這篇論文想解決什麼？

作者點出的缺口很清楚：近年的 security AI 研究，很多都在展示 LLM 可以做 threat intelligence、triage、malware analysis 或 remediation recommendation；但真正落地時，SOC 團隊會不會採用、採用在哪些小任務、怎麼分配信任、哪些地方仍保留人類判斷，其實還缺少長期觀察。

因此，這篇研究的核心問題不是「LLM 好不好」，而是：

• SOC 分析師會把 LLM 用在哪些工作上？
• 這些使用模式是否對應既有的資安職能框架，例如 NICE？
• 分析師與 LLM 的互動是長鏈對話，還是短而快的 micro-interaction？
• 分析師把模型當成建議者，還是把它當成解釋器與脈絡補充工具？

這些問題之所以重要，是因為很多 AI for SOC 的討論容易跳太快，直接從「模型可以」推到「組織應該導入」。但中間其實隔著一整層更細緻的現場現實：分析師願不願意用、在什麼情境下願意用、用完之後是否真的改變工作流。

研究設計：不是 demo，而是 10 個月的真實使用紀錄

這篇最有分量的地方，在於資料不是模擬出來的。作者分析的是一家 24/7 managed detection and response 公司中，45 位 SOC 分析師 透過內部 LLM gateway 使用 GPT-4-0613 的真實紀錄，時間從 2023 年 5 月到 2024 年 3 月，總共蒐集到 3122 筆查詢，清理後保留 3090 筆有效 query 與 532 組 conversation。

參與者職務涵蓋：

• SOC Analyst I
• SOC Analyst II
• Senior SOC Analyst
• SOC Incident Handler
• Threat Analyst
• Associate Analyst

也就是說，這份資料橫跨第一線 triage、進階調查、事件處理與 threat analysis，不是單一角色的偏樣本。

更重要的是，作者並沒有把模型接到內部系統自動執行，而是提供一個受控的 browser-based LLM gateway。分析師可以自由拿它來輔助工作，但仍必須遵守資料分類政策，不能把高敏感資料直接餵進去。這種 setup 很接近很多企業今天真正會採取的導入方式：先把 LLM 當成安全邊界內的輔助介面，而不是讓它直接接手決策與執行。

方法：把 query、conversation、analyst 三層分開看

作者的方法設計相當扎實。他們不是只做粗略統計，而是把分析拆成三層：

• Query-level：分析單一查詢在問什麼、怎麼問、意圖是什麼。
• Conversation-level：分析多輪互動如何展開，觀察分析師是否會逐步 refinement。
• Analyst-level：觀察不同分析師的使用強度、使用風格與整合程度。

在標註方法上，作者用多人協作的 thematic analysis，並在 query pattern、query subject、task 等維度做獨立編碼與 IRR 檢查。像是 Query Pattern 的 Fleiss’ Kappa 達到 0.90，Subject 為 0.82，Task 為 0.79，一致性算是相當不錯。這代表這篇不是只靠作者主觀印象在講故事，而是有用相對嚴謹的質化流程去支撐觀察。

第一個核心發現：LLM 在 SOC 裡主要被拿來做「理解」而不是「判決」

我認為整篇論文最值得記住的一句話，可以濃縮成這樣：

SOC 分析師主要把 LLM 當成 on-demand cognitive aid，而不是高風險判斷的代替者。

從 query 主題來看，最常見的任務不是 asking the model「這是不是惡意」，而是：

• Command Understanding / Analysis / Generation（約 31%）
• Text Generation & Editing（約 22%）
• Code / Script / Regex Analysis（約 11%）

換句話說，分析師最常拿 LLM 來做的是：

• 解釋一段 command 在做什麼
• 幫忙改寫 incident description 或客戶溝通文字
• 看懂 PowerShell、Python、regex 或可疑腳本

這個結果非常關鍵。它說明真正有黏性的使用場景，往往不是那種很戲劇化的「請 AI 幫我判斷這是不是 APT」，而是比較細碎、但高頻且高價值的 microtask：快速補上技術上下文、減少文字整理成本、協助 analyst 把原本就要做的工作做得更順。

第二個核心發現：互動通常很短，LLM 更像工作流中的小工具而不是長對話夥伴

論文的另一個重要發現是，大多數 analyst-LLM interaction 很短。作者指出：

• 41% 是 one-off interaction
• 其餘 59% 雖然形成多步對話，但多數仍很短
• 57% 的 conversation 只有兩步
• 75% 的 conversation 僅有 2–3 個 analyst query
• 只有略高於 4% 的 session 超過 10 步

這說明 LLM 在 SOC 的真實使用型態，並不像很多 agent demo 那樣一路多輪協作。更多時候，它比較像嵌在 investigation 中的一個快速輔助點：

• 看不懂一段命令時問一下
• 整理一段描述時修一下
• 寫 regex 或 query 時補一下
• 理解某個 artifact 時做一次快速 sanity check

這對產品設計很有啟發。它意味著未來真正實用的 SOC LLM 介面，不一定是「一個超級 chat window」，而更可能是深度嵌進現有工作流、能在局部任務上快速回應的 context-aware assistant。

第三個核心發現：93% 的 query 可以對應到 NICE Framework

這篇很漂亮的一個結果，是作者把 analyst query 對照到 NICE Framework for Cybersecurity。結果發現，93% 的 query 可以合理對應到至少一個 NICE task、knowledge 或 skill element；剩下約 7% 多半是閒聊、系統互動或比較邊緣的 miscellaneous 用法。

這個數字代表什麼？代表 LLM 在 SOC 裡的使用並不是隨機或玩票，而是高度對齊既有的專業職能結構。例如：

• command interpretation 對應到 command-line tools 與 techniques 的知識能力
• incident text 編修則對應到有效技術溝通能力

這個結論很值得企業與產品團隊注意。它暗示一件事：未來若要做真正有用的 SOC copilot，與其做一個泛用 chatbot，不如沿著 NICE role / task / skill 去客製化，讓輔助能力直接貼齊 analyst 的工作職能。

第四個核心發現：分析師要的是 evidence 與 context，不是模型幫他下結論

全篇最成熟的地方，在於作者沒有被「AI 決策」這個敘事帶走。論文顯示，只有大約 4% 的 query 明確要求模型給 recommendation，例如問「這是不是 malicious」或「這是不是 threat」。即使只看最熱門的 command analysis 類查詢，要求明確 recommendation 的比例也只有約 3%。

這意味著多數分析師真正想從 LLM 拿到的，不是 verdict，而是：

• 解釋
• 脈絡
• 功能理解
• 證據導向的補充資訊

這點和很多近年談 human-AI teaming 的研究其實是對得上的：在高風險決策場景中，人通常不希望 AI 直接替自己拍板，而是希望 AI 幫忙把證據攤平、把理解速度加快。

對 SOC 來說尤其如此。因為 analyst 最在意的不只是答案本身，而是：

• 這段 command 為什麼可疑？
• 哪個參數值得注意？
• 和哪類 technique 或 workflow 有關？
• 我還需要查哪些 log 或 artifact 才能做 escalation？

所以作者提出的設計方向很務實：對 investigative task，介面應該預設採 evidence-first，而不是 recommendation-first。

第五個核心發現：導入是漸進式的，而且高度不平均

論文也呈現一個很真實的組織現象：LLM adoption 並不平均。45 位分析師的使用強度差異很大，作者用 query count 做分群後，大致分成：

• 低使用群：34 人
• 中度使用群：10 人
• 高強度 outlier：1 人

其中最活躍的單一分析師大約貢獻了總資料集 17% 的 query。不過，這不代表只有少數人在玩。到 2024 年初，45 位分析師都至少用過一次，而且每月活躍使用者數持續上升，顯示整體 adoption 確實在發生。

這種不平均其實很合理，因為不同 analyst 的任務結構、偏好、對文字工作的需求，以及對 AI 的信任程度本來就不同。作者也觀察到，有些人偏向把 LLM 當 writing assistant，有些人偏 command/code interpretation，有些人則只有在特定 investigation 場景才會叫出來用。

這代表未來 SOC LLM 導入不應該假設 everyone uses the same copilot in the same way。更合理的做法是承認 analyst 之間本來就有不同 integration style，並讓工具支援這種差異。

我怎麼看這篇論文？

我認為這篇論文最有價值的，不是證明「LLM 很強」，而是幫整個 AI for SOC 討論補上一塊長期缺失的拼圖：真正的使用行為證據。

如果只看近年的資安 AI 論文，我們很容易形成一種錯覺，以為未來 SOC 的主角會是全自動 agent，從 triage 到 response 全部包辦。但這篇的訊息比較成熟，也更可信：目前 LLM 在 SOC 裡最自然的位置，並不是 fully autonomous operator，而是高頻、低摩擦、補脈絡的認知輔助者。

這種角色其實不低階，反而非常重要。因為 SOC 的痛點從來不只是「缺少答案」，更常是：

• artifact 太多、理解太慢
• 上下文切換太頻繁
• 文件與溝通成本太高
• 分析流程裡有大量細碎但必要的 cognitive overhead

而 LLM 如果能把這些 friction 降低，即使它沒有直接接管判斷，也已經足夠有價值。

這篇論文的限制

當然，這篇也有幾個必須保留的地方。

1. 單一組織、單一部署條件

資料來自單一 MDR 組織，而且使用的是特定的 GPT-4 gateway setup。不同 SOC 的工具鏈、文化、權限政策與案件型態都不同，因此結果不能直接外推到所有 SOC。

2. 研究重點是「怎麼用」，不是「用得多有效」

這篇沒有直接衡量 analyst 用了 LLM 之後，是否真的縮短 triage time、降低誤判、提升 investigation quality。它回答的是 usage pattern，而不是 outcome improvement。

3. 只分析 analyst query，不正式評估 LLM response 品質

這是作者刻意的研究選擇。好處是聚焦 human side，壞處則是無法細緻回答「哪些用法真的有效、哪些只是主觀上覺得方便」。

4. 初期採用階段可能帶有新鮮感效應

作者自己也承認，部分 adoption 可能受到 pilot 階段的新鮮感影響。要判斷這種 usage 會不會長期穩定，還需要更長時間的後續研究。

對實務者的啟示

如果你在做 SOC 平台、MDR 產品、內部 AI 助理或資安自動化，這篇論文給的啟示其實非常具體：

• 優先做 microtask support，而不是先做 autonomous SOC dream：最有黏性的場景往往是 command 解釋、文字修訂、腳本理解、查詢撰寫。
• 把 assistant 嵌進工作流，而不是叫分析師切去另一個聊天世界：短互動、高頻率，意味著 context switching 成本很重要。
• 預設提供 evidence 與 context，而不是直接給 verdict：分析師仍希望保留決策主權。
• 沿著 NICE Framework 客製化，比做泛用 chatbot 更有機會落地：因為真實查詢本來就高度對齊職能能力。
• 接受 analyst 之間會有不同 adoption style：不是每個人都會同樣頻繁、同樣深地依賴 LLM。

總結

LLMs in the SOC 不是一篇在炫技的論文，它的價值恰恰在於不炫技。它告訴我們，今天 LLM 真正開始進入 SOC，不是因為它已經能全自動接管事件處理，而是因為它在很多細碎但關鍵的工作節點上，已經能成為分析師的即時認知輔助。

從 45 位分析師、10 個月、3090 筆真實 query 得到的訊息相當一致：

• 分析師主要用 LLM 來理解 technical artifacts 與加速技術溝通
• 大多數互動都很短，屬於 on-demand micro-interaction
• 93% 的 query 與 NICE 專業職能對齊
• 只有極少數查詢是在要求模型直接做惡意／非惡意判決
• LLM 在 SOC 裡更像 evidentiary aide，而不是 autonomous decision-maker

如果把這篇放進最近 sectools.tw 追的脈絡，它剛好補上了很重要的一層：在 benchmark、agentic system、CTI pipeline、IR orchestration 之外，真正的落地問題其實是 human-AI collaboration 怎麼發生。 而這篇論文給出的答案很務實，也很值得記住：

未來真正有機會在 SOC 穩定落地的，不一定是最會做決策的 AI，而可能是最會在正確時刻補上證據、解釋與上下文的 AI。

免責聲明

本文由 AI 產生、整理與撰寫。 內容主要依據公開論文、arXiv 頁面與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。