【公益譯文】安全控制評估自動化支援：軟體漏洞管理（二）

本文為NISTIR 8011第4卷，詳細介紹瞭如何自動評估與軟體漏洞管理安全能力相關的安全控制措施，以便管理軟體缺陷帶來的網路風險。上一篇我們軟體漏洞管理（VUL）能力定義、概述和範圍，今天，我們來講一下VUL資料需求示例及VUL相關的運營實施概念。

2.4 VUL資料需求示例

VUL能力的期望狀態是：已知漏洞列表準確、完整，包含最新資訊；所有裝置上安裝的軟體產品均無已知漏洞。實際狀態的VUL能力資料需求的示例見表1。期望狀態的VUL能力資料需求示例見表2。

 表1.   VUL實際狀態資料需求示例

表2.   VUL期望狀態資料需求示例

該值由組織根據其分配給資產的值定義。有關裝置屬性的說明，參見[IR8011-1] 。

組織可以為本地環境定義資料需求和相關漏洞。

有些已知漏洞可透過不安裝部分程式碼段、可執行檔案或透過配置選項有效緩解。

如果可以透過檢查登錄檔設定、可執行雜湊或配置設定來確定是否已實施替代緩解方法，則可以制定規範，自動驗證是否存在漏洞。

2.5 VUL相關的運營實施概念

VUL識別網路裝置（實際狀態）中實際存在的軟體（包括虛擬機器上的軟體），將這些軟體與期望狀態列表對比，明確軟體中存在哪些已知漏洞（或缺陷），並安裝補丁（或其他緩解方法），降低系統漏洞的可利用性。

軟體漏洞管理能力運營概念（CONOPS）定義瞭如何實現VUL能力，是自動化評估流程的核心。請參見圖1。

圖1.   VUL運營概念（CONOPS）

2.5.1         採集實際狀態

ISCM資料採集流程利用工具識別補丁級別的網路裝置中的軟體檔案（和產品），包括大容量儲存器和韌體中的軟體。這些工具進一步提供必要資訊，將實際軟體與發現的補丁級別（實際狀態）與授權的補丁級別（期望狀態）進行比較。本節透過舉例介紹用於識別實際和期望補丁級別的方法。

同時，ISCM資料採集流程還會明確目標網路的監控範圍和頻率，最終確定完整性和及時性度量標準。裝置可能因為以下各種原因而無法監控：（1）裝置未聯網，可能在特定掃描過程中檢測不到；（2）裝置關掉；掃描過程中發生錯誤；（3）裝置位於掃描範圍之外的被保護地區；（3）裝置在預期IP地址範圍之外（若掃描器掃描特定範圍）；等等。請注意，若列表資料質量可接受，可依據硬體資產管理（HWAM）能力列表檢查掃描範圍。

需對所有能力的實際狀態資料進行有效配置管理。附錄G介紹如何對實際狀態進行配置管理。附錄G中列出的控制元件為VUL能力評估流程的元控制元件。

2.5.1.1   作業系統軟體資料庫的實際狀態資料

有一些組織將作業系統軟體資料庫（OSSD）作為軟體版本的實際狀態資料的來源。不過，OSSD的多個執行特徵可能會在軟體版本識別過程導致如下錯誤：

• 軟體未列入OSSD。裝置中有些軟體未在OSSD中列出（即，軟體由於未列入OSSD而無法被OSSD識別）。

• OSSD條目無法識別安裝的所有軟體。對於特定產品版本來說，不同安裝介質例項可能會安裝稍有差別的可執行檔案，因此可能存在不同漏洞。OSSD可能檢測不到這一點。

• 產品解除安裝過程可能會刪除OSSD中的軟體檔案條目，但不會刪除所有程式碼。解除安裝過程中存在的問題可能會導致OSSD無法識別的裝置仍存在漏洞程式碼，因此這些程式碼可被利用但不會被OSSD發現。

• OSSD不包含共享程式碼。使用OSSD無法解決共享程式碼的問題，使用共享程式碼開發的程式若安裝了補丁，可能會導致共享程式碼發生變化。參見2.5.2.6節。

2.5.1.2   漏洞掃描器提供的實際狀態資料

漏洞掃描是在實際狀態中查詢CVE的最常用方法之一。漏洞掃描器將存在漏洞的軟體檔案版本列表與系統裝置上的實際軟體檔案版本進行對比。

為確保風險識別的準確性，建議對漏洞掃描器功能進行驗證，保證掃描結果的可靠性。漏洞掃描器驗證過程包括以下步驟：

