安全誤報的真相

引言

近年來，“假陽性”在我們的生活中出現了一些意想不到的體現。當然這里指的是新冠疫情，它需要進行大規模的核酸檢測活動，來控制病毒的傳播。根據記錄，假陽性指的是檢測結果是陽性，但檢測者的實際情況卻是陰性（未被感染）。通常，“誤報”是該情況更為常見的說法。

在計算機安全方面，我們也經常面臨著誤報所帶來的困擾。當提問到SIEM背后的安全團隊“在工作上遇到的最大挑戰是什么？”時，答案大概率會是“誤報”。最近的一份報告估計，安全專業人員收到全部預警中，大約有20%都是誤報，而這大大增加了安全人員的工作量。

然而，誤報背后的故事并不像表面看起來的那樣簡單。本文中我們主張，在對一個分析工具進行評估時，適當的誤報率往往意味著一個相對較好的結果。

我們到底在說什么？

在應用程序安全的靜態分析中，我們主要關注的是通過分析源代碼來捕獲所有真實的漏洞。 

下圖是一個可視化結果，可以幫助我們更好地把握靜態分析的兩個基本概念之間的區別：查準率和查全率。放大鏡內部區域中的點表示由檢測工具識別或選擇的樣品。該圖可以幫助我們更好地搞清楚如何評估系統統計程序的性能。 

從工程學的角度來看，該圖體現了以下幾點內容：

• 減少誤報，可以提高查準率（所有檢測到的漏洞實際上都是真實確切的安全隱患）
• 減少誤報，可以提高查全率（所有存在的漏洞都能被正確地檢測到）
• 查全率100%時，檢測工具不會錯過任何一個漏洞。
• 查準率100%時，檢測工具不會發出任何一個錯誤的預警

換句話講，漏洞掃描儀的目標就是使放大鏡中內部的區域盡可能地靠近左邊的矩形區域（相關元素）。

然而，最佳方案往往是無法明確的，這就意味著必須要做出權衡。問題是：哪一方面更加重要呢？查準率的最大化，還是查全率的最大化？

哪種情況更糟糕呢？過多的誤報，還是過多的漏報？

為了更好地了解其中的原因，我們把情況分為兩個極端：假設一個檢測工具只有在給定的代碼片段存在漏洞的概率高于99.999%時，才會提醒用戶。有了如此高的閾值，那么幾乎可以肯定該預警確實是一個真實的漏洞。但是由于掃描儀的選擇性，又會有多少安全問題被忽略呢？答案是：很多。

現在反過來考慮，如果檢測工具被設置為：不錯過任何一個漏洞（最大查全率）。那么又會發生什么呢？結果就是：該組織很快就會面臨成百上千的誤報。而這也同樣是一件風險極高的事情。

正如伊索在他的寓言《狼來了》中警告世人的那樣，任何一個反復發出虛假警報的人，其話語都不會被再次相信。在現實世界中，這種不再受信任的表現就體現在：安全人員會單純地關閉安全預警，而不去理會它，或者說如果無法關閉的話，就直接忽略該預警。然而，其后果也同樣會像寓言中的那樣具有戲劇性，甚至更加嚴重。

 實際上，“安全預警疲勞”大概是導致靜態分析失敗率較高的最大原因。可以說，誤報背負了太多的“罪名”，以至于人們總會錯誤地認為：只要檢測工具不再發出任何誤報，那么一切問題就會迎刃而解了。  

學會接受誤報

想要學會接受誤報，就必須要克制住那些促使我們過早下結論的本能。一個思維實驗可以幫助說明這一點：假設要比較兩個安全掃描儀A和B的性能。在基準測試上運行這兩個工具后，結果如下：A掃描儀只檢測到了有效的漏洞，而B掃描儀則同時檢測到了有效漏洞和無效漏洞。僅根據這一點來判斷，哪一臺掃描儀會更容易得出表象結論呢？這要求安全人員必須足夠地明智，并且在做出決策之前還需要參考更多的數據。根據這些數據，你很可能會發現：B結果報告中的一些有效內容，在A報告中卻被忽略掉了。

現在，你大概就可以體會到本文的言外之意了：任何聲稱自己不會出現誤報的檢測工具、程序或安全公司，其本身都是可疑的。如果情況真是這樣的話，那么也就意味著某些安全相關內容被忽略的可能性也非常高。

