有日誌不代表有偵測,有警報不代表有回應。Detection engineering 是把原始事件轉化為可行動、有 owner、可量測 MTTD/MTTR 訊號的過程。
先談 logging,再談 detection
沒有結構的日誌無法擴展。四個原則:
- 結構化 JSON,使用標準欄位:
timestamp、service、env、request_id、user_id(已 hash/redact)、action、result。 - Correlation ID 貫穿服務、gateway、queue——使用 W3C Trace Context。
- 不要 log 原始 secret/PII。在共用 SDK 輸出 stdout 之前就 redact。
- 敏感操作 (admin action、key access、資料匯出) 要有獨立的稽核日誌——schema 不同、retention 較長 (12-36 個月)。
應該串到 SIEM 的關鍵日誌來源
| 來源 | 偵測價值 |
|---|---|
| Cloud audit (CloudTrail、Activity Log) | 異常 IAM、key 建立、出現於陌生 region |
| K8s audit log (Metadata level) | RBAC 變更、exec 進入 pod、secret 存取 |
| Identity provider (Okta、Azure AD) | 暴力破解、impossible travel、MFA 繞過 |
| 應用程式稽核日誌 | 權限提升、大量資料匯出 |
| Falco / Tetragon | 容器 runtime 行為 |
| WAF、CDN、gateway | 暴力破解、scraping、anomaly |
Sigma:detection-as-code
Sigma 是用來描述偵測規則的標準 YAML 格式,獨立於 SIEM (可轉換為 Splunk SPL、ELK Lucene、Sentinel KQL 等)。範例:
title: K8s exec into production pod
id: 1f0e3aa8-...
status: stable
logsource:
product: kubernetes
service: audit
detection:
selection:
verb: create
objectRef.subresource: exec
objectRef.namespace|startswith: prod-
condition: selection
level: high
tags:
- attack.execution
- attack.t1609 # container administration command
把規則存在 git 中,透過 PR 審查,加上 CI 測試 (positive/negative case)。這就是detection-as-code。
對應到 MITRE ATT&CK
ATT&CK 把攻擊者行為分為 tactic (目標) 與 technique (手法)。把偵測對應到 ATT&CK 的好處:
- 知道自己在哪些 tactic 缺乏偵測 (例如 Initial Access 強,但 Lateral Movement、Exfiltration 弱)。
- 對照 threat intel:鎖定我們所在產業的 APT 群組常用什麼 technique → 優先補上對應偵測。
- 向管理層報告覆蓋率時更具體:「對我們的技術堆疊相關 technique 覆蓋率達 65%」。
IR runbook 與 tabletop 演練
NIST PICERL 應變週期:Preparation → Identification → Containment → Eradication → Recovery → Lessons learned。每份 runbook 都應包含:
- Severity matrix:SEV1/2/3 對應的回應 SLA。
- 明確的 on-call rotation 與升級路徑。
- 溝通範本:status page、客戶通知、主管機關通知 (越南個人資料保護法 第13/2023/NĐ-CP 號政令:72 小時)。
- 證據保全:磁碟/記憶體快照、複製日誌、匯出稽核——在刪除/還原之前。
- 依事件類型的 containment playbook:secret 外洩、帳號淪陷、ransomware、資料外流。
每季舉辦 1-2 次 tabletop 演練,每次 60-90 分鐘,使用 1 個真實情境。量測:偵測時間 (MTTD)、抑制時間 (MTTC)、還原時間 (MTTR)。
無責備 post-mortem
目標不是找人懲罰,而是找出讓事故發生的系統條件。參考範本:
- 摘要 (3-5 行)。
- Timeline:誰、做了什麼、何時 (UTC timestamp)。
- Impact:使用者、資料、財務。
- Root cause:contributing factor (通常多個,而非單一)。
- What went well:承認做得好的地方以強化。
- Action item:有 owner、實際 deadline,進入 sprint backlog。
無責備文化需要領導者保護——若回報者被懲罰,下次就沒人敢誠實說了。
Bug bounty 與 purple team
內部偵測之外的補強:
- 透過
security.txt+security@email 提供 responsible disclosure:便宜又免費。 - 使用 HackerOne/Intigriti 或在地平台的 bug bounty:scope 與 payout 明確。
- Purple team 演練:red team 跑一個 technique,blue team 量測是否能偵測,然後一起 tune 規則。互相學習,不計分數。
應該量測的指標
- 依事件類型的 MTTD。
- 依 severity 的漏洞 MTTR,以及符合 SLA 的比例。
- 警報 true positive 率 (預防警報疲勞)。
- 依 tactic 的 ATT&CK 覆蓋率。
- Tabletop 頻率、post-mortem action item 準時完成的比例。
結論
Detection engineering 與 IR 是 DevSecOps 與 SOC 交會的地方。把規則當程式碼 (Sigma + git + CI)、把 runbook 當產品 (審查、版本化、量測 MTTR),並守護無責備文化。如此一來,每場事故都會成為改善系統的燃料,而不是引起恐慌的事件。