7.3 評估脆弱性（PRM_AVL）

7.3.1　安全保障工程目的

標識和特征化系統的安全脆弱性。
評估安全脆弱性的目標是獲得對一給定環境中系統安全脆弱性的理解。
評估安全脆弱性的目的在于標識和特征化系統的安全脆弱性。本安全工程保障控制組件包括分析系統資產、定義特殊的脆弱性以及提供對整個系統脆弱性的評估。與安全風險和脆弱性評估有關的術語，在許多不同上下文環境中用起來是不同的。就本模型的用途而言，“脆弱性”指的是可被開發利用（而不是那些原本就有安全漏洞和程序缺陷的易被威脅所攻擊）的系統的一個方面。這些脆弱性與任何特殊的威脅或攻擊形成并不相干。評估活動在系統生命期內任何時間都可進行，以支持在已知環境中對開發、維護和運行系統做出決策。
圖7描述了評估脆弱性（PRM_AVL）安全工程保障控制子類組成結構。
.

7.3.2　PRM_AVL.1 選擇脆弱性分析方法

選擇對一確定環境中系統安全脆弱性進行標識和特征化的方法、技術和標準。

7.3.2.1　安全工程保障控制組件控制

本基本實踐包括定義對系統建立安全脆弱性的方法，這種方法允許對安全脆弱性進行標識和特征化。這些可以包括一個對基于威脅及其可能性、運行功能、安全需求或提供的其它相關領域的脆弱性進行分類和優先級排列的方案。標識這些分析的深度和廣度，允許安全工程師和顧客可以確定目標系統是否為本訓練及其理解的一部分。所有分析應在預先安排和指定時間內，在一個已知的并記錄有配置的框架內進行。該種分析的方法論應包括預期結果。分析的特定目標應陳述清楚。

7.3.2.2　安全工程保障控制組件注解

脆弱性分析方法可以是現有的、經裁剪的或者專門針對系統中特定運行方面和確定環境而制定的。分析方法通常以PRM_ATT “評估安全風險”中的風險分析方法論為基礎。需要注意的是并不提供有關威脅、能力和價值的理解，這時的方法論必須針對其范圍或采用一系列可用假設條件。
用于分析脆弱性的方法可以是定量的或定性的。通常的脆弱性分析包括一種可能性預測。攻擊結果可以書面報告形式遞交，攻擊本身還可以書面形式證明。
就脆弱性的標識而言，至少存在兩種基本上不同的方法。這兩種方法被特征化為基于分析的方法或基于測試的方法。基于測試的方法對于標識現存的脆弱性，以及測試內容中含有已知威脅的脆弱性，都是很好的方法。基于分析的方法，對于標識新的脆弱性的以及那些并不立即暴露但會隨另一安全問題的出現而暴露的脆弱性，則是最好的方法。在選擇脆弱性分析方法論時還可考慮的其它選擇包括基于定量或定性的方法。應該考慮對分析和測量完整性的控制問題。
工作產品示例：
a) 脆弱性分析方法――標識尋找和提出系統安全脆弱性的方法，包括分析、報告和跟蹤過程。
b) 脆弱性分析格式――描述脆弱性分析結果的格式，保證方法的特征化。
c) 攻擊方法論和工作原理――包括執行攻擊測試的目標和方法。
d) 攻擊過程――執行攻擊測試的詳細步驟。
e) 攻擊規劃――包括資源、時間安排和攻擊方法論的描述。
f) 穿透研究――以標識未知脆弱性為目標的攻擊概要分析和方案。
g) 攻擊概要――描述將要進行的特定攻擊。

7.3.3　PRM_AVL.2 標識脆弱性

標識系統安全脆弱性。

7.3.3.1　安全工程保障控制組件控制

系統脆弱性可以在系統的安全和非安全的相關部分被發現。許多情況下，支持與安全機制相關的安全功能和工作的非安全機制，被發現具有可利用的脆弱性。選擇脆弱性分析方法（PRM_AVL.1）中研究過的攻擊概要方法論應延伸到對脆弱性的確認。所有發現的系統脆弱性應予以記錄。

