2019測試指南-安全測試數據分析和報告

安全測試指標和度量
的目標定義安全測試指標和度量的目標是將安全測試數據用於風險分析和管理流程的先決條件。例如，諸如安全測試中發現的漏洞總數之類的度量可能會量化應用程序的安全狀態。這些測量還有助於肯定軟件安全測試的安全目標。例如，在將應用程序部署到生產環境以前，將漏洞數量減小到可接受的數量（最小值）。

另外一個可管理的目標多是將應用程序安全情況與基準進行比較，以評估應用程序安全流程的改進。例如，安全度量基準可能包含僅使用滲透測試進行測試的應用程序。從編碼期間進行安全測試的應用程序得到的安全數據與基線相比應顯示出改進（例如，漏洞數量減小）。

在傳統的軟件測試中，軟件缺陷的數量（例如應用程序中發現的錯誤）能夠提供軟件質量的測量。一樣，安全測試能夠提供軟件安全性的衡量標準。從缺陷管理和報告的角度來看，軟件質量和安全測試能夠對根本緣由和缺陷修復工做使用相似的分類。從根本緣由的角度來看，安全缺陷多是因爲設計錯誤（例如，安全漏洞）或因爲編碼錯誤（例如，安全漏洞）形成的。從修復缺陷所需的工做的角度來看，安全性和質量缺陷均可以根據開發人員的小時數來衡量，以實現修復，修復所需的工具和資源以及實施修復的成本。

與質量數據相比，安全測試數據的特徵是對威脅，漏洞暴露以及漏洞肯定風險可能帶來的潛在影響進行分類。測試安全性應用程序包括管理技術風險以確保應用程序對策達到可接受的水平。所以，安全測試數據須要支持SDLC期間關鍵檢查點的安全風險策略。例如，源代碼分析中的漏洞表明了風險的初始衡量標準。能夠經過肯定暴露和可能性因素以及經過滲透測試驗證漏洞來計算漏洞的風險度量（例如，高，中，低）。

在評估應用程序的安全狀態時，重要的是要考慮某些因素，例如正在開發的應用程序的大小。統計數據證實，應用程序大小與測試期間應用程序中發現的問題數量有關。應用程序大小的一種度量是應用程序的代碼行數（LOC）。一般，軟件質量缺陷的範圍是每千行新代碼和更改代碼中大約7到10個缺陷[21]。因爲單獨進行一次測試，測試能夠將整體數量減小約25％，所以對於較大尺寸的應用程序而言，與較小尺寸的應用程序相比，測試更爲合理。

當在SDLC的幾個階段中進行安全測試時，測試數據能夠證實安全測試在引入漏洞後當即檢測漏洞的能力。測試數據還能夠經過在SDLC的不一樣檢查點實施對策來證實消除漏洞的有效性。此類型的度量也被定義爲「包含度量」，並提供在開發過程的每一個階段執行的安全評估在每一個階段內維護安全性的能力的度量。這些遏制指標也是下降修復漏洞成本的關鍵因素。在SDLC的相同階段處理漏洞比在它們被發現時更便宜，而不是稍後在另外一個階段修復它們。

安全測試指標能夠在與有形和定時目標相關聯時支持安全風險，成本和缺陷管理分析，例如：

• 將漏洞總數減小30％
• 在特定截止日期前解決安全問題（例如，在測試版發佈以前）

安全測試數據能夠是絕對的，例如在手動代碼審查期間檢測到的漏洞數量，以及比較，例如與滲透測試相比在代碼審查中檢測到的漏洞數量。要回答有關安全過程質量的問題，肯定可接受和良好的基線很是重要。

安全測試數據還能夠支持安全分析的特定目標。這些對象能夠符合安全法規和信息安全標準，安全流程管理，安全根本緣由和流程改進的識別以及安全成本效益分析。

報告安全測試數據時，必須提供支持分析的指標。分析的範圍是對測試數據的解釋，以找到有關正在生產的軟件的安全性以及該過程的有效性的線索。

安全測試數據支持的線索的一些示例能夠是：

• 漏洞是否會下降到可接受的發佈水平？
• 該產品的安全質量與同類軟件產品相好比何？
• 是否知足全部安全測試要求？
• 安全問題的主要根源是什麼？
• 與安全漏洞相比，安全漏洞有多少？
• 哪一種安全活動最有效地發現漏洞？
• 哪一個團隊在修復安全缺陷和漏洞方面更有效率？
• 哪些百分比的整體漏洞是高風險？
• 哪些工具在檢測安全漏洞方面最有效？
• 哪一種安全測試最有效地發現漏洞（例如，白盒與黑盒）測試？
• 安全代碼審查期間發現了多少安全問題？
• 在安全設計審覈期間發現了多少安全問題？