·       確保組織編寫的漏洞掃描器可檢查大部分已知漏洞。否則，該漏洞掃描器可能會漏報漏洞。組織將掃描器發現的漏洞與NVD進行對比，明確該掃描器發現的已知漏洞的百分比，並將該百分比納入掃描器採購流程。

·       確保掃描器的誤報率和漏報率在可接受範圍內。沒有任何一項測試是百分百可靠。掃描器掃描漏洞時可能會上報不存在的漏洞（誤報），也可能不上報確實存在的漏洞（漏報）。採購流程中要評估掃描器的誤報率和漏報率。一般情況下，誤報率和漏報率成反比—一個較高，另一個必然較低。需平衡兩者，也就是說，避免過多誤報和過多漏報。

·       確保新漏洞發現時，漏洞掃描器廠商及時提供更新，而且掃描器可快速更新，提供新的檢測程式碼。請注意，檢測（掃描）和響應（安裝補丁）對於實現有效漏洞管理來說不可或缺。

2.5.1.3   軟體白名單提供的實際狀態資料

若能獲得有漏洞軟體檔案的數字指紋，我們可根據數字指紋製作軟體檔案列表，從而準確、可靠地識別裝置中的軟體數字指紋。更多詳情，參見2.5.2.3節。

軟體白名單中資料的主要問題是：截至本文寫作時，NVD或廠商對明確包含已知漏洞的軟體檔案尚未提供任何數字指紋。

2.5.1.4   程式碼分析器提供的實際狀態資料

靜態和動態程式碼分析器（參見術語表）用於識別可能成為漏洞的編碼缺陷。通常，在軟體執行前部署程式碼分析器（即在系統工程/系統開發生命週期早期），原因是在開發早期修復發現的缺陷成本較低。

若組織無法控制原始碼但希望評估購買的產品（或考慮購買的產品）是否採取了安全設計，通常會部署動態程式碼分析器識別和診斷安全缺陷。組織在模擬生產的測試環境中部署採購的程式碼（最好在最終採購決策前），根據其風險承受能力評估缺陷是否可接受。

2.5.2         採集期望狀態資料

VUL能力的期望狀態為將可接受軟體檔案版本列舉出來，將網路中已安裝軟體的已知缺陷限制在組織的風險承受範圍內。因此，對於網路中的所有軟體檔案來說，要定義期望狀態需知曉如何確定存在最少已知缺陷的最佳版本（即補丁級別）。正如下述資料採集方法所述，期望狀態的識別是個持續演進過程，需納入和整合多個來源的資訊，有時，還需根據具體情況考慮組織的風險承受能力。

每項能力的期望狀態資料都需要有效配置管理。附錄G介紹瞭如何對期望狀態進行配置管理。附錄G中的控制元件為VUL能力評估過程的元控制元件。

2.5.2.1      國家漏洞資料庫（NVD）

VUL能力的期望狀態是儘可能使用無缺陷（CVE）軟體，而NVD是CVE的重要資訊來源。每個CVE都有唯一識別符號，NVD是CVE的權威性來源。由於NVD資料為網上公共資源，多方均透過下載NVD資料並結合其他資料識別和修復漏洞，如包含CVE的軟體檔案特徵、CVE相關文章或CVE補丁號。

2.5.2.2      漏洞掃描器

除了提供實際狀態資料（參見2.5.1.2節），漏洞掃描器也能提供期望狀態資料。漏洞掃描器從NVD上獲得CVE資訊、將CVE與包含CVE漏洞的軟體的識別符號相關聯，檢查聯網裝置上的軟體是否存在CVE緩解補丁，從而檢測出系統內聯網裝置的軟體存在的已知漏洞。就特定掃描而言，期望狀態指軟體中不存在CVE漏洞。

說明：任一漏洞掃描器可能只檢測一部分已知漏洞，所以各檢測器對期望狀態的定義不盡相同。

2.5.2.3      開發人員包清單

漏洞掃描器具備商業可行性的其中一個原因是，掃描器在掃描時，將裝置上的程式碼與已知包含CVE的程式碼進行比對，提供的結果與實際情況較為接近（可接受精度範圍內）。包清單若列明每個檔案的數字簽名，則提供了更可靠的CVE漏洞識別方法和修復補丁。開發人員一般會針對每個版本提供以下補丁級檔案列表資訊：

·       版本中的CVE漏洞。

·       列明包含每個漏洞的軟體檔案、含有漏洞修復的檔案以及每個檔案的數字指紋。

