代碼安全PPTQA-第二章 軟件安全需求與設計

目錄2.1安全需求概述2.2安全需求分析方法2.3安全設計概述2.4安全設計方法2.5威脅建模1本章學習目標1.了解安全需求的定義和標準；2.了解安全需求分析過程；3.了解軟件安全設計的內容；4.了解什么是威脅建模；5.理解安全設計的分析方法；6.理解安全需求的原則；7.掌握安全設計的方法；8.掌握威脅建模的過程；2安全需求概述2.1安全需求的定義傳統(tǒng)軟件需求由功能需求、非功能需求和約束構成。安全需求的定義有三種：（1）將安全需求看作傳統(tǒng)軟件需求的非功能性需求部分，用于補充產(chǎn)品的功能描述，從安全方面描述產(chǎn)品特性。（2）將安全需求看作與業(yè)務功能需求同等重要的安全功能需求，是開發(fā)人員必須實現(xiàn)的軟件功能，對業(yè)務功能需求進行安全約束。（3）使用安全策略或質量需求來定義安全需求。安全需求的三個安全屬性軟件安全需求是為保障實現(xiàn)業(yè)務功能而對相關信息的機密性、完整性和可用性提出的要求。（1）機密性(Confidentiality)指保護敏感信息不被未授權用戶訪問。（2）完整性(Integrity)指保護數(shù)據(jù)不被更改或破壞。（3）可用性(Availability)指確保資源被授權用戶的使用。安全需求的標準安全需求常用的標準有：安全開發(fā)標準ISO27034；信息技術軟件安全保障規(guī)范GB/T30998-2014；功能安全基礎標準IEC61508；信息技術安全性認證通用標準（CC標準）。CC標準定義了安全功能需求和安全保障需求來規(guī)范安全需求。（1）安全功能需求是指安全系統(tǒng)應該提供的安全功能。開發(fā)者可參照CC標準第二部分安全功能要求中定義的安全審計、通信/不可抵賴、密碼支持、用戶數(shù)據(jù)保護、標識和鑒別和安全管理等確定需求。（2）安全保障需求是指安全可信度及為保障可信度而應采取的措施。開發(fā)者可參考CC標準第三部分安全保障要求定義的保護輪廓評估、安全目標評估、配置管理、交付和運行、脆弱性評估和保障維護等。安全保障級別安全保障級別（EVL）是CC標準定義的系統(tǒng)安全可信度評價方法。安全保障級別（EVL）通過安全系統(tǒng)在構造管理、生命周期支持和脆弱性評估等方面所采取的措施來確定系統(tǒng)的安全可信度，EVL1至EAL7評估等級對開發(fā)系統(tǒng)的安全要求不斷增加。安全風險值，系統(tǒng)的病毒感染率和平均失效時間MTTF都是除安全保障級別（EAL）外當前成熟流行的評價系統(tǒng)安全保障程度的指標。安全需求分析方法2.2安全需求分析過程安全需求分析的過程是一個不斷發(fā)展的過程，安全需求的內容需要不斷地進行修正以保持分析結果的有效性。軟件安全需求的分析過程有以下步驟：（1）系統(tǒng)調查：了解系統(tǒng)所處的安全環(huán)境及其它安全信息，確定需要保護的資產(chǎn)，評價各個資產(chǎn)的相對價值。（2）分析系統(tǒng)的脆弱點和安全威脅：確定系統(tǒng)的脆弱點，針對每個脆弱點可能由此引發(fā)的安全威脅及其對資產(chǎn)可能造成損害的程度進行定性和定量分析。（3）確定需求：結合定性分析和定量分析的結果，確定信息系統(tǒng)的安全需求，開發(fā)人員根據(jù)需求實施相應的安全措施。安全需求分析方法安全需求分析方法目前均是對傳統(tǒng)需求分析方法的擴展，在傳統(tǒng)需求分析過程中融入安全性考量。安全需求分析的常用方法有濫用案例、濫用框架和安全質量需求工程（SQUARE）等。濫用案例濫用案例是在傳統(tǒng)的需求分析方法用例上的安全擴展，開發(fā)者通過將自己置于攻擊者的狀態(tài)，考慮當安全機制無效或被破壞時的后果，可更深入了解系統(tǒng)和防范惡意攻擊。濫用案例的典型方法有誤用用例和濫用用例：（1）誤用用例方法是從功能性用例的文本描述中分析可能存在的安全漏洞并識別出對應的威脅，建立威脅用例和對應的安全需求用例。（2）濫用用例方法用于捕獲攻擊者與系統(tǒng)之間的交互所產(chǎn)生的威脅，對攻擊者的企圖、攻擊能力進行評估，針對識別出的威脅單獨建立威脅用例，這些威脅用例與誤用用例中的功能性用例并不產(chǎn)生交互。濫用案例的創(chuàng)建步驟（1）用UML的方法描述參與者和用例。（2）引入主要的濫用者和濫用用例。（3）研究濫用用例和用例之間潛在的include關系。（4）引入新的用例來發(fā)現(xiàn)或阻止濫用用例。（5）形成詳細的需求記錄。濫用框架濫用框架是在傳統(tǒng)的需求分析方法中問題框架上的安全擴展，開發(fā)者從攻擊者的角度考慮系統(tǒng)面臨的問題，采用已有的問題框架方法針對問題領域進行分析并獲取安全需求。濫用框架通過濫用框架威脅圖和安全需求描述圖來描述系統(tǒng)面臨的安全問題。濫用框架定義“攻擊者領城”表示攻擊者；定義“受害者領域”表示系統(tǒng)遭受威脅的資產(chǎn)；引入“反需求”表示攻擊者對系統(tǒng)的需求，先獲取反需求，再制定相應的安全需求。濫用框架威脅圖圖中E1表示反需求在受害領域產(chǎn)生的安全威脅現(xiàn)象。E2表示機器領域和受害者領域之間的共享現(xiàn)象，機器領域通過E2對受害領域進行操作來完成軟件系統(tǒng)的功能。實線的E3表示惡意攻擊者對機器領域產(chǎn)生的攻擊現(xiàn)象。虛線的E3表示反需求受到攻擊者領域的需求引用，它和反需求一起描述了攻擊者領域對機器領域的攻擊效果。濫用框架威脅圖濫用框架安全需求描述圖圖中E1表示在攻擊情況下受保護領域所期望的現(xiàn)象。E2表示機器領域和受害者領域之間的共享現(xiàn)象，機器領域通過E2對受害領域進行操作來完成軟件系統(tǒng)的功能。實線的E3表示惡意攻擊者對機器領域產(chǎn)生的攻擊現(xiàn)象。虛線的E3表示反需求受到攻擊者領域的需求引用，它和反需求一起描述了攻擊者領域對機器領域的攻擊效果。安全需求描述圖SQUARE過程模型SQUARE過程模型在軟件開發(fā)周期的早期植入安全概念，在系統(tǒng)實現(xiàn)后分析系統(tǒng)的安全性，并對系統(tǒng)將來的修改和更新起著重要作用。SQUARE過程分析安全需求應當在項目發(fā)生變化時重新應用。SQUARE模型需要項目投資者、需求工程師和安全專家的參與，過程相對復雜，適合在大型項目中運用。SQUARE模型的執(zhí)行過程（1）統(tǒng)一定義：查閱IEEE和SWEBOK等安全相關資料進行統(tǒng)一定義。（2）確認安全日標：在軟件項目開始階段確定安全目標，并在整個生命周期中持續(xù)關注。軟件項目的不同用戶有不同的安全目標。（3）開發(fā)方案：分析選擇可更好地支持安全需求定義的方案。（4）進行風險評估：風險專家根據(jù)項目需求推薦特定的風險評估方法，進行風險分析并得出風險評估結果。（5）選擇啟發(fā)性方法：根據(jù)項目客戶的不同類型選擇適合的啟發(fā)式方法。（6）制定安全需求：利用之前所選開發(fā)方案得出安全需求。（7）需求分類：對關鍵需求，目標和可能存在的構架約束進行區(qū)分。（8）需求排序：通過需求分類和成本效益分析進行需求排序。（9）需求復查：注意不完善的和需要獨立于特定架構實現(xiàn)的需求。17安全設計概述2.3總體設計階段內容總體設計又稱概要設計，此階段對比分析多種系統(tǒng)實現(xiàn)方案和軟件結構，從中選出最佳方案和最合理的軟件結構?？傮w設計階段的主要任務有：（1）系統(tǒng)設計：劃分出組成系統(tǒng)的物理元素。（2）結構設計：確定系統(tǒng)中程序的模塊組成，實現(xiàn)軟件安全性需求，確定模塊相互間的關系。詳細設計階段內容系統(tǒng)的詳細設計是在總體設計的基礎上進一步細化，為每項任務選擇適當?shù)募夹g手段和處理方法。詳細設計階段的主要內容有：（1）確定模塊采用的算法，寫出模塊的詳細過程性描述。（2）確定模塊使用的數(shù)據(jù)結構。（3）確定模塊接口的細節(jié)。包括對系統(tǒng)外部的接口、用戶界面，對系統(tǒng)內部模塊的接口、模塊輸入數(shù)據(jù)、輸出數(shù)據(jù)和局部數(shù)據(jù)等。（4）為每個模塊設計出測試用例。包括輸入數(shù)據(jù)，期望輸出等內容。安全設計原則（1）簡單易懂原則：代碼越復雜越難審查的透徹，越容易出錯。（2）最小特權原則：對于請求存儲資源的主體，只授予執(zhí)行操作所需的最少訪問權，而且應該保證對于該訪問權只準許使用所需的最少時間。（3）權限分離原則：把軟件劃分為不同獨立的模塊，把權限分離成不同的權限許可和認證條件，把用戶分離成不同的權限角色。（4）最少共享機制原則：避免多個主體共享同一個資源，因為敏感的信息可能通過相同的機制在這些主體之間共享導致被其他用戶獲取。安全設計原則（5）完全中立原則：每次主體對資源的請求，系統(tǒng)都應該實行認證和執(zhí)行檢查，特別是和安全相關的內容。（6）心理可接受度原則：安全機制不應妨礙資源的可用性或使得資源難以獲取，否則用戶很可能會選擇關閉這些安全機制或功能。（7）默認故障處理保護原則：當系統(tǒng)失效或產(chǎn)生故障時，必須是以安全的方式來處理系統(tǒng)信息，系統(tǒng)故障處理默認應該是安全的設置（8）不信任原則：開發(fā)者應假定系統(tǒng)環(huán)境是不安全的，對外部實體的所有輸入都應進行檢查。安全設計原則（9）縱深防御原則：用多重防御提高攻擊者的攻擊成本來管理風險。（10）保障最弱環(huán)節(jié)原則：攻擊者一般從系統(tǒng)最薄弱的環(huán)節(jié)發(fā)起攻擊，開發(fā)者應針對軟件的薄弱點實施更強的安全保護措施。（11）公開設計原則：假定攻擊者有能力獲取系統(tǒng)足夠的信息來發(fā)起攻擊，而不是依賴于攻擊者不可能知道來保護系統(tǒng)的安全。（12）隱私保護原則：系統(tǒng)收集到的用戶信息都應實施妥善和安全的保護。（13）攻擊面最小化原則：軟件的攻擊面越大，其安全風險也就越大。安全設計方法2.4危險性分析危險性分析是對系統(tǒng)存在的危險類別、出現(xiàn)條件、事故后果等進行分析，判斷系統(tǒng)潛在的危險性。危險性分析的步驟如下：（1）確定危險事件。將對危險事件有影響的單元確定為軟件安全性關鍵單元，分析這些單元影響危險事件的方式和途徑。（2）分析影響軟件安全性關鍵單元的其他單元對安全的影響。（3）分析軟件安全關鍵單元的詳細設計是否符合安全性設計的要求。確定在測試計劃、說明和規(guī)程中包含的需要的安全性要求。（4）確定在系統(tǒng)操作員、軟件用戶、系統(tǒng)診斷手冊等中包含安全性要求（5）確保編程人員了解安全關鍵單元，向程序員提供安全編程的建議。25基于模式的軟件安全設計基于模式的軟件安全設計通過組合以往的設計模式開發(fā)新的框架，實現(xiàn)設計過程的軟件復用，提升設計質量。常見的軟件安全設計模式有：（1）架構級模式：分為不信任分解、特權分離和推遲到內核。（2）設計級模式：分為安全工廠模式、安全策略工廠模式