爲了使用測試數據作出合理的判斷，重要的是要充分了解測試過程以及測試工具。應採用工具分類法來決定使用哪些安全工具。安全工具能夠被認定爲善於發現針對不一樣工件的常見已知漏洞。

問題是未測試未知的安全問題。安全測試沒有問題這一事實並不意味着軟件或應用程序是好的。一些研究[22]已經證實，工具最多隻能找到45％的整體漏洞。

即便是最複雜的自動化工具也不適合經驗豐富的安全測試人員。僅依靠自動化工具的成功測試結果將給安全從業者帶來虛假的安全感。一般，安全測試人員使用安全測試方法和測試工具的經驗越多，安全測試和分析的結果就越好。重要的是，對安全測試工具進行投資的管理人員也應考慮投資僱用熟練的人力資源以及安全測試培訓。

報告要求
應用程序的安全狀態能夠從效果的角度來描述，例如漏洞的數量和漏洞的風險評級，以及從緣由或來源的角度來看，例如編碼錯誤，架構缺陷和配置問題。

漏洞能夠根據不一樣的標準進行分類。最經常使用的漏洞嚴重性度量標準是事件響應和安全團隊論壇（FIRST）常見漏洞評分系統（CVSS），該系統目前處於發佈版本2，版本3即將發佈。

報告安全測試數據時，最佳作法是包含如下信息：

• 按類型對每一個漏洞進行分類
• 該問題所面臨的安全威脅
• 安全問題的根本緣由（例如，安全漏洞，安全漏洞）
• 用於發現問題的測試技術
• 漏洞的修復（例如，對策）
• 漏洞的嚴重等級（高，中，低和/或CVSS評分）

經過描述安全威脅是什麼，能夠了解緩解控制是否以及爲什麼在減輕威脅方面無效。

報告問題的根本緣由有助於肯定須要修復的問題。例如，在白盒測試的狀況下，漏洞的軟件安全根本緣由將是違規的源代碼。

報告問題後，向軟件開發人員提供有關如何從新測試和查找漏洞的指導也很重要。這可能涉及使用白盒測試技術（例如，使用靜態代碼分析器進行安全代碼審查）來查找代碼是否易受攻擊。若是能夠經過黑盒技術（滲透測試）找到漏洞，則測試報告還須要提供有關如何驗證漏洞暴露給前端（例如，客戶端）的信息。

有關如何修復漏洞的信息應該足夠詳細，以便開發人員實施修復。它應該提供安全的編碼示例，配置更改，並提供足夠的參考。

最後，嚴重等級有助於計算風險等級，並有助於肯定補救措施的優先順序。一般，爲漏洞分配風險評級涉及基於影響和暴露等因素的外部風險分析。

業務案例
爲使安全測試指標有用，他們須要爲組織的安全測試數據利益相關者提供價值。利益相關者能夠包括項目經理，開發人員，信息安全辦公室，審計員和首席信息官。價值能夠是每一個項目利益相關者在角色和責任方面的業務案例。

軟件開發人員查看安全測試數據，以顯示軟件編碼更安全，更有效。這使他們可以使用源代碼分析工具以及遵循安全編碼標準和參加軟件安全培訓。

項目經理根據項目計劃查找容許他們成功管理和利用安全測試活動和資源的數據。對於項目經理而言，安全測試數據能夠顯示項目按計劃進行，並在交付日期的目標上移動，而且在測試期間變得更好。

若是該計劃來自信息安全官（ISO），則安全測試數據還有助於安全測試的業務案例。例如，它能夠提供證據代表SDLC期間的安全測試不會影響項目交付，而是減小了在生產後期解決漏洞所需的整體工做量。

對於合規性審計人員，安全測試指標提供了必定程度的軟件安全保障，並確保經過組織內的安全審查流程解決安全標準合規性問題。

最後，負責預算須要在安全資源中分配的首席信息官（CIO）和首席信息安全官（CISO）尋求從安全測試數據中推導出成本效益分析。這使他們可以就投資的安全活動和工具作出明智的決策。支持此類分析的指標之一是安全性投資回報率（ROI）[23]。要從安全測試數據中獲取此類指標，重要的是量化因爲漏洞暴露致使的風險與安全測試在下降安全風險方面的有效性之間的差別，並將此差距與安全測試活動的成本相關聯或採用的測試工具。