用ChatGPT為Sentinel告警做摘要與分流

簡而言之： 把事件本身匯出來——標題、嚴重等級、涉及的實體與關聯告警，而不是原始日誌——讓ChatGPT依「人該先看哪一條」為未處理佇列排序，每條附一段白話說明和下一步該做的檢查。這能把一個讀不完的佇列變成十分鐘讀得完的簡報。但它絕不能自行關閉、隔離或判定任何事件無害。

SIEM完全做到了你買它時想要的事，而問題恰恰在這裡。把身分系統、端點、防火牆和雲端訂閱接進來一個月之後，Microsoft Sentinel產生的事件數量已經超出一個人讀得完的範圍，更別說逐條調查了。偵測在運作，垮掉的是「讀」這一環。

多數中型公司撞上這堵牆的方式都一樣：有一套SIEM，有一位還兼著別的工作的IT經理或資安工程師，而在18:00到隔天09:00之間根本沒有人。佇列在夜裡變長，早上花在草草瀏覽上，而誠實的說法是：低級與中級事件是靠「眼熟」關掉的，不是靠調查。

一層AI摘要能解決的是其中很窄的一部分：在人開始處理之前，把佇列變得可讀、有次序。它不會讓誰變成分析師，也覆蓋不了凌晨三點。把「它解決了哪一半」講清楚，才能讓這件事保持有用而不是危險。

SIEM為什麼會先讓告警疲勞變得更糟

SIEM上線後的頭幾週，是它一生中最吵的時候，而這是預期之內的，不是故障。

開箱即用的規則並不了解你的環境。 每晚02:00從某台伺服器發起驗證的排程備份工作、一位使用境外VPN出口的開發人員、一位正在做合規批次作業的管理員——每一件都會觸發點什麼。規則在普遍意義上是對的，只是在「你」這件具體的事上是錯的。

事件抵達時缺少讓它可判斷的脈絡。 Sentinel會把相關告警歸併成一個事件，並附上實體——帳號、主機、IP、檔案——但某個帳號要不要緊，是一個關於你們組織的問題，而SIEM看不到這一層。

數量本身擊垮了優先順序。 嚴重等級是由觸發的那條規則給的，不是由後果給的。四十條中級事件在清單裡長得一模一樣，而那條牽涉到一個具特權的財務帳號的，和另外三十九條看起來毫無區別。

夜裡沒人在讀。 這才是真正的缺口，而在「讀」這一側堆再多工具也補不上它。值得早點說明白，免得後面的內容被誤當成這個問題的解法。

到這一步，人的直覺是去調規則、壓噪音——這是對的，也確實該做。但調校是一件推進很慢、還要和其他所有事搶時間的工作，而在它推進的同時，佇列每天早上仍然要被讀一遍。

一層AI摘要該放在處置路徑的哪個位置

只有一個位置：在SIEM產出事件之後、在人決定打開哪幾條之前。上游一切照舊，下游一切仍然屬於人。

該餵給模型的是事件，還是原始日誌？

是事件，而且不用多太多。Sentinel的事件紀錄本身已經帶著一份摘要所需的東西：標題與描述、嚴重等級與狀態、偵測所對應的戰術與技術、時間戳記、被歸併進來的告警，以及涉及的實體。這是一個緊湊的結構化物件。

原始日誌表是錯誤的輸入，有三個理由。它體量巨大，於是你為體量付費，又讓模型的注意力從要緊的東西上散掉。它包含的敏感細節遠多於這項分析所需。而摘要的價值本來也不在日誌裡——它在於解釋「這一簇告警看起來加起來是什麼意思」。

再加一樣事件紀錄裡沒有的東西：你們環境的「正常態」。用一小段脈絡說明你們的備份工作在做什麼、員工合法地從哪些地方連線、哪些服務帳號在無人值守地運行、哪些人和系統是真正敏感的——這一段對輸出的改善，超過任何提示詞技巧。沒有它，模型只能套用泛泛的推理，然後每晚都把你們自己的排程工作標出來。

透過Sentinel自己的API、或對事件相關資料表執行KQL查詢把事件拉出來；具體的欄位名稱和查詢介面請以微軟目前的文件為準，不要相信某段程式碼片段——這個平台是會變的。

該跑在Sentinel的自動化裡，還是跑成一個外部腳本？

兩條路都成立，只是適合不同的起點。

Sentinel的自動化規則與劇本（Playbook，建構在Azure Logic Apps之上）可以在事件建立時觸發並呼叫外部API，這是原生路徑，也讓整條流程留在Azure裡——權限和稽核軌跡本來就在那兒。它是更好的長期歸宿，也更費工夫建起來。

