前言：為什麼企業需要 SIEM 與 SOC？
面對日益複雜的資安威脅，單純依靠防火牆與防毒軟體已不足以應對。勒索病毒、APT 攻擊、內部威脅等多樣化的攻擊手法，要求企業必須具備即時偵測、關聯分析與快速回應的能力。SIEM（Security Information and Event Management，安全資訊與事件管理）與 SOC（Security Operations Center，資安監控中心）正是為此而生的解決方案。
根據 IBM《2025 年資料外洩成本報告》，未建置 SIEM 的企業平均需要 287 天才能偵測並控制資安事件，而部署 SIEM 搭配 SOC 的企業可將此時間縮短至 174 天——減少超過 100 天的暴露時間，直接降低數百萬元的潛在損失。
一、SIEM 是什麼？核心功能解析
SIEM 是一套整合「安全資訊管理（SIM）」與「安全事件管理（SEM）」的平台，其核心功能包含：
1. 日誌收集與正規化（Log Collection & Normalization）
SIEM 的基礎是從各種來源收集日誌資料，並將不同格式統一為標準化格式，以利後續分析。常見的日誌來源包括：
- 網路設備：防火牆（FortiGate、Palo Alto）、交換器、路由器、IDS/IPS
- 伺服器：Windows Event Log、Linux Syslog、Web Server Access Log
- 端點設備：EDR/XDR 代理程式、防毒軟體、DLP 系統
- 身份驗證系統：Active Directory、LDAP、SSO、VPN 閘道
- 雲端服務：Microsoft 365 稽核日誌、Azure AD 登入日誌、AWS CloudTrail
- 應用程式：ERP、資料庫系統、郵件伺服器
日誌收集可透過 Syslog、SNMP Trap、Windows Event Forwarding（WEF）、API 整合或代理程式（Agent）等方式進行。建議採用集中式日誌收集架構，設置 Log Collector 作為中繼站，降低 SIEM 主節點的負擔。
2. 關聯規則引擎（Correlation Engine）
單一日誌事件往往不具備足夠的威脅判斷力。SIEM 的關聯規則引擎會將多個來源的事件進行交叉比對，識別出潛在的攻擊模式。例如：
- 暴力破解偵測：同一來源 IP 在 5 分鐘內對不同帳號產生 50 次以上登入失敗
- 橫向移動偵測：某帳號在短時間內登入多台不同伺服器，且存取了過去從未觸及的資源
- 資料外洩偵測：非營業時段出現大量對外資料傳輸，且目標 IP 為已知惡意網域
- 帳號異常：同一帳號從地理位置相距甚遠的兩個 IP 同時登入（Impossible Travel）
進階的 SIEM 平台還支援 UEBA（User and Entity Behavior Analytics），利用機器學習建立使用者行為基準線，自動偵測偏離正常模式的異常行為。
3. 即時告警與儀表板（Alerting & Dashboard）
SIEM 會根據關聯規則的觸發結果產生告警，並依嚴重程度分級（Critical / High / Medium / Low / Informational）。有效的告警管理需要：
- 告警分級：依資產價值、威脅等級、信心度進行多維度評分
- 告警歸併：將相關告警合併為單一事件，避免分析師被淹沒在大量重複通知中
- 告警路由：依類型自動分派給對應的分析師或團隊
- 誤報調校：持續優化規則，降低誤報率（False Positive Rate），目標維持在 20% 以下
4. 日誌保存與合規（Retention & Compliance）
許多法規與標準要求企業保存特定期間的日誌紀錄：
- 資通安全管理法：至少保存 6 個月
- ISO 27001：依風險評估決定保存期限
- PCI DSS：至少保存 1 年，其中 3 個月需可即時查詢
- 金管會規範：金融業日誌須保存至少 5 年
SIEM 應規劃熱儲存（Hot）、溫儲存（Warm）、冷儲存（Cold）三層架構，在查詢效能與儲存成本之間取得平衡。
二、SIEM 架構設計
典型的 SIEM 部署架構包含以下元件：
小型企業架構（EPS < 2,000）
EPS（Events Per Second）低於 2,000 的環境，可採用 All-in-One 架構：
- 單一 SIEM 主機負責收集、分析與儲存
- 搭配 1-2 台 Log Collector 進行日誌中繼
- 適合 100-500 人規模企業
- 硬體需求：16 核 CPU、64GB RAM、4TB SSD 以上
中大型企業架構（EPS 2,000-50,000）
當 EPS 超過 2,000 時，建議採用分散式架構：
- 收集層：分佈在各據點的 Log Collector，負責接收、壓縮與轉發日誌
- 處理層：SIEM 核心引擎叢集，負責關聯分析與告警產生
- 儲存層：獨立的儲存叢集（如 Elasticsearch），提供高效搜尋與長期保存
- 展示層：Web Console 與 API，供分析師操作與第三方整合
SIEM 產品比較
| 產品 | 授權模式 | 適合規模 | 特點 |
|---|---|---|---|
| FortiSIEM | 資產數 | 中小型 | 與 Fortinet 生態深度整合，內建 UEBA |
| Splunk Enterprise Security | 資料量 | 中大型 | 強大搜尋語言（SPL），豐富的 App 生態 |
| Microsoft Sentinel | 資料量（雲端） | 中大型 | 雲原生，深度整合 Microsoft 365 / Azure |
| Elastic Security | 節點數 / 開源 | 各規模 | 開源核心，彈性擴展，社群規則豐富 |
| IBM QRadar | EPS | 大型 | 成熟的關聯引擎，強大的合規報表 |
三、SOC 建置與維運
SIEM 是工具，SOC 是運用這些工具的團隊與流程。建置 SOC 需要從人員、流程、技術三個面向規劃。
1. SOC 人員配置
典型的 SOC 團隊分為三個層級：
- L1 分析師（Triage）：負責初步告警分類與過濾，判斷告警是否為真正的資安事件。通常需要 1-3 年資安經驗
- L2 分析師（Investigation）：對 L1 上報的事件進行深入調查，進行威脅情資比對與影響範圍評估。需要 3-5 年經驗
- L3 分析師（Hunting & Response）：主動進行威脅獵捕（Threat Hunting），處理進階威脅，並優化偵測規則。需要 5 年以上經驗
對於中小企業而言，建立全職 SOC 團隊的成本極高。可考慮以下替代方案：
- MDR（Managed Detection and Response）：委託專業資安服務商進行 7x24 監控與回應
- Hybrid SOC：內部配置 1-2 名資安人員，搭配外部 MDR 服務補足人力缺口
- MSSP（Managed Security Service Provider）：完全委外的資安監控服務
2. SOC 標準作業流程
SOC 的核心流程通常遵循 NIST 事件回應框架：
- 準備（Preparation）：建立 Playbook、培訓團隊、測試工具
- 偵測與分析（Detection & Analysis）：監控告警、調查事件、判斷嚴重程度
- 遏制、消除與復原（Containment, Eradication & Recovery）：隔離受影響系統、清除威脅、恢復服務
- 事後活動（Post-Incident Activity）：事件報告、根因分析、改善措施
3. SOAR 自動化回應
SOAR（Security Orchestration, Automation and Response）是 SOC 提升效率的關鍵工具。常見的自動化劇本包括：
- 自動封鎖惡意 IP（整合防火牆 API）
- 自動隔離受感染端點（整合 EDR）
- 自動查詢威脅情資（VirusTotal、AbuseIPDB）
- 自動產生事件報告與通知相關人員
- 自動重設遭入侵帳號的密碼（整合 AD）
四、關聯規則實務設計
良好的關聯規則是 SIEM 發揮價值的關鍵。以下分享幾個實務中常用的規則設計思路：
基於 MITRE ATT&CK 的規則設計
將關聯規則對應到 MITRE ATT&CK 框架的戰術與技術，可確保偵測覆蓋率的完整性：
| ATT&CK 戰術 | 偵測場景 | 關鍵日誌來源 |
|---|---|---|
| Initial Access | 釣魚郵件附件被開啟 | 郵件閘道 + 端點 EDR |
| Execution | PowerShell 執行可疑指令 | Windows Event 4688 / Sysmon |
| Persistence | 排程任務或服務被建立 | Windows Event 4698 / 7045 |
| Lateral Movement | 異常 RDP / SMB 連線 | Windows Event 4624 + 防火牆 |
| Exfiltration | 大量資料上傳至外部 | Proxy / 防火牆流量日誌 |
降低誤報的技巧
- 白名單機制：將已知安全的 IP、帳號、程式加入白名單，減少不必要的告警
- 時間窗口調整：根據實際環境調整偵測時間窗口，避免過度敏感
- 多條件組合：要求多個條件同時滿足才觸發告警，提高精確度
- 資產價值加權：對關鍵伺服器的告警給予更高權重，聚焦重要事件
- 定期審查：每月檢視告警統計，停用或調整效果不佳的規則
五、建置步驟與時程規劃
SIEM / SOC 專案建議分階段實施：
第一階段：基礎建設（1-3 個月）
- 選定 SIEM 平台並完成安裝
- 接入核心日誌來源（防火牆、AD、VPN、伺服器）
- 啟用內建的基礎關聯規則
- 建立告警通知流程
第二階段：擴展覆蓋（3-6 個月）
- 擴大日誌收集範圍（端點、雲端、應用程式）
- 客製化關聯規則，對應 MITRE ATT&CK 框架
- 建立 SOC 標準作業流程（SOP）與 Playbook
- 導入威脅情資饋送（Threat Intelligence Feed）
第三階段：優化成熟（6-12 個月）
- 導入 SOAR 自動化回應
- 啟用 UEBA 行為分析
- 進行紅隊/紫隊演練驗證偵測能力
- 建立 KPI 指標（MTTD、MTTR、誤報率）持續改善
六、常見挑戰與對策
- 日誌量爆炸：採用分層儲存與日誌過濾策略，只將有價值的事件送入 SIEM 分析
- 告警疲勞：持續優化規則、導入 SOAR 自動處理低風險告警、設定合理的閾值
- 人才短缺：善用 MDR 服務補足人力，內部人員專注於策略層級的決策
- 授權成本：精確評估 EPS/資料量需求，選擇適合的授權模式，避免超量付費
- 跨廠牌整合：優先選擇支援 CEF / LEEF / Syslog 標準格式的設備，降低整合難度
重點摘要
- SIEM 是工具（日誌分析），SOC 是團隊（監控+回應）
- 有 SIEM 沒 SOC 等於有雷達沒人看
- 中小企業不建議自建 SOC，用 MDR 託管服務更划算
- Microsoft Sentinel + MDR 是中小企業的高 CP 值選擇
有任何問題，歡迎與我們討論。
預約免費資安架構評估 →