在查準率和查全率之間找到一個平衡點是一個很復雜的問題，需要大量的調整工作。（推薦去了解Gitguardian工程師是如何提高模型精度的）不僅如此，在尋找平衡點的過程中偶爾出現的失誤，也是相當正常的。這就是為什么說，相比起存在少量誤報，沒有誤報才是最該令人擔心的。

同時，誤報也暗示了一個有趣的事實：安全永遠不是非黑即白的。一定存在著一個我們所不知道的領域。在該領域中，人工作業發揮著更大的左右。

由于現代軟件的某些性質，組織總會得到一些誤報。當誤報出現時，開發者可以簡單地將其標記。誤報是測試用例的一部分，我們完全可以忽略這些困擾。

安全永遠不是非黑即白的，總有一個我們所未知的領域，在那里人工審查和分類至關重要。換句話講，重要的并不僅僅是原始數據，如何去利用它們也同樣非常關鍵。從這個角度來看，誤報也是具有一定價值的。它們有助于對檢測工具和算法進行公司近，以便更好地理解和考慮安全上下文。然而，正如漸近線那樣，絕對值0（0誤報）是永遠無法到達的。

還有一個必要的條件，就是要把那些看似是困難的東西轉化為良性的循環。也就是說，你必須要確保這些誤報是可以被標記的，并且能夠盡可能簡單地整合到檢測算法中。實現這一目標最常見的方法之一就是單純地從掃描的邊緣排除文件、目錄以及存儲庫。

專業從事機密檢測的GitGuardian工作人員表示，他們推動了該想法，為的是能夠在盡可能多的背景下獲取更多的發現，從而加快反饋周期，并盡可能地減輕繁重的工作負載。

若開發人員利用客戶端安裝的ggshield作為預提交的hook，來提交機密，那么該提交便會被攔截，除非開發人員將其標記為要忽略的機密。從那時起，該機密就會被視為誤報，并且該誤報以后都不會被再次觸發，但其適用范圍也僅限于該開發人員的本地工作站。只有那些能夠訪問 GitGuardian決策面板的安全團隊成員才能在整個團隊范圍中標記誤報。

一旦出現了機密泄露，組織會提供工具來幫助安全團隊進行迅速的處理。例如，自動修復機制會自動向泄密的開發人員發送郵件。根據機制的配置，開發人員可以獨立做出決策，解決問題或忽略警報，這在一定程度上也減輕了安全團隊的工作量。

上述的一些例子都啟示著我們要學會繞過誤報來調整檢測和修復的過程，而不是癡迷于消除誤報。在統計學中，有一個專有的名詞來描述這種癡迷，即過擬合。這意味著組織的模型過于依賴特定的數據集，由于缺乏現實世界的輸入，該模型在生產環境中已不再適用。

總結

誤報通常會導致安全預警疲勞以及安全程序的損壞，以至于它被普遍地認為是百害而無一利。的確，當對某個檢測工具進行評價時，組織往往會追求一個更高的查準率，畢竟誤報過多的檢測工具是弊大于利的。話雖如此，但也同樣不要忽略查全率的重要性。

GitGuardian的安全團隊設計了一種通用的檢測過濾器，用來提高機密檢測的查全率。從純粹的統計學視角來看，較低誤報率是一個相當好的跡象，這意味著存在的“漏網之魚”極少。

在受控情況下，誤報并沒有多么地糟糕。它們甚至可以用來提升組織的某些優勢。因為這些誤報表明了該組織無論是在分析方面還是修補方面，都存在著可以改進的地方。

搞清楚為什么系統會發出誤報，并找到一種有效的解決方案，才是提高應用程序安全性的關鍵。相信這是安全和開發團隊在協作方面真正關鍵的領域之一。

總而言之，請記住：如果你的檢測工具不存在任何的誤報，那么就請趕快舍棄它，因為它很可能會給你帶來更大的麻煩。 

數世點評

正如漏洞檢測的查全率和查準率無法同時達到100%的理想狀態一樣，我們往往也無法通過有限的信息，來對安全檢測工具的實際效率得出一個完全精準的評估。從本質上來講，誤報給安全團隊帶來的更多是負面影響，誤報也的確是一種應被盡可能解決的問題。而本文則提供了一個外部視角，側面地通過誤報情況來獲取更多有關檢測工具或安全情況的潛在信息。也正如文中所講，安全永遠都不是非黑即白的。這是因為安全是由眾多因素所共同影響的，我們永遠也永遠無法兼顧所有的方面。但是對于可把控的因素，從多個方面來充分挖掘其中的有效信息，從而提升整體的安全，卻是可以做到的。