而一個排程的唯讀腳本：查詢過去24小時的事件、把整批一次性交給模型、把簡報發到信箱或聊天頻道——這是更快搞清楚「這件事到底有沒有用」的辦法。它還有一個值得刻意保留的性質：它跑在一個唯讀身分上，不往Sentinel裡寫任何東西。

先從腳本開始。等到提示詞不再每隔幾天就改一次、而且簡報真的有人在讀的時候，再把它搬進劇本。

另外值得知道的是：微軟自己也為資安維運提供了AI能力，如果你們本來就在那套授權體系裡很深，它值得按它自己的條件先評估一遍。本文這套做法的成本，是一個下午。

一個實際例子——從嘈雜的佇列到一份排好序的晨報

設想一家約400人的公司，Sentinel工作區接入了Entra ID、Defender、一台防火牆和兩個雲端訂閱，還有一位有資安意識的IT經理。

一夜之間工作區產生了38條新事件，多數是低級與中級。07:30的排程工作查詢最近24小時建立的事件，逐條取出標題、嚴重等級、戰術、內含的告警名稱與實體。這是幾百行結構化文字——一次請求就裝得下。

提示詞給模型三樣東西：這批事件、上面說的環境脈絡，以及一個明確的輸出格式。真正起作用的是格式。要求每條事件產出一個條目，包含：一個排序位次、用兩句話說清這些告警看起來在描述什麼、最可能的無害解釋、人接下來該做的那一項檢查，以及一個把握程度。要求它把它認為屬於同一起底層活動的事件歸成一組。並且要求它明確點名：哪些事件憑所給資料它無法判斷。

08:00落到手上的這份簡報，通常會把那38條事件收斂成大約四簇值得關注的、十來條能說明理由的已知活動、以及少數幾條被標為「無法判斷」的。IT經理十分鐘讀完，打開Sentinel時已經知道該從哪裡開始——處置的順序和以前一樣，只是省掉了那一小時的通讀。

關於這個例子，有兩點必須誠實。那組「已知活動」仍然需要抽查，因為「模型信心十足地把一次真實入侵解釋過去」正是最要命的失敗模式。而且那38條事件在Sentinel裡依然是38條——什麼都沒有被關閉，佇列是變得可讀了，不是變短了。讓它變短是規則調校的工作，這套做法不替代它。同樣形狀的「輔助分流」在服務台場景裡也成立，我們在建置內部IT服務台分流機器人那篇裡寫過。

AI輔助分流 vs 偵測規則調校 vs 7×24小時SOC

多快能看到價值 — AI輔助分流輕鬆勝出。一份唯讀匯出、一段提示詞、一個下午，而另外兩條路是幾週的調校或一輪採購。
減少告警數量 — 偵測規則調校完勝。三者之中只有它能讓佇列真的變短，而不只是更好讀。
解釋一條事件到底意味著什麼 — AI輔助分流勝出。把一簇技術告警變成一句忙碌的IT經理能據以行動的話，正是語言模型擅長的事。
凌晨三點的覆蓋 — 7×24小時SOC勝出，其餘兩者都不沾邊。一份簡報只有在有人讀的時候才成立。
對事件做出判斷並採取行動 — SOC勝出。在一次進行中的入侵裡做遏制，是判斷和動作，不是摘要。
給稽核或保險公司的證據 — SOC、或一套有紀錄的調校計畫勝出。一段聊天紀錄不構成「有人在監控」的證據。
長期成本 — AI輔助分流便宜得多，而它便宜正是因為它做得最少。

這三者是層次，不是替代關係。對一家中型公司而言，現實的順序是：用AI摘要先扛住眼前的佇列，把省下的時間投進規則調校讓佇列變短，再為沒人醒著的那些小時買有人值守的覆蓋。

這套做法絕不能做的事

三條界線，沒有商量餘地。

絕不自動關閉事件。 模型那句「這幾乎肯定是備份工作」，是一個看不到你們流量、工單和上週脈絡的假設。據此關閉會得到一個乾淨的佇列和一種虛假的覆蓋感，那比一個亂糟糟的佇列更糟。

絕不讓它隔離主機、停用帳號或封鎖位址。 回應動作必須落在人的決定之後。一個能憑模型對告警的解讀去隔離機器的自動化，既是新的故障來源，也在能被觸發的那一刻成為攻擊面。

絕不把「很可能無害」當成結論。 把它當成「先從哪裡看起」的一句說明。這個區別聽起來像摳字眼，直到它要緊的那一週。

以及貫穿這三條的一個基本立場：模型只能看見你發給它的東西。任何不在匯出裡的——一條被抑制的規則、一個停止上報的資料來源、一類你從未接入的日誌——對它都是不可見的，而且它不會告訴你少了什麼。

把這件事做對——日誌資料治理、API金鑰，以及什麼時候該讓IT介入

