2019測試指南-推導安全測試要求

得到安全測試要求

要得到成功的測試程序，必須知道測試目標是什麼。這些目標由安全要求指定。本節詳細討論瞭如何經過從適用的標準和法規以及正面和負面的應用程序要求中獲取安全測試的要求來記錄安全測試的要求。它還討論了安全要求如何在SDLC期間有效推進安全測試，以及如何使用安全測試數據來有效管理軟件安全風險。

測試目標
安全測試的目標之一是驗證安全控制是否按預期運行。這經過描述安全控件功能的安全要求進行記錄。從較高的層面來講，這意味着要證實數據和服務的機密性，完整性和可用性。另外一個目標是驗證安全控制是在不多或沒有漏洞的狀況下實現的。這些是常見的漏洞，例如OWASP Top Ten，以及以前在SDLC期間經過安全評估肯定的漏洞，例如威脅建模，源代碼分析和滲透測試。

安全要求文檔安全要求文檔
的第一步是瞭解業務要求。業務需求文檔能夠提供有關應用程序的預期功能的初始高級信息。例如，應用程序的主要目的多是向客戶提供金融服務或容許從在線目錄中購買商品。業務要求的安所有分應強調保護客戶數據以及遵照適用的安全文檔（如法規，標準和策略）的必要性。

適用法規，標準和策略的通常清單是Web應用程序的良好初步安全合規性分析。例如，能夠經過檢查有關業務部門以及應用程序將運行的國家或州的信息來識別合規性法規。其中一些合規性指南和法規可能轉化爲安全控制的特定技術要求。例如，在財務應用程序的狀況下，遵照FFIEC認證準則[15]要求金融機構經過多層安全控制和多因素身份驗證來實施緩解弱認證風險的應用程序。

通常安全要求清單也須要捕獲適用的安全行業標準。例如，對於處理客戶信用卡數據的應用程序，符合PCI DSS [16]標準禁止存儲PIN和CVV2數據，並要求商家經過加密保護磁帶數據進行存儲和傳輸。經過掩蔽顯示。能夠經過源代碼分析驗證此類PCI DSS安全要求。

清單的另外一部分須要強制執行符合組織信息安全標準和策略的通常要求。從功能需求的角度來看，安全控制的要求須要映射到信息安全標準的特定部分。此類要求的一個示例多是：「必須經過應用程序使用的身份驗證控件強制執行六個字母數字字符的密碼複雜性。」 當安全要求映射到合規性規則時，安全性測試能夠驗證合規性風險的暴露程度。若是發現違反信息安全標準和政策的行爲，則會產生能夠記錄而且業務必須管理的風險。因爲這些安全合規性要求是可執行的，

安全要求驗證
從功能角度來看，安全性要求的驗證是安全性測試的主要目標。從風險管理的角度來看，安全要求的驗證是信息安全評估的目標。從較高層面來講，信息安全評估的主要目標是肯定安全控制方面的差距，例如缺少基自己份驗證，受權或加密控制。更深刻的是，安全評估目標是風險分析，例如肯定安全控制中的潛在弱點，以確保數據的機密性，完整性和可用性。例如，當應用程序處理我的身份信息（PII）和敏感數據時，要驗證的安全要求是遵照公司信息安全策略，要求在傳輸和存儲中加密此類數據。假設加密用於保護數據，加密算法和密鑰長度須要符合組織加密標準。這些可能要求只能使用某些算法和密鑰長度。例如，能夠進行安全性測試的安全性要求是驗證僅容許使用容許的密碼（例如，SHA-256，RSA，AES）以及容許的最小密鑰長度（例如，對稱性超過128位，非對稱性超過1024）加密）。加密算法和密鑰長度須要符合組織加密標準。這些可能要求只能使用某些算法和密鑰長度。例如，能夠進行安全性測試的安全性要求是驗證僅容許使用容許的密碼（例如，SHA-256，RSA，AES）以及容許的最小密鑰長度（例如，對稱性超過128位，非對稱性超過1024）加密）。加密算法和密鑰長度須要符合組織加密標準。這些可能要求只能使用某些算法和密鑰長度。例如，能夠進行安全性測試的安全性要求是驗證僅容許使用容許的密碼（例如，SHA-256，RSA，AES）以及容許的最小密鑰長度（例如，對稱性超過128位，非對稱性超過1024）加密）。

從安全評估的角度來看，能夠經過使用不一樣的工件和測試方法在SDLC的不一樣階段驗證安全性要求。例如，威脅建模側重於識別設計過程當中的安全漏洞，安全代碼分析和評估側重於在開發過程當中識別源代碼中的安全問題，而滲透測試側重於在測試或驗證期間識別應用程序中的漏洞。

