安全合規(guī)軟件安全開發(fā)過程規(guī)范

1、安全開發(fā)過程規(guī)范、SDL簡介SDL security development lifecycle （安全開發(fā)生命周期），是微軟提出的從安全角度指導軟件開發(fā)過程的管理模式。SDL是一個安全保證的過程，起重點是軟件開發(fā)，它在開 發(fā)的所有階段都引入了安全和隱私的原則。自2004年起，SDL一直都是微軟在全公司實施的強制性策略。二、SDL步驟圖SDL中的方法，試圖從安全漏洞產生的根源上解決問題，通過對軟件工程的控制，保證產 品的安全性。美國國家標準與技術研究所（NIST）估計，如果是在項目發(fā)布后在執(zhí)行漏洞修復計劃，其 修復成本相當于在設計階段執(zhí)行修復的 30倍三、SDL的步驟包括：階段 1：培訓開發(fā)團

2、隊的所有成員都必須接受適當的安全培訓，了解相關的安全知識，培訓對象包括開 發(fā)人員、測試人員、項目經理、產品經理等。階段 2：安全要求在項目確立之前，需要提前與項目經理或者產品 owner 進行溝通，確定安全的要求和需要 做的事情。確認項目計劃和里程碑，盡量避免因為安全問題而導致項目延期發(fā)布。階段 3：質量門 /bug 欄質量門和 bug 欄用于確定安全和隱私質量的最低可接受級別Bug 欄是應用于整個開發(fā)項目的質量門，用于定義安全漏洞的嚴重性閾值。例如，應用程 序在發(fā)布時不得包含具有“關鍵”或“重要”評級的已知漏洞。 Bug 欄一經設定，便絕不 能放松。階段 4：安全和隱私風險評估安全風險評估（

3、SRA和隱私風險評估（PRA）是一個必需的過程，必須包括以下信息：1、（安全）項目的哪些部分在發(fā)布前需要威脅模型？2、（安全）項目的哪些部分在發(fā)布前需要進行安全設計評析？3、（安全）項目的哪些部分需要并不食欲項目團隊且雙方認可的小組進行滲透測試？4、（安全）是否存在安全顧問認為有必要增加的測試或分析要求已緩解安全風險？5、（安全）模糊測試要求的具體范圍是什么？6、（安全）隱私影響評級如何？階段 5：設計要求在設計階段應仔細考慮安全和隱私問題，在項目初期確定好安全需求，盡可能避免安全引 起的需求變更。階段 6：減小攻擊面 減小攻擊面與威脅建模緊密相關，不過它解決安全問題的角度稍有不同。減小攻擊面

4、通過 減小攻擊者利用潛在弱點或漏洞的機會來降低風險，減小攻擊面包括：關閉或限制對系統(tǒng)服務的訪問，應用“最小權限原則”，以及盡可能進行分層防御 階段 7：威脅建模 為項目或產品面臨的威脅建立模型，明確可能來自的攻擊有哪些方面。階段 8：使用指定的工具 開發(fā)團隊使用的編輯器、鏈接器等相關工具，可能會涉及一些安全相關的環(huán)節(jié)，因此在使 用工具的版本上，需要提前與安全團隊進行溝通。階段 9：棄用不安全函數許多常用函數可能存在安全隱患，應當禁用不安全的函數和API，使用安全團隊推薦的函數。階段 10：靜態(tài)分析 代碼靜態(tài)分析可以由相關工具輔助完成，其結果與人工分析相結合。階段 11：動態(tài)程序分析 動態(tài)分析是

5、靜態(tài)分析的補充，用于測試環(huán)節(jié)驗證程序的安全性。階段 12：模糊測試( Fuzzing Test ) 模糊測試是一種專門形式的動態(tài)分析，它通過故意向應用程序引入不良格式或隨機數據誘發(fā)程序故障。模糊測試策略的制定，以應用程序的預期用途，以及應用程序的功能和設計規(guī)范為基礎。安全顧問可能要求進行額外的模糊測試，或者擴大模糊測試的范圍和增加持 續(xù)時間 階段 13：威脅模型和攻擊面評析項目經常會因為需求等因素導致最終的產出偏離原本設定的目標，因此在項目后期對威脅 模型和攻擊面進行評析是有必要的，能夠及時發(fā)現問題并修正。階段 14：事件響應計劃受 SDL 要求約束的每個軟件在發(fā)布時都必須包含事件響應計劃。即

6、使在發(fā)布時不包含任何 已知漏洞的產品，也可能在日后面臨新出現的威脅。需要注意的是，如果產品中包含第三 方的代碼，也需要留下第三方的聯(lián)系方式并加入事件響應計劃，以便在發(fā)生問題時能夠找 到對應的人。階段 15：最終安全評析最終安全評析（FSR是在發(fā)布之前仔細檢查對軟件執(zhí)行的所有安全活動。通過FSR將得出以下三種不同不同結果。1、通過FSR在FSR過程中確定所有安全和隱私問題都已得到修復或緩解。2、通過FSR但有異常。在FSR過程中確定所有安全和隱私問題都已得到修復或緩解，并 且/ 或者所有異常都已得到圓滿解決。無法解決的問題將記錄下來，在下次發(fā)布時更正。3、需上報問題的FSR如果團隊未滿足所有SD

7、L要求，并且安全顧問和產品團隊無法達 成可接受的折中，則安全顧問不能批準項目，項目不能發(fā)布。團隊必須在發(fā)布之前解決所 有可解決的問題，或者上報高級管理層進行抉擇。階段 16：發(fā)布 / 存檔 在通過FSR或者雖有問題但達成一致后，可以完成產品的發(fā)布。但發(fā)布的同時仍需對各種問題和文檔進行存檔，為緊急響應和產品升級提供幫助 從以上的過程可以看出，微軟的 SDL的過程實施非常細致。微軟這些年來也一直幫助公司 的所有產品團隊，以及合作伙伴實施 SDL效果相當顯著。相對于微軟的 SDL OWAS推出了 SAMMSoftware Assuranee Maturity Model ），幫助開 發(fā)者在軟件工程的過程中實施安全SAMMf SDL的主要區(qū)別在于，SDL適用于軟件開發(fā)商，他們以販售軟件為主要業(yè)務；而SAMM 更適用于自主開發(fā)軟件的使用者，如銀行或在線服務提供商。軟件開發(fā)商的軟件工程往往 較為成熟，有著嚴格的質量控制；而自主開發(fā)軟件的企業(yè)組織，則更強調高效，因此在軟 件工程的做法上也存在差異。四、SDL實戰(zhàn)經驗準則：準則一：與項目經理進行充分溝通，排除足夠的時間準則二：規(guī)范公司的立項