三個值得刻意決定、而不是預設滑過去的問題。

什麼東西離開了你們的租戶。 資安遙測屬於你們持有的較敏感的資料：使用者名稱、主機名稱、內部定址、你們的偵測涵蓋範圍，以及由此暴露的缺口。把它發給一個外部API是一個真實的決定。請有意識地做：去讀你們實際使用的那個產品層級的資料處理與訓練條款，而不是想當然——商業版和企業版通常與消費者版不同，條款也會變。可以考慮在匯出前把帳號名稱與主機名稱做假名化處理，這通常不會損失多少分析價值。如果這些都不可接受，同樣的方法在自架模型上照樣成立；而把AI工作留在合規基礎設施上的這套模式，和資料落地受限市場裡適用的是同一套。

憑證。 用於匯出的身分對Sentinel應當是唯讀、且僅此而已；模型的API金鑰應當屬於一個有獨立計費與用量上限的公司帳號——而不是屬於當初建這套東西的那位工程師。兩者都放進金鑰保管庫，給它們一個輪換日期，並且確保除了建立者之外還有別人知道它們存在。一位已經離職的工程師的個人API金鑰還在悄悄跑著生產工作，是一個反覆出現、又完全可以避免的問題。

沒人醒著的那些小時歸誰管。 這一部分是本文解決不了的。偵測工程、規則調校和有人值守的監控覆蓋，正是一套SIEM與資安監控服務存在的意義，其中就包括那項能讓佇列變短、而不只是更好讀的調校工作。我們的AI+支援服務負責把這類自動化建在受治理的憑證與公司帳號上，我們的託管IT支援負責圍繞它的存取權限生命週期。Brocent自2007年在北京創立以來一直在亞洲提供託管IT與資安服務，總部位於新加坡，並自2016年起設有香港辦公室。

常見問題

把資安日誌資料發給AI工具，本身會不會帶來風險？

會，而且這值得做一個決定，而不是形成一個習慣。一份事件匯出描述了你們的使用者、系統和偵測涵蓋範圍。請把傳送內容壓縮到事件層級欄位、考慮對帳號名稱與主機名稱做假名化、並核對你們實際所用層級的資料處理條款。如果法規或客戶合約不允許，就用自架模型——這套流程並不取決於回答的是哪個模型。

AI能自動關掉誤報嗎？

不能。它可以提出哪些事件看起來像已知活動、並說明理由，這作為閱讀順序確實有用。但「關閉」是一個對稽核軌跡和實際資安態勢都有後果的決定，它必須留在人這裡。

這能降低我們的Sentinel資料擷取費用嗎？

不能——它位於擷取之後，完全不改變你們採集了什麼。擷取成本是一個資料採集與日誌層級的問題：接了哪些資料來源、哪些資料表放在分析層、保留多久。這值得複核，但那是與分流分開的另一件事。

凌晨三點產生的事件怎麼辦？

它們會一直待在佇列裡，直到有人讀那份簡報。這是誠實的答案，也正是為什麼這是「可讀性改善」而不是「覆蓋」。如果非上班時間的回應對你們的風險狀況確實要緊——對多數持有客戶資料的公司來說確實如此——那需要的是由人值守的監控，而不是更好的摘要。

這能替代調校偵測規則嗎？

不能，而把它當成替代品，正是這件事出錯的主要方式。摘要讓一個過吵的佇列變得扛得住；調校讓它變短。用前者去迴避後者，等於你在長期付錢請一個模型，去解釋那些本來就不該被觸發的告警。

我們怎麼知道這些摘要是準確的？

抽查。頭幾週裡，固定打開若干條被模型「解釋過去」的事件，檢查它的推理是否站得住。把簡報保存下來，和調查後的實際結論做對照。如果它對你們環境的判斷是「自信地錯了」，修復辦法幾乎總是更好的環境脈絡，而不是更好的提示詞。

除了Sentinel，別的SIEM能用嗎？

能。除了匯出這一步，本文沒有任何東西是Sentinel特有的——任何能透過API暴露事件與實體的SIEM都能餵進同一套流程。之所以拿Sentinel舉例，是因為它正是被這個問題困擾的中型公司最常部署的平台。

從哪裡開始

挑一週你們已經處置完的事件匯出來，用十句白話寫下你們的環境脈絡。讓它產出那份排好序的簡報，再和你們那一週實際查到的結果做對照。你會很快學到兩件事：這個排序是否和你的判斷一致，以及模型對你們環境的哪些部分一無所知——後者本身就是一份有用的缺口清單。如果結論是「佇列可讀了，但夜裡根本沒人在讀」，那是一個覆蓋問題、而不是工具問題，值得聊一聊——聯絡我們。