在SDLC早期發現的安全問題能夠記錄在測試計劃中，以便稍後經過安全測試進行驗證。經過結合不一樣測試技術的結果，能夠得到更好的安全測試用例並提升安全要求的保證級別。例如，當滲透測試和源代碼分析的結果相結合時，能夠區分真正的漏洞和不可利用的漏洞。例如，考慮到SQL注入漏洞的安全性測試，黑盒測試可能首先涉及掃描應用程序以指紋漏洞。能夠驗證的潛在SQL注入漏洞的第一個證據是生成SQL異常。SQL漏洞的進一步驗證可能涉及手動注入攻擊向量以修改SQL查詢的語法以進行信息泄露。這可能涉及大量的試錯分析，直到執行惡意查詢。假設測試人員有源代碼，她能夠從源代碼分析中學習如何構建能夠利用漏洞的SQL攻擊向量（例如，執行將機密數據返回給未受權用戶的惡意查詢）。

威脅和對策分類法
甲威脅和對策的分類，其中考慮到漏洞的考慮根本緣由，是在驗證安全控制設計，編碼，並內置於減輕這種漏洞的暴露的影響的關鍵因素。對於Web應用程序，安全控件暴露於常見漏洞（例如OWASP Top Ten）多是得到通常安全要求的良好起點。更具體地說，Web應用程序安全框架[17]提供了漏洞的分類（例如，分類），這些漏洞能夠記錄在不一樣的準則和標準中，並經過安全測試進行驗證。

威脅和對策分類的重點是根據威脅和漏洞的根本緣由定義安全要求。可使用STRIDE [18]將威脅分類爲欺騙，篡改，否定，信息泄露，拒絕服務和特權提高。根本緣由可歸類爲設計中的安全漏洞，編碼中的安全漏洞或因爲不安全配置致使的問題。例如，弱身份驗證漏洞的根本緣由多是當數據跨越應用程序的客戶端和服務器層之間的信任邊界時缺少相互身份驗證。在架構設計審查期間捕獲不能否認威脅的安全要求容許記錄對策的要求（例如，

針對漏洞的威脅和對策分類也可用於記錄安全編碼的安全要求，例如安全編碼標準。身份驗證控件中的常見編碼錯誤的示例包括應用哈希函數來加密密碼，而不將種子應用於值。從安全編碼的角度來看，這是一個影響用於身份驗證的加密的漏洞，其中包含編碼錯誤中的漏洞根本緣由。因爲根本緣由是不安全編碼，所以能夠在安全編碼標準中記錄安全要求，並在SDLC的開發階段經過安全代碼審查進行驗證。

安全測試和風險分析
安全要求須要考慮漏洞的嚴重性，以支持風險緩解策略。假設組織維護應用程序中發現的漏洞存儲庫（即漏洞知識庫），則能夠按類型，問題，緩解，根本緣由報告安全問題，並將其映射到找到它們的應用程序。此類漏洞知識庫還可用於創建度量標準，以分析整個SDLC中安全性測試的有效性。

例如，考慮一個輸入驗證問題，例如SQL注入，它是經過源代碼分析識別出來的，並報告了編碼錯誤根本緣由和輸入驗證漏洞類型。能夠經過滲透測試來評估這種漏洞的暴露，經過使用幾個SQL注入攻擊向量探測輸入字段。此測試可能會驗證在訪問數據庫以前是否過濾了特​​殊字符並減輕了漏洞。經過結合源代碼分析和滲透測試的結果，能夠肯定漏洞的可能性和暴露程度，並計算漏洞的風險評級。經過報告調查結果中的漏洞風險評級（例如，測試報告），能夠決定緩解策略。例如，

經過考慮利用常見漏洞的威脅情景，能夠識別應用程序安全控制須要進行安全性測試的潛在風險。例如，OWASP Top Ten漏洞能夠映射到諸如網絡釣魚，隱私侵權，識別盜竊，系統危害，數據更改或數據破壞，財務損失和聲譽損失等攻擊。這些問題應記錄爲威脅情景的一部分。經過考慮威脅和漏洞，能夠設計一組模擬此類攻擊場景的測試。理想狀況下，組織漏洞知識庫可用於派生安全風險驅動的測試用例，以驗證最可能的攻擊方案。例如，若是身份盜竊被認爲是高風險，

推導功能和非功能測試要求

功能安全要求
從功能安全要求的角度來看，適用的標準，政策和法規既須要一種安全控制，也須要控制功能。這些要求也稱爲「積極要求」，由於它們陳述了能夠經過安全測試驗證的預期功能。積極要求的示例是：「應用程序將在六次登陸嘗試失敗後鎖定用戶」或「密碼必須至少爲六個字母數字字符」。正面要求的驗證包括斷言預期的功能，而且能夠經過從新建立測試條件並根據預約義的輸入運行測試來進行測試。而後將結果顯示爲失敗或經過條件。

爲了經過安全測試驗證安全性要求，安全性需求須要由功能驅動，而且須要突出顯示預期的功能（什麼）和隱式實現（如何）。驗證的高級安全性設計要求的示例能夠是：