7.3.3.2　安全工程保障控制組件注解

在本實施中，脆弱性被看成是系統在不考慮威脅可能性情況下的固有問題。這些脆弱性可以按照威脅分析的結果進行優先級排列。不可重復的攻擊，解決起來難度較大。
脆弱性在PRM_ASR“評估安全風險”中關于對功能的優先級排列部分中進行標識，而商務優先級和安全目標則在PEN_ISR“確定安全要求” 中進行標識。此外，資產問題在PRM_AIM中必須進行考慮。
工作產品示例:
a) 描述系統經受各種攻擊的脆弱性清單。
b) 包括攻擊測試結果（例如脆弱性）的穿透輪廓。

7.3.4　PRM_AVL.3 收集脆弱性數據

收集與脆弱性性質相關的數據。

7.3.4.1　安全工程保障控制組件控制

脆弱性具有自身的性質。本基本實踐打算將與這些性質相關的數據收集起來。在某種情況下，脆弱性的測量單位可能與PRM_ATT.3“標識威脅的測量單元”中有關威脅的測量單位相同。由于脆弱性易于被利用，因此脆弱性存在的可能性應予標識，其數據應被收集。

7.3.4.2　安全工程保障控制組件注解

很多收集起來的脆弱性數據將被以后用來執行PRM_ASR“評估安全風險”。因此，以一種為PRM_ASR可以使用的格式對脆弱性數據進行收集和存貯非常重要。無論什么情況，總存在著與度量標準和可能性相關的不確定性。通常，更為有效的辦法是分別保留其不確定性，以便在工作數據進行重新調整后，可以看出是數據本身還是與該數據相關的不確定性需要對工作數據進行調整。
工作產品示例：
a) 脆弱性性質表－記錄系統或產品脆弱性特征的表

7.3.5　PRM_AVL.4 合成系統脆弱性

評估系統脆弱性并將特定脆弱性及各種特定脆弱性的組合結果進行綜合收集與脆弱性性質有關的數據。

7.3.5.1　安全工程保障控制組件控制

分析那些脆弱性或脆弱性的總和會對系統造成問題。所有分析應標識出該脆弱性的特征，例如脆弱性被開發的可能性以及成功開發脆弱性的概率。提出合成脆弱性的建議也可以包括在分析結果之中。

7.3.5.2　安全工程保障控制組件注解

必須收集對系統的分析和攻擊訓練的結果。任何已被發現的脆弱性及其可開發性均需進行標識并形成足夠詳細的文檔，從而允許顧客做出有關解決辦法的決定。
工作產品示例：
a) 脆弱性評估報告――包括對系統造成問題的脆弱性的定性或定量的描述，這些問題是攻擊的可能性、攻擊成功的可能性及攻擊產生的影響。
b) 攻擊報告――對已發現的脆弱性、被開發的潛在可能性和推薦的處置方法的分析過程和結果進行書面總結。

7.3.6　PRM_AVL.5 監視脆弱性及其特定

監視合適的脆弱性及其特征的不斷變化。

7.3.6.1　安全工程保障控制組件控制

適合于任何位置和狀態的脆弱性頻譜都是動態的。新的脆弱性變得與之相關，而現有脆弱性的特征可能發生變化。因此，重要的是有規律地監視現有脆弱性及其特征并檢查新的脆弱性。本基本實踐與PEN_COS.2監視威脅、脆弱性、影響、風險和環境變化的一般性監視活動緊密相連。

7.3.6.2　安全工程保障控制組件注解

由于脆弱性可能發生變化，在一確定環境中可能多次引入評估活動。然而，這種脆弱性的重復評估不應代替對脆弱性的監視。
工作產品示例：
a) 脆弱性監視報告－描述脆弱性監視結果的文檔
b) 脆弱性變化報告－描述新的或變化了的脆弱性文檔