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

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

2、須接受適當(dāng)?shù)陌踩嘤?xùn)，了解相關(guān)的安全知識，培訓(xùn)對象包括開發(fā)人員、測試人員、項(xiàng)目經(jīng)理、產(chǎn)品經(jīng)理等。階段2:安全要求在項(xiàng)目確立之前，需要提前與項(xiàng)目經(jīng)理或者產(chǎn)品owner進(jìn)行溝通，確定安全的要求和需要做的事情。確認(rèn)項(xiàng)目計(jì)劃和里程碑，盡量避免因?yàn)榘踩珕栴}而導(dǎo)致項(xiàng)目延期發(fā)布。階段3:質(zhì)量門/bug欄質(zhì)量門和bug欄用于確定安全和隱私質(zhì)量的最低可接受級別。Bug欄是應(yīng)用于整個(gè)開發(fā)項(xiàng)目的質(zhì)量門，用于定義安全漏洞的嚴(yán)重性閾值。例如，應(yīng)用程序在發(fā)布時(shí)不得包含具有“關(guān)鍵”或“重要”評級的已知漏洞。Bug欄一經(jīng)設(shè)定，便絕不能放松。階段4:安全和隱私風(fēng)險(xiǎn)評估安全風(fēng)險(xiǎn)評估（SRQ和隱私風(fēng)險(xiǎn)評估（PRA遢一個(gè)必需的過程，

3、必須包括以下信息：1、（安全）項(xiàng)目的哪些部分在發(fā)布前需要威脅模型？2、（安全）項(xiàng)目的哪些部分在發(fā)布前需要進(jìn)行安全設(shè)計(jì)評析？3、（安全）項(xiàng)目的哪些部分需要并不食欲項(xiàng)目團(tuán)隊(duì)且雙方認(rèn)可的小組進(jìn)行滲透測試？4、（安全）是否存在安全顧問認(rèn)為有必要增加的測試或分析要求已緩解安全風(fēng)險(xiǎn)？5、（安全）模糊測試要求的具體范圍是什么？6、（安全）隱私影響評級如何？階段5:設(shè)計(jì)要求在設(shè)計(jì)階段應(yīng)仔細(xì)考慮安全和隱私問題，在項(xiàng)目初期確定好安全需求，盡可能避免安全引起的需求變更。階段6:減小攻擊面減小攻擊面與威脅建模緊密相關(guān)，不過它解決安全問題的角度稍有不同。減小攻擊面通過減小攻擊者利用潛在弱點(diǎn)或漏洞的機(jī)會來降低風(fēng)險(xiǎn)，減小攻

4、擊面包括：關(guān)閉或限制對系統(tǒng)服務(wù)的訪問，應(yīng)用“最小權(quán)限原則”，以及盡可能進(jìn)行分層防御。階段7:威脅建模為項(xiàng)目或產(chǎn)品面臨的威脅建立模型，明確可能來自的攻擊有哪些方面。階段8:使用指定的工具開發(fā)團(tuán)隊(duì)使用的編輯器、鏈接器等相關(guān)工具，可能會涉及一些安全相關(guān)的環(huán)節(jié)，因此在使用工具的版本上，需要提前與安全團(tuán)隊(duì)進(jìn)行溝通。階段9:棄用不安全函數(shù)許多常用函數(shù)可能存在安全隱患，應(yīng)當(dāng)禁用不安全的函數(shù)和API,使用安全團(tuán)隊(duì)推薦的函數(shù)。階段10:靜態(tài)分析代碼靜態(tài)分析可以由相關(guān)工具輔助完成，其結(jié)果與人工分析相結(jié)合。階段11:動(dòng)態(tài)程序分析動(dòng)態(tài)分析是靜態(tài)分析的補(bǔ)充，用于測試環(huán)節(jié)驗(yàn)證程序的安全性。階段12：模糊測試(Fuzzin

5、gTest模糊測試是一種專門形式的動(dòng)態(tài)分析，它通過故意向應(yīng)用程序引入不良格式或隨機(jī)數(shù)據(jù)誘發(fā)程序故障。模糊測試策略的制定，以應(yīng)用程序的預(yù)期用途，以及應(yīng)用程序的功能和設(shè)計(jì)規(guī)范為基礎(chǔ)。安全顧問可能要求進(jìn)行額外的模糊測試，或者擴(kuò)大模糊測試的范圍和增加持續(xù)時(shí)間。階段13:威脅模型和攻擊面評析項(xiàng)目經(jīng)常會因?yàn)樾枨蟮纫蛩貙?dǎo)致最終的產(chǎn)出偏離原本設(shè)定的目標(biāo)，因此在項(xiàng)目后期對威脅模型和攻擊面進(jìn)行評析是有必要的，能夠及時(shí)發(fā)現(xiàn)問題并修正。階段14：事件響應(yīng)計(jì)劃受SDL要求約束的每個(gè)軟件在發(fā)布時(shí)都必須包含事件響應(yīng)計(jì)劃。即使在發(fā)布時(shí)不包含任何已知漏洞的產(chǎn)品，也可能在日后面臨新出現(xiàn)的威脅。需要注意的是，如果產(chǎn)品中包含第三方的

