提升偵測和報告效能
本文說明如何提升偵測和回報成效。
偵測總延遲時間
對於資安營運中心 (SOC),總平均偵測時間 (MTTD) 是整個安全防護管道的延遲時間總和。如要準確評估及縮短 MTTD,您需要追蹤三個主要元件:
記錄擷取延遲時間 (記錄建立到資料擷取)
記錄擷取延遲時間是指來源系統 (metadata.event_timestamp) 發生安全事件,到 Google Security Operations (metadata.ingested_time) 成功擷取及剖析記錄之間的時間差。
造成這種情況的因素:
- 收集器或轉送器問題 (例如積壓工作或網路節流)。
- 記錄來源剖析問題 (例如 UDM 正規化延遲)。
如要縮短記錄擷取延遲時間,請採取下列做法:
- 監控記錄來源健康狀態,並最佳化收集器或轉送器設定。
- 如要監控差異,請在 YARA-L 或資料湖中比較 UDM 時間戳記 (
metadata.ingested_timestamp與metadata.event_timestamp)。
規則處理延遲時間 (從擷取資料到建立偵測)
規則處理延遲時間是指從資料擷取到偵測引擎成功建立快訊 (detection.creation_time) 所經過的時間。這個元件會受到 YARA-L 規則設定的影響。
造成這種情況的因素:
- 規則執行頻率:接近即時 (最佳)、10 分鐘、1 小時或 24 小時。頻率越高,最低處理延遲就越高。詳情請參閱「設定執行頻率」。
- 規則類型和複雜度:多事件規則需要比對時間範圍才能完整處理,因此會造成延遲。如果複合規則依賴其他非即時偵測結果,也會造成延遲。詳情請參閱「複合式偵測」。
如要減少規則處理延遲,請執行下列操作:
- 盡可能使用近乎即時執行的單一事件規則。
- 如果是多事件規則,請設定盡可能小的時間範圍。
詳情請參閱資訊主頁的 YARA-L 2.0 查詢範例。
YARA-L 規則,用於監控規則處理延遲時間
下列 YARA-L 規則會找出記錄擷取時間與偵測項目建立時間的差異超過特定門檻的執行個體。使用這項規則找出偵測管道中的效能瓶頸。
在測試環境中部署這項規則,做為記錄來源的基準。
您可以將這些結果匯出至資訊主頁,以視覺化方式呈現不同記錄類型的延遲趨勢。
這項規則會比較 metadata.event_timestamp (活動發生時間) 與 metadata.ingested_time (Google SecOps 收到記錄的時間)。
rule rule_processing_latency_monitor {
meta:
author = "SecOps Engineering"
description = "Alerts when the gap between ingestion and detection creation is greater than 15 minutes."
severity = "Low"
events:
$event.metadata.event_timestamp.seconds = $event_ts
$event.metadata.ingested_time.seconds = $ingest_ts
// Calculate the delta in seconds
$latency_delta = $ingest_ts - $event_ts
// Threshold: 900 seconds (15 minutes)
$latency_delta > 900
match:
$event.metadata.log_type over 1h
outcome:
$max_latency = max($latency_delta)
$log_source = array_distinct($event.metadata.log_type)
condition:
$event
}
案件確認延遲時間 (從偵測建立到指派給分析師)
如果您使用 Google SecOps SIEM 獨立平台,則不適用本節內容。
案件確認延遲是指偵測到警示並建立警示後,分析師在 SOAR 元件中確認警示並進行分類所經過的時間。
平均確認時間 (MTTA) 指標專門追蹤 SOC 團隊回應所產生快訊的效率。
- 為縮短案件確認延遲時間,請最佳化快訊路徑、調整和自動化功能 (例如使用應對手冊自動指派或擴充),以便快速將快訊移至分類階段。
後續步驟
- 如要瞭解規則重播 (也稱為清除作業) 如何管理延遲抵達的資料和內容更新,以及這類作業對 MTTD 指標的影響,請參閱「瞭解規則重播和 MTTD」。
- 如要進一步瞭解 Google SecOps 中的規則偵測延遲、影響因素、疑難排解,以及減少延遲的技巧,請參閱「瞭解規則偵測延遲」。
還有其他問題嗎?向社群成員和 Google SecOps 專業人員尋求答案。