若提供補丁級清單資訊，掃描器可非常準確地描述裝置上漏洞的實際狀態（CVE漏洞）和期望狀態（具體應包含哪些檔案以及這些檔案的補丁級別）。若採取補丁級廠商清單，非常有可能降低漏洞掃描錯誤率（誤報和漏報）。補丁級清單可基於SWID標籤編制。

2.5.2.4      批准的補丁級別列表

有些組織會直接編制一份已批准（和必要）補丁列表。該核准的補丁列表即為期望狀態。任何缺乏必要補丁和/或其他緩解措施的軟體都被標記為有漏洞軟體。該補丁列表基於組織的風險承受能力編制，需要手動管理該列表。

2.5.2.5      CWE（編碼缺陷）資訊

CWE相關的VUL能力的期望狀態是軟體中不存在與組織的風險承受能力不一致的CWE。CWE資訊採集和響應是自定義軟體開發過程的重要環節。若廠商不太可能發現並上報軟體漏洞，則CWE資訊對於組織計劃部署的商業軟體至關重要。有關發現CWE（實際狀態和期望狀態）的工具，見2.3.2節。

2.5.2.6      共享程式碼

解決共享程式碼問題可進一步減少軟體漏洞帶來的風險。組織可識別不同產品更新的軟體檔案，並將所識別的軟體檔案與使用共享程式碼的一個或多個產品的漏洞列表進行比較，從而確定補丁中的共享程式碼檔案是否達到期望狀態。

2.5.3         發現缺陷/進行優先順序排序

VUL能力側重於將評估邊界（實際狀態）內發現的軟體物件版本與應該存在的最新軟體物件版本列表（期望狀態）進行對比，並確定響應的優先順序（通常對存在漏洞的軟體打補丁）。期望狀態軟體物件是為了將未修補漏洞的風險降至最低而選擇的版本。使用商業漏洞掃描器（一般內建CVE漏洞和補丁資訊）比較實際狀態和期望狀態是最常用的方法，但在漏洞管理中，其他缺陷（如組織明確須修復的CWE）可能會被程式碼分析器錯誤地識別為未知漏洞。無論如何，完成實際狀態與期望狀態比較後，都要確定的缺陷進行優先順序排序，以便採取合理響應措施（如首先解決高風險問題）。

2.6 支援VUL的NIST SP 800-53控制措施和控制項

本節介紹如何明確支援VUL能力所需的NIST SP 800-53控制措施和控制項，並介紹用於描述各控制措施和控制項重點關注的軟體漏洞的術語。

2.6.1      必要控制措施確定流程

本NISTIR第1卷中的3.5.2節“安全控制項與能力”中詳細描述了用於明確支援能力所需的NIST SP 800-53控制措施和控制項的過程。簡言之，該過程包括兩個步驟：

1.     用關鍵字搜尋NIST SP800-53中的控制措施，確定可能支援該功能的控制措施或控制項。請參見附錄B中的關鍵字規則。

2.     手動識別確實支援該能力的NIST SP 800-53控制措施或控制項（有效告警），而忽略不支援該能力的控制措施或控制項（誤報）。

 以上兩個步驟後續會生成三套NIST SP 800-53控制措施/控制項：

1.     支援VUL能力的低風險、中風險和高風險基線中的控制措施/控制項（3.3和3.4節）。

2.     透過關鍵詞搜尋選擇的低風險、中風險和高風險基線中的控制措施/控制項。不過，這些控制措施/控制項是手動確定為誤報（附錄C中列出）。

3.     關鍵詞搜尋後未進一步分析的基線之外的控制措施：

a.     程式管理（PM）控制措施，原因是PM控制措施不適用於單個系統。

b.     未選擇的控制措施—NIST SP 800-53中未分配基線或基線中未選擇的控制措施；和

c.     隱私控制措施。

組織若要開展自動化測試，參見附錄D中的未分析控制措施/控制項。

2.6.2      控制項術語

支援VUL能力的許多控制項還支援其他幾種能力，例如，配置管理控制措施可輔助硬體資產管理，軟體資產管理和配置設定管理能力。

有些控制項支援多種能力，為明確其適用範圍，相關描述用大括號括起來，

例如，{…軟體…}，表示特定控制項支援VUL能力並針對（且僅針對）大括號內的內容。

2.7 VUL角色和責任

表3列舉了VUL相關角色及其職責。圖2說明了角色如何與運營概念相結合。組織若進行自動化評估，可將職責分配給承擔現有角色的人員，自行定製方案。

 表3.   VUL相關的運營和管理角色

