為什麼告警疲勞才是真正的 SOC 問題——而且其實是企業問題
告警疲勞不是 SOC 的不便,而是企業風險
當資安領導者談到告警疲勞時,討論通常只停留在 SOC 內部:分析師精疲力竭、儀表板被紅色填滿,以及 MTTR 一季又一季地上升。這樣的描述並沒有錯,只是看得太小了。
在企業層級——包括金融服務業、製藥、半導體與大型製造業——告警疲勞不是單純的營運不便,而是會出現在資產負債表、稽核發現,以及董事會討論韌性的議題中的企業風險。
當資安領導者談到告警疲勞時,討論通常只停留在 SOC 內部:分析師精疲力竭、儀表板被紅色填滿,以及 MTTR 一季又一季地上升。這樣的描述並沒有錯,只是看得太小了。
在企業層級——包括金融服務業、製藥、半導體與大型製造業——告警疲勞不是單純的營運不便,而是會出現在資產負債表、稽核發現,以及董事會討論韌性的議題中的企業風險。
資安團隊並不缺告警。他們缺的是時間、脈絡與注意力。
一項針對 2,058 位資安領導者的 2025 年調查發現,59% 的受訪者表示收到太多告警,52% 則形容自己的 SOC 團隊工作過量。Security Magazine 的研究摘要 也指出,許多團隊因為資安資料難以管理、分散在不同工具中,而在調查過程中損失大量時間。
人員承受的代價同樣明顯。在 2025 ISC2 Cybersecurity Workforce Study 中,48% 的受訪者表示,為了跟上最新威脅與技術而感到疲憊;47% 表示經常被工作量壓得喘不過氣。ISC2 的研究 共調查超過 16,000 位資安專業人員與決策者。
這就是告警疲勞:每一則通知開始看起來都一樣,每一項調查都像是緊急事件,而分析師花在決定「哪些可以忽略」的精力,甚至比判斷「哪些真正重要」還多。
這不是某一家公司的特殊問題,而是影響各地資安團隊的運作問題。
星期一早上 9:02,對外公開的防火牆開始記錄連接埠掃描。
到了 9:05,SIEM 已經產生 5,000 個告警。IT 負責人打開儀表板,看見一整面紅色,於是問了每個小型資安團隊最後都會問的問題:
「我們不能直接在 SIEM 上面加一層 AI,讓它告訴我們哪些事情重要嗎?」
這是個合理的問題。事實上,在 SIEM 之上加入 AI 確實是正確方向。現有的 SIEM 已經收集事件、套用偵測規則並保存證據;AI 層可以把這些輸出轉化為優先順序、解釋與下一步行動。
這正是 SIEM+ 的定位:為已經使用 SIEM、希望改善告警分流與安全態勢可視性的團隊,提供不需要替換既有 SIEM 的 AI 資安覆蓋層。
真正重要的是,你加入的是什麼樣的 AI 層。
通用聊天機器人、一次性的 LLM 腳本,或鬆散連接的 AI copilot,可能可以對單一告警產生令人印象深刻的回答。但資安運作需要更持久的系統:它必須記住脈絡、分組相關證據、遵守資料邊界、追蹤長期態勢,並產生人員能採取行動、日後也能提出佐證的輸出。

在資安產業,我們有一個很糟糕的習慣:把「數量」等同於「風險」。當傳統 SIEM 儀表板顯示 10,000 個告警時,狀態指示燈轉紅、態勢分數跌到零,主管也跟著恐慌。
但任何 Tier-1 SOC 分析師都知道,針對一個對外公開 IP 的簡單自動化連接埠掃描,就能在三分鐘內產生 5,000 筆原始防火牆拒絕記錄。那不是 5,000 個獨立的重大威脅,而是一個低層級事件。
當我們打造 SIEM+(siem.plus)時,我們知道如果只是把原始告警數量餵進 UI,就會重現我們原本想消除的「告警疲勞」。我們需要一種方法,把資料湖中的雜訊轉化為能在董事會議桌上使用、並真正反映風險的指標。
以下深入介紹 SIEM+ 動態安全態勢分數、懲罰衰減演算法,以及我們如何迫使 LLM 將威脅映射到合規框架,同時避免幻覺。

台灣意德勤股份有限公司(イベントス株式会社、Eventus Taiwan Limited) 很高興參加 TECH BEAT Shizuoka 2026。這個平台連結靜岡縣內企業與新創公司,透過合作與開放式創新,共同創造新的價值。
本次活動中,我們展示兩項協助企業活用營運資料的方案:提供資安可視性與回應能力的 SIEM+,以及支援 IoT 資料收集與應用程式開發的 SEKHMET。