6、代碼，也需要留下第三方的聯(lián)系方式并加入事件響應(yīng)計(jì)劃，以便在發(fā)生問題時(shí)能夠找到對應(yīng)的人。階段15:最終安全評析最終安全評析(FSR是在發(fā)布之前仔細(xì)檢查對軟件執(zhí)行的所有安全活動(dòng)。通過FSR將得出以下三種不同不同結(jié)果。1、 通過FSR在FSR過程中確定所有安全和隱私問題都已得到修復(fù)或緩解。2、 通過FSR但有異常。在FSR過程中確定所有安全和隱私問題都已得到修復(fù)或緩解，并且/或者所有異常都已得到圓滿解決。無法解決的問題將記錄下來，在下次發(fā)布時(shí)更正。3、 需上報(bào)問題的FSR如果團(tuán)隊(duì)未滿足所有SDL要求，并且安全顧問和產(chǎn)品團(tuán)隊(duì)無法達(dá)成可接受的折中，則安全顧問不能批準(zhǔn)項(xiàng)目，項(xiàng)目不能發(fā)布。團(tuán)隊(duì)必須在發(fā)布之前

7、解決所有可解決的問題，或者上報(bào)高級管理層進(jìn)行抉擇。階段16:發(fā)布/存檔在通過FSR者雖有問題但達(dá)成一致后，可以完成產(chǎn)品的發(fā)布。但發(fā)布的同時(shí)仍需對各種問題和文檔進(jìn)行存檔，為緊急響應(yīng)和產(chǎn)品升級提供幫助。從以上的過程可以看出，微軟的SDL的過程實(shí)施非常細(xì)致。微軟這些年來也一直幫助公司的所有產(chǎn)品團(tuán)隊(duì)，以及合作伙伴實(shí)施SDL效果相當(dāng)顯著。相對于微軟的SDL,OWASP推出了SAMM(SoftwareAssuranceMaturityModel),幫助開發(fā)者在軟件工程的過程中實(shí)施安全SAMM與SDL的主要區(qū)別在于，SDL適用于軟件開發(fā)商，他們以販?zhǔn)圮浖橹饕獦I(yè)務(wù)；而SAMM更適用于自主開發(fā)軟件的使用者，如銀行或在線服務(wù)提供商。軟件開發(fā)商的軟件工程往往較為成熟，有著嚴(yán)格的質(zhì)量控制；而自主開發(fā)軟件的企業(yè)組織，則更強(qiáng)調(diào)高效，因此在軟件工程的做法上也存在差異。四、SDL實(shí)戰(zhàn)經(jīng)驗(yàn)準(zhǔn)則：準(zhǔn)則一：與項(xiàng)目經(jīng)理進(jìn)行充分溝通，排除足夠的時(shí)間準(zhǔn)則二：規(guī)范公司的立項(xiàng)流程