漏報溯源通常有哪些環節

漏報溯源通常有以下這些環節：

• 單點的檢測手段不足是絕大多數人都會想到的，可能是檢測規則寫得不夠好，對某些情況沒有考慮到，補充相關場景的檢測規則即可。例如只做了rootkit檢測，而沒有考慮諸如“不利用任何第三方可執行文件實現的反彈shell”就屬于這一類情況。

• 單點的檢測深度如果沒有問題，那么可能的原因是單維度的數據不足以捕捉事件，或者單維度數據不足以精確剔除誤報，這個時候就要引入其他維度的數據作對比，典型的例子比如SQL注入，在CGI層面要對抗HTTP編碼問題，單維度的WAF數據還不夠，可能需要從SQL層引入第二層檢測，兩個維度疊加后出結果。更常見的webshell則有很多維度。

• 在大型互聯網中，單點的深度和檢測維度都沒有問題，而是出問題的機器上還沒安裝和運行相關的檢測產品，全網的部署覆蓋率才50%，剩下的50%在這幾個維度是裸奔，所以被人捅了馬蜂窩。這個問題其實也無解，只有加速提升覆蓋率。反過來說，單點的檢測方案再美好，因為影響了性能和可用性推廣不了，最后都等于沒有。所以把安全的功能和檢測能力放在第一位的方案往往不是最優解。

• 進程掛了，模塊掛了，數據同步漏了。最后的結果就是出問題時正好漏過了，一方面可能是因為產品本身的健壯性比較差，另一方面可能是設計不夠好，體積臃腫，垃圾數據大堆，真正的數據利用率很低。

• 覆蓋率100%，但是數據質量不高，導致的誤報很多，有價值的信息也被淹沒了。質量不高有兩層含義：第一層數據源跟檢測目標的相關性不強，傳統的SOC里采集了大量的數據，但很多信息不是安全強相關，也不足以判斷到底發生了什么，這種數據就沒什么用。比如防火墻的日志里一大堆數據包分片的告警，在海量的環境下純屬垃圾信息。第二層含義是模糊告警太多，很多中低風險疑似觸發安全策略的告警，需要通過手工做大量驗證，整體上ROI很低。人有習慣效應，告警刷屏多了又不是嚴重告警，人會自動“選擇性忽略”，這樣還不如沒有。

回答所涉及的環境：聯想天逸510S、Windows 10。