、安全構建器工廠模式、責任安全鏈模式、安全狀態(tài)機器模式和安全訪問者模式等。（3）實施級模式：分為安全日志、清除敏感信息、安全目錄、路徑名規(guī)范化、輸入驗證

、資源獲取初始化等模式。26安全關鍵單元的確定和設計安全關鍵單元是指其錯誤可能導致系統(tǒng)存在嚴重危險的軟件單元。安全關鍵單元的確定需要對確定的安全性關鍵部件進行細化和分解，再對產(chǎn)生的軟件單元作進一步分析，從中確定安全性關鍵單元。安全性關鍵單元應遵循以下設計準則：（1）分離安全關鍵單元。保障非關鍵的單元故障不會影響關鍵單元。（2）安全關鍵單元至少受控于兩個獨立的單元。（3）安全關鍵單元必須具有強數(shù)據(jù)類型；（4）安全關鍵的計時單元必須由系統(tǒng)控制，不允許隨意修改。27威脅建模2.5威脅建模概述威脅建模以結構化的方式識別和評估系統(tǒng)面臨的威脅，使開發(fā)人員充分了解和管理可能的安全威脅，指導選擇恰當?shù)膽獙Υ胧?，降低安全防護成本，提高工程質量。威脅建模需要重復進行，因為：（1）安全人員很難一次找出所有威脅。（2）目前應用程序大多為動態(tài)，威脅建模過程需要隨著應用程序的發(fā)展不斷重復，改善并適應變化的應用程序。威脅建模過程（1）識別資源：找出系統(tǒng)必須保護的有價值的資源。（2）創(chuàng)建總體體系結構：利用簡單的圖表來記錄應用程序的體系結構。（3）分解應用程序：分解應用程序的體系結構。（4）識別威脅：根據(jù)應用程序的體系結構和潛在缺陷，找出可能影響應用程序的威脅。（5）記錄威脅：利用通用威脅模板記錄每種威脅。（6）評價威脅：對確定的威脅列表進行評價以區(qū)分優(yōu)先順序。威脅建模的輸出威脅建模過程的輸出是工作項目報告，內容包括應用程序體系結構安全方面的記錄和評價過的威脅列表。該工作項目報告可使項目成員更加清楚地了解需要處理的威脅，以及如何進行處理。（1）設計者利用項目報告來進行技術與功能方面的安全設計選擇決策。（2）開發(fā)者利用項目報告來降低風險。（3）測試人員利用項目報告編寫測試案例來