• 保護傳輸和存儲中的用戶憑據和共享機密
• 屏蔽顯示中的任何機密數據（例如，密碼，賬戶）
• 在必定次數的登陸嘗試失敗後鎖定用戶賬戶
• 因爲登陸失敗，請勿向用戶顯示特定的驗證錯誤
• 僅容許使用字母數字的密碼，包括特殊字符和最小長度爲六個字符，以限制攻擊面
• 經過驗證舊密碼，新密碼和用戶對質詢問題的回答，僅容許對通過身份驗證的用戶進行密碼更改功能，以防止經過密碼更改強制輸入密碼。
• 密碼重置表單應驗證用戶的用戶名和用戶的註冊電子郵件，而後經過電子郵件將臨時密碼發送給用戶。發出的臨時密碼應該是一次性密碼。密碼重置網頁的連接將發送給用戶。密碼重置網頁應驗證用戶臨時密碼，新密碼以及用戶對質詢問題的回答。

風險驅動的安全要求
安全測試還須要風險驅動，即他們須要驗證應用程序是否存在乎外行爲。這些也稱爲「否認要求」，由於它們指定了應用程序不該該執行的操做。

負面要求的例子是：

• 應用程序不該容許更改或銷燬數據
• 惡意用戶不該對應用程序進行未經受權的金融交易進行攻擊或濫用。

負面要求更難以測試，由於沒有預期的行爲要尋找。這可能須要威脅分析師提出不可預見的輸入條件，緣由和影響。這是安全測試須要由風險分析和威脅建模驅動的地方。關鍵是將威脅情景和對策的功能記錄爲減輕威脅的因素。

例如，在身份驗證控件的狀況下，能夠從威脅和對策角度記錄如下安全要求：

• 加密存儲和傳輸中的身份驗證數據，以下降信息泄露和身份驗證協議攻擊的風險
• 使用非可逆加密來加密密碼，例如使用摘要（例如，HASH）和種子來防止字典攻擊
• 在達到登陸失敗閾值後鎖定賬戶並強制執行密碼複雜性以下降強力密碼攻擊的風險
• 驗證憑據時顯示通用錯誤消息，以下降賬戶獲取或枚舉的風險
• 相互驗證客戶端和服務器，以防止不能否認和中間人（MiTM）攻擊

威脅樹和攻擊庫等威脅建模工具可用於推導負面測試場景。威脅樹將假定根攻擊（例如，攻擊者可能可以讀取其餘用戶的消息）並識別安全控制的不一樣漏洞（例如，因爲SQL注入漏洞而致使數據驗證失敗）和必要的對策（例如，實施數據）驗證和參數化查詢）能夠被驗證爲有效減輕此類攻擊。

 

經過使用和濫用案例獲取安全測試要求

描述應用程序功能的先決條件是瞭解應用程序應該執行的操做以及操做方式。這能夠經過描述用例來完成。用例以軟件工程中經常使用的圖形形式顯示演員及其關係的交互。它們有助於識別應用程序中的參與者，他們的關係，每一個場景的預期行動順序，替代操做，特殊要求，前提條件和後置條件。

與用例相似，濫用和濫用案例 [19]描述了應用程序的非預期和惡意使用場景。這些濫用案例提供了一種描述攻擊者如何濫用和濫用應用程序的方案的方法。經過瀏覽使用場景中的各個步驟並思考如何惡意利用它，能夠發現未明肯定義的應用程序的潛在缺陷或方面。關鍵是描述全部可能的或至少是最關鍵的使用和誤用場景。

濫用方案容許從攻擊者的角度分析應用程序，並有助於識別潛在的漏洞以及須要實施的對策，以減輕潛在暴露於此類漏洞所形成的影響。鑑於全部使用和濫用案例，分析它們以肯定哪些是最關鍵的而且須要記錄在安全要求中很是重要。肯定最嚴重的濫用和濫用案例能夠記錄安全要求以及應減輕安全風險的必要控制措施。

爲了從使用和誤用案例[20]中得到安全性要求，定義功能場景和負面場景並將其以圖形形式放置是很重要的。例如，在推導認證的安全要求的狀況下，能夠遵循如下逐步方法。

• 步驟1：描述功能場景：用戶經過提供用戶名和密碼進行身份驗證。應用程序根據應用程序對用戶憑據的身份驗證授予用戶訪問權限，並在驗證失敗時向用戶提供特定錯誤。

• 步驟2：描述負面場景：攻擊者經過對應用程序中的密碼和賬戶收集漏洞的強力攻擊或字典攻擊來破壞身份驗證。驗證錯誤向攻擊者提供特定信息，以猜想哪些賬戶其實是有效的註冊賬戶（用戶名）。而後攻擊者將嘗試暴力破解這樣一個有效賬戶的密碼。經過有限次數的嘗試（即10 ^ 4），對四個最小長度的全部數字密碼的暴力攻擊均可以成功。

• 第3步：使用和濫用案例描述功能和負面狀況：下圖中的圖形示例描述了經過使用和誤用狀況推導的安全要求。功能方案包括用戶操做（輸入用戶名和密碼）和應用程序操做（驗證用戶並在驗證失敗時提供錯誤消息）。濫用案例包括攻擊者的行爲，即試圖經過字典攻擊強制密碼並經過猜想錯誤消息中的有效用戶名來破壞身份驗證。經過以圖形方式表示對用戶操做（濫用）的威脅，能夠將對策導出爲緩解此類威脅的應用程序操做。