圖2.   VUL中的自動化評估涉及的主要角色

2.8 VUL評估範圍

評估範圍涵蓋整個計算機網路上的所有軟體，“整個”是指從網路最中間到網閘所在的或與其他網路相連的邊界。對於VUL能力，評估範圍涉及所有裝置上的軟體，包括掃描時發現的可移動裝置上的軟體。有關評估範圍相關術語的更多資訊和定義，參見本NISTIR第1卷中的4.3.2節。

2.9 VUL的實際狀態和期望狀態規範

有關VUL能力的實際狀態和期望狀態規範的資訊，參見第3.2節中的缺陷檢查表的評估標準註釋部分。

請注意，許多支援VUL能力的控制措施都引用了最新的裝置軟體清單（或其他清單）。SWAM能力提供軟體列表。此外，還要注意，根據IST SP 800-53A [SP800-53A]對測試的定義，測試VUL控制措施時，需要同時編制實際狀態清單和期望狀態清單，將兩者進行比較。有關比較詳情，參見第3.2節中的缺陷檢查表。

2.10       VUL授權範圍和繼承

關於如何解決自動評估的授權範圍問題，參見本NISTIR第1卷的4.3.1節。簡言之，對於VUL能力，NIST SP 800-53、CM-08(5)、《資訊系統元件清單》|《元件無重複登記》指出，每個裝置上的軟體被分配到一個且僅一個授權（系統）範圍。ISCM儀表盤可提供一種機制，記錄軟體分配的授權範圍，確保所有軟體分配給至少一個授權範圍，而且一個軟體產品不會分配給多個授權範圍。

關於如何管理公共控制元件的繼承，請參見此NISTIR第1卷的4.3.3節。對於VUL，很多實用程式、資料庫管理軟體產品、Web伺服器軟體物件以及作業系統的某些部件為其他系統提供了可繼承的支援和/或控制元件。ISCM儀表盤可提供一種機制，記錄繼承相關資訊和評估系統的整體風險。

2.11       VUL評估標準建議的分數和風險接受閾值

該NISTIR不涉及用於設定閾值的風險評分選項的常規指南。對於VUL能力，建議組織利用指標衡量每個裝置的平均風險評分和最大風險評分。需要說明的是，漏洞掃描工具可能在評估發現的漏洞時進行風險評分。

2.12       VUL評估標準涉及的裝置分組

為了支援自動化評估和持續授權，應按授權範圍對軟體進行明確分組（請參見NIST SP 800-53中的控制項CM-8（a）和CM-8（5））。此外，還可根據人員角色（裝置管理人、補丁管理人、軟體管理人和軟體缺陷管理人）對軟體進行清晰梳理，對特定裝置進行軟體漏洞管理（請參見NIST SP 800-53中的控制項CM-8（4））。除了這兩個重要分組，組織可能希望利用其他分組方法進行風險分析，詳情請參見本NISTIR第1卷5.6節。

[1] 支援VUL能力所需的特定資料因組織平臺、工具、配置等而異。

[2] 完全沒有已知漏洞幾無可能，也不現實（例如，當尚未提供補丁或尚未修補低風險漏洞時），因此，目標是儘量降低環境中的已知漏洞數量。

[3] 例如，Windows登錄檔或Linux包管理器

[4] 由組織根據攻擊者預期利用未知漏洞進行攻擊的速度而定義。

[5] 要求廠商基於數字指紋上報資料從而實現可靠的漏洞檢測對於漏洞檢測過程來說是一項重大提升。

[6] 準確地說，預期狀態指所有軟體都安裝補丁，符合組織的風險承受能力。 例如，一些組織可承受其認為的低風險CVE漏洞。

[7] 包清單列明瞭補丁釋出涉及的檔案。若清單列明瞭每個檔案的數字指紋，可對補丁全部內容的完整性/真實性進行驗證。因此，為了更可靠地識別CVE漏洞，軟體廠商需提供包清單列明每個檔案的數字指紋。

[8] 對缺陷進行評分或優先順序排序所必需的風險優先順序排序方法不在本出版物的範圍內。有關風險管理，風險評估和風險優先順序的討論，請參見[SP800-30]和[SP800-39]。

[9] 若未明確說明該角色為自動化，則由個人或團隊擔任。

[10] 漏洞管理過程中，利用風險評分（也稱“缺陷評分”）衡量缺陷的可利用性。