摘要： 本文介紹可信賴計算安全開發(fā)生命周期（或 SDL），即 Microsoft 在開發(fā)需要抵御惡意攻擊的軟件時采用的一套流程。 該流程在 Microsoft 軟件開發(fā)流程的每個階段添加了一系列關(guān)注安全性的活動和交付結(jié)果。 這些活動和交付結(jié)果包括在軟件設(shè)計過程中開發(fā)威脅模型、在實施過程中使用靜態(tài)分析代碼掃描工具以及在集中進(jìn)行的“安全推動”過程中進(jìn)行代碼審核和安全測試。 應(yīng)用 SDL 的軟件在發(fā)布之前，必須由獨立于開發(fā)小組的另一個小組執(zhí)行最終安全審核。 與未應(yīng)用 SDL 的軟件相比，應(yīng)用了 SDL 的軟件從外部發(fā)現(xiàn)其安全漏洞的機(jī)率顯著降低。 本文介紹 SDL 并討論了在 Microsoft 軟件開發(fā)過程中實施該流程的經(jīng)驗。
注意 本文是 2004 計算機(jī)安全應(yīng)用年會上發(fā)表的”可信賴計算安全開發(fā)生命周期“一文的更新版本，這次大會由 IEEE 主辦，已于 2004 年 12 月在亞利桑那州圖森市舉行。
1. 簡介
所有軟件供應(yīng)商都有必要解決安全威脅方面的問題。 對軟件供應(yīng)商來說，安全性是其核心要求，這是由市場力量所驅(qū)動，也是由保護(hù)關(guān)鍵基礎(chǔ)結(jié)構(gòu)及建立和保持計算的廣泛信任的需要所決定的。 所有軟件供應(yīng)商面對的一個主要挑戰(zhàn)就是創(chuàng)建更加安全的軟件，使其不需要頻繁地通過修補(bǔ)程序進(jìn)行更新，且需要進(jìn)行的安全管理工作也更少。
對于軟件行業(yè)來說，要滿足當(dāng)今提升安全性的需要，關(guān)鍵在于實施可重復(fù)的流程，通過這些流程可靠地實現(xiàn)可測量的安全性提升。 因此，軟件供應(yīng)商必須轉(zhuǎn)為采用一種更嚴(yán)格的、更加關(guān)注安全性的軟件開發(fā)流程。 這種流程旨在盡量減少設(shè)計、編碼和文檔編寫過程中存在的漏洞，并在開發(fā)生命周期中盡可能早地檢測到并消除這些漏洞。 用于處理來自 Internet 的輸入、控制可能被攻擊的關(guān)鍵系統(tǒng)或處理個人身份信息的企業(yè)和消費者軟件最需要實施這種流程。
構(gòu)建更安全的軟件可從三個方面著手：可重復(fù)的流程、工程師教育以及度量標(biāo)準(zhǔn)和可測量性。 本文檔重點介紹 SDL 的可重復(fù)流程方面，雖然也討論了工程師教育并提供了反映目前部分應(yīng)用 SDL 的影響的一些總體指標(biāo)。
如果參照 Microsoft 的經(jīng)驗，其他組織采用 SDL 應(yīng)該不會為軟件開發(fā)增加不合理的成本。 根據(jù) Microsoft 的經(jīng)驗，提供更安全的軟件的益處（例如，更少的補(bǔ)丁和更加滿意的用戶）超過付出的代價。
SDL 會集成一些有助于提升軟件安全性的措施，在此過程中可能需要對軟件開發(fā)組織的流程進(jìn)行調(diào)整。 本文檔概述了這些措施，并說明了將其集成到典型的軟件開發(fā)生命周期中的方法。 進(jìn)行這些調(diào)整的目的不是要完全改變開發(fā)流程，而是在開發(fā)流程中加入一些精心定義的安全檢查點和安全性交付結(jié)果。
本文假定公司（或軟件開發(fā)組織）中存在一個中央小組，該小組致力于推動最佳安全做法的制訂與改進(jìn)和流程優(yōu)化，為整個組織提供專家意見，并在軟件發(fā)布前對其進(jìn)行審核（最終安全審核或 FSR）。 根據(jù) Microsoft 的經(jīng)驗，設(shè)立這樣一個組織對成功實施 SDL 和提升軟件安全性十分重要。 可能有些組織會考慮由承包商或顧問擔(dān)任“中央安全小組”角色。 本文介紹如何將旨在提升軟件安全性的一系列步驟集成到大型軟件開發(fā)組織通常使用的軟件開發(fā)流程中。 Microsoft 設(shè)計并實施了這些步驟，作為其可信賴計算計劃的一部分。 這些流程改進(jìn)的目標(biāo)是減少用戶使用的軟件中安全漏洞的數(shù)量并降低安全漏洞的嚴(yán)重程度。 在本文中，這種經(jīng)過調(diào)整的軟件開發(fā)流程，即當(dāng)前在 Microsoft 實施的流程被稱為可信賴計算軟件開發(fā)生命周期（或簡稱為 SDL）。
Microsoft 的經(jīng)驗是在軟件設(shè)計和開發(fā)過程中必須經(jīng)常與安全小組進(jìn)行互動，并必須與其共享敏感的技術(shù)和商業(yè)信息。 由于以上原因，最好的解決方案是在軟件開發(fā)組織內(nèi)部建立一個安全小組（雖然可能有必要請顧問人員幫助建立小組和培訓(xùn)小組的成員）。
1.1 基本流程
在 Microsoft 普遍采用的軟件開發(fā)流程大致如圖 1 所示。 從更高層面上看，這也是行業(yè)內(nèi)的典型流程。
圖 1. 標(biāo)準(zhǔn)的 Microsoft 開發(fā)流程
盡管圖 1 顯示了五個里程碑，看起來開發(fā)流程好像是“瀑布式”的，實際上該流程是螺旋形的。 為了對市場需求的變化和軟件實施中遇到的實際情況做出反應(yīng)，在實施階段可能經(jīng)常需要重新考慮需求和設(shè)計問題。 并且，該開發(fā)流程強(qiáng)調(diào)在幾乎每個點都要提供運行代碼，這樣每個主要里程碑實際上分解為交付一系列構(gòu)件，從而可以不斷向前地測試和操作使用這些構(gòu)件（由開發(fā)小組進(jìn)行）。
1.2 安全開發(fā)生命周期概述
現(xiàn)實世界中的軟件安全性方面的經(jīng)驗已經(jīng)為構(gòu)建更安全的軟件建立了一套高標(biāo)準(zhǔn)的原則。 Microsoft 將這些原則稱作 SD3+C – 設(shè)計安全、默認(rèn)安全、部署安全和通信。 這些原則的簡要定義如下：
•設(shè)計安全：在架構(gòu)、設(shè)計和實現(xiàn)軟件時，應(yīng)使它在運行時能保護(hù)自身及其處理的信息，并能抵御攻擊。
•默認(rèn)安全：在現(xiàn)實世界中，軟件達(dá)不到絕對安全，所以設(shè)計者應(yīng)假定其存在安全缺陷。 為了使攻擊者針對這些缺陷發(fā)起攻擊時造成的損失最小，軟件在默認(rèn)狀態(tài)下應(yīng)具有較高的安全性。 例如，軟件應(yīng)在最低的必要權(quán)限下運行，非廣泛需要的服務(wù)和功能在默認(rèn)情況下應(yīng)被禁用或僅可由少數(shù)用戶訪問。
•部署安全：軟件應(yīng)該隨附工具和指導(dǎo)以幫助最終用戶和/或管理員安全地使用它。 此外，更新應(yīng)該易于部署。
•通信：軟件開發(fā)者應(yīng)為產(chǎn)品漏洞的發(fā)現(xiàn)做好準(zhǔn)備并坦誠負(fù)責(zé)地與最終用戶和/或管理員進(jìn)行通信，以幫助他們采取保護(hù)措施（如打補(bǔ)丁或部署變通辦法）。
盡管 SD3+C 的每個要素均對開發(fā)流程提出了要求，但前兩個要素（設(shè)計安全和默認(rèn)安全）對提升安全性的作用最大。 設(shè)計安全改進(jìn)流程以防止在第一階段引入漏洞，默認(rèn)安全則要求軟件默認(rèn)狀態(tài)下暴露的地方，即“攻擊面”達(dá)到最小。
在現(xiàn)有開發(fā)流程中引入旨在集成 SD3+C 方法的安全措施后形成的總體流程結(jié)構(gòu)如圖 2 所示。
圖 2. SDL 對 Microsoft 開發(fā)流程的改進(jìn)
本文的第 2 節(jié)從更高層面介紹了 SDL 的各個組件。 第 3 節(jié)簡要概述了 Microsoft 實施 SDL 的特定情況。 本文第 4 節(jié)提供了一些說明性的數(shù)據(jù)，展示了在 Microsoft Windows Server 2003 和其他軟件開發(fā)過程中對 SDL 的早期應(yīng)用在減少安全漏洞數(shù)和嚴(yán)重性等級方面（與之前的軟件版本相比）起到的作用。 第 5 節(jié)根據(jù) Microsoft 應(yīng)用 SDL 的經(jīng)驗對流程各要素進(jìn)行了定性討論。 最后，第 6 節(jié)進(jìn)行了總結(jié)。
2. 安全開發(fā)生命周期流程
如前所述，工程師教育已超出本文的討論范圍。 但是必須認(rèn)識到教育計劃對 SDL 的成功實施至關(guān)重要。 計算機(jī)科學(xué)和相關(guān)專業(yè)的大學(xué)應(yīng)屆畢業(yè)生一般缺乏必要的培訓(xùn)，不能立即加入工作隊伍從事安全軟件的設(shè)計、開發(fā)或測試工作。 即使是學(xué)了安全課程的人員，他們可能對加密算法或訪問控制模型接觸較多，但是對緩沖區(qū)溢出或規(guī)范化缺陷可能了解不多。 一般情況下，行業(yè)內(nèi)的軟件設(shè)計者、工程師和測試人員也缺乏適當(dāng)?shù)陌踩夹g(shù)知識。
在這些情況下，準(zhǔn)備開發(fā)安全軟件的組織必須負(fù)責(zé)對其工程人員進(jìn)行適當(dāng)教育。 根據(jù)組織的規(guī)模和可用的資源，應(yīng)付這種挑戰(zhàn)的方法可能會有所不同。 擁有大批工程人員的組織可建立一個內(nèi)部計劃對其工程師進(jìn)行在職安全培訓(xùn)，而小型組織則可能需要依賴外部培訓(xùn)。 在 Microsoft，所有從事軟件開發(fā)的人員必須參加一年一次的“安全進(jìn)修課程”培訓(xùn)。
2.1 需求階段
安全系統(tǒng)開發(fā)的一個基本原則就是需要“自下而上”地考慮安全問題。 盡管很多開發(fā)項目開發(fā)出的“后續(xù)版本”是建立在先前發(fā)布的版本基礎(chǔ)上，但是新的發(fā)行版或版本的需求階段和初始規(guī)劃仍然為構(gòu)建安全軟件提供了極好的機(jī)會。
在需求階段中，產(chǎn)品小組與中央安全小組聯(lián)系，請求指派安全顧問（在 Microsoft 實施 SDL 時稱為“安全員”），該安全顧問在進(jìn)行規(guī)劃時充當(dāng)聯(lián)絡(luò)點，并提供資源和指導(dǎo)。 安全顧問通過審核計劃、提出建議和確保安全小組規(guī)劃適當(dāng)?shù)馁Y源來支持產(chǎn)品小組的日程，為產(chǎn)品小組提供協(xié)助。 安全顧問在安全里程碑和出口標(biāo)準(zhǔn)方面向產(chǎn)品小組提出建議，這些安全里程碑和出口標(biāo)準(zhǔn)是由項目的規(guī)模、復(fù)雜程度和風(fēng)險決定的。 從項目開始到完成最終安全審核和軟件發(fā)布，安全顧問始終充當(dāng)產(chǎn)品小組與安全小組之間的聯(lián)系點。 安全顧問還充當(dāng)安全小組和產(chǎn)品小組管理人員之間的聯(lián)系人，向小組管理人員提供關(guān)于項目的安全要素是否正常工作的意見，以避免在流程的晚期出現(xiàn)安全方面的問題。
在需求階段中，產(chǎn)品小組應(yīng)考慮如何在開發(fā)流程中集成安全性，找出關(guān)鍵的安全性對象，以及在盡量提升軟件安全性的同時盡量減少對計劃和日程的影響。 在此過程中，產(chǎn)品小組需要考慮如何使軟件的安全功能和保證措施與其他可能與該軟件配合使用的軟件相互集成。 （要滿足用戶將各個產(chǎn)品集成到安全系統(tǒng)的需要，考慮與其他軟件的接口非常關(guān)鍵。）產(chǎn)品小組關(guān)于安全目標(biāo)、挑戰(zhàn)和計劃的整體構(gòu)想必須反映到需求階段中制作的規(guī)劃文檔中。 雖然計劃可能會隨著項目的進(jìn)行而變化，但是較早地明確制訂這些計劃將有助于確保不會忽視任何需求或不會直到最后一刻才發(fā)現(xiàn)它們。
每個產(chǎn)品小組都應(yīng)將安全性要求視為此階段的重要組成部分。 盡管有些安全性要求將在威脅建模過程中確定，但是用戶需求可能要求根據(jù)客戶的要求來考慮一些安全性。 符合行業(yè)標(biāo)準(zhǔn)或認(rèn)證過程（如通用標(biāo)準(zhǔn)）的需要也可能提出一些安全性要求。 作為正常規(guī)劃流程的一部分，產(chǎn)品小組應(yīng)認(rèn)識到并反映這些要求。
2.2 設(shè)計階段
設(shè)計階段確定軟件的總體需求和結(jié)構(gòu)。 從安全性的角度來看，設(shè)計階段的關(guān)鍵要素包括：
•定義安全體系結(jié)構(gòu)和設(shè)計指導(dǎo)原則：從安全性角度定義軟件的總體結(jié)構(gòu)，并確定對安全性起關(guān)鍵作用的組件（“可信賴計算基礎(chǔ)”）。 確定將在軟件中全面應(yīng)用的設(shè)計技巧，如分層、使用強(qiáng)類型語言、應(yīng)用最低權(quán)限和使攻擊面最小化。 （分層 指的是將軟件組織成精心定義的組件以避免組件之間出現(xiàn)循環(huán)依賴關(guān)系 — 將組件組織為層，高級層可以依賴低級層的服務(wù)，且禁止低級層依賴高級層的服務(wù)。）體系結(jié)構(gòu)中各要素的特點將在各自的設(shè)計規(guī)范中詳細(xì)說明，而安全體系結(jié)構(gòu)只是確定安全設(shè)計的總體構(gòu)想。
•記錄軟件攻擊面的要素。 由于軟件不可能絕對的安全，所以必須重視的是：默認(rèn)情況下應(yīng)僅將大多數(shù)用戶需要使用的功能對所有用戶開放，且可以用盡可能最低的權(quán)限安裝那些功能。 對攻擊面要素進(jìn)行度量可為產(chǎn)品小組提供默認(rèn)安全性的現(xiàn)行度量標(biāo)準(zhǔn)，使產(chǎn)品小組可以檢測到令軟件易受攻擊的情況。 盡管有些增加攻擊面的情況可能是因為增加了產(chǎn)品功能或可用性導(dǎo)致的，但是在設(shè)計和實施過程中還是需要對每種這樣的情況進(jìn)行認(rèn)真檢測和研究，以確保軟件交付時在默認(rèn)配置下具有最好的安全性。
•對威脅進(jìn)行建模。 產(chǎn)品小組逐個組件地對威脅進(jìn)行建模。 組件小組使用結(jié)構(gòu)化的方法，確定軟件必須管理的模塊以及訪問那些模塊時所使用的接口。 威脅建模過程確定可能對每個模塊造成損害的威脅以及導(dǎo)致?lián)p害的可能性（風(fēng)險評估）。 組件小組然后確定降低風(fēng)險的對策 — 通過安全功能（如加密）或通過正確使用保護(hù)模塊免受損害的軟件。 這樣，威脅建?？梢詭椭a(chǎn)品小組確定安全性需求，以及需要特別仔細(xì)地審核代碼和進(jìn)行安全測試的領(lǐng)域。 應(yīng)使用工具來支持威脅建模過程，該工具應(yīng)可以處理機(jī)器可讀格式的威脅模型，并可以對其進(jìn)行存儲和更新。
•定義補(bǔ)充性交付標(biāo)準(zhǔn)。 盡管應(yīng)定義組織的基本安全交付標(biāo)準(zhǔn)，但是各個產(chǎn)品小組或軟件版本也可以設(shè)立發(fā)布軟件前必須符合的特定標(biāo)準(zhǔn)。 例如，正在開發(fā)一個準(zhǔn)備交付用戶使用并可能面臨高強(qiáng)度攻擊的軟件更新版本的產(chǎn)品小組可以建立這樣的標(biāo)準(zhǔn)：在一段時間內(nèi)外部沒有發(fā)現(xiàn)新版本漏洞時才認(rèn)為它已做好發(fā)布的準(zhǔn)備。 （也就是說，開發(fā)過程應(yīng)在漏洞被報告之前找到并消除這些漏洞，而不是在產(chǎn)品小組接到報告之后不得不“修復(fù)”這些漏洞。）
2.3 實施階段
在實施階段，產(chǎn)品小組對軟件進(jìn)行編碼、測試和集成。 在此階段將采取措施消除安全缺陷或防止引入安全缺陷的作用很大 — 這些措施將大大減少安全漏洞遺留到發(fā)布給用戶的軟件最終版本中的可能性。
威脅建模的成果為實施階段提供特別重要的指導(dǎo)。 開發(fā)者應(yīng)特別注意確保代碼的正確性以消除高優(yōu)先級威脅，測試者可集中對這些威脅進(jìn)行測試以確保將其攔截或消除。
在實施階段中應(yīng)用的 SDL 要素為：
•應(yīng)用編碼和測試標(biāo)準(zhǔn)。 編碼標(biāo)準(zhǔn)幫助開發(fā)者避免引入導(dǎo)致安全漏洞的缺陷。 例如，使用更安全和更一致的字符串處理和緩沖區(qū)操縱結(jié)構(gòu)有助于避免引入緩沖區(qū)溢出漏洞。 測試標(biāo)準(zhǔn)和最佳做法有助于確保將測試重點放在檢測潛在的安全漏洞上，而不僅僅是專注于測試軟件功能的正確運行。
•應(yīng)用包括模糊化工具在內(nèi)的安全測試工具。 “模糊化”為軟件應(yīng)用程序編程接口 (API) 和網(wǎng)絡(luò)接口提供結(jié)構(gòu)化但無效的輸入，以使檢測到可能導(dǎo)致軟件漏洞的錯誤的可能性最大化。
•應(yīng)用靜態(tài)分析代碼掃描工具。 這些工具可檢測出某些類型的可能導(dǎo)致漏洞的編碼缺陷，包括緩沖區(qū)溢出、整數(shù)溢出和未初始化變量。 Microsoft 在開發(fā)這類工具上已進(jìn)行了大量的投資（長期使用的兩個工具為 PREfix 和 PREfast），隨著新的編碼缺陷和軟件漏洞的發(fā)現(xiàn)，Microsoft 將繼續(xù)對這些工具進(jìn)行改進(jìn)。
•進(jìn)行代碼審核。 作為自動化工具和測試的補(bǔ)充，將由接受過培訓(xùn)的開發(fā)人員進(jìn)行代碼審核，他們將檢查源代碼并檢測和消除潛在的安全漏洞。 這是開發(fā)流程中從軟件中消除安全漏洞的關(guān)鍵步驟。
2.4 驗證階段
驗證階段是指軟件已具備所有功能并進(jìn)入用戶試用版測試的階段。 在此階段中，在對軟件進(jìn)行試用版測試時，產(chǎn)品小組進(jìn)行“安全推進(jìn)”，包括進(jìn)行安全代碼審核（超出實施階段中進(jìn)行的審核范圍）和集中式安全測試。
早在 2002 年，Microsoft 已在 Windows Server 2003 及其他軟件版本驗證階段引入了安全推進(jìn)。 在流程中引入安全推進(jìn)有兩個原因：
•有問題的軟件版本已進(jìn)入生命周期的驗證階段，此階段最適合進(jìn)行所需的集中式代碼審核和測試。
•在驗證階段進(jìn)行安全推進(jìn)可確保代碼審核和測試針對的是軟件的完成版本，并提供了對實施階段開發(fā)或更新的代碼以及未修改的“遺留代碼”進(jìn)行全部審核的機(jī)會。
其中第一個原因反映了歷史上的巧合：在驗證階段進(jìn)行安全推進(jìn)的決定。 但是 Microsoft 已證實在驗證階段進(jìn)行安全推進(jìn)確實是非常好的做法，既可以確保最終的軟件符合要求又可以對先前軟件版本的舊代碼進(jìn)行更深入的審核。
特別要注意的是對高優(yōu)先級代碼（成為軟件“攻擊面”一部分的代碼）進(jìn)行代碼審核和測試對 SDL 其他部分十分關(guān)鍵。 例如，在實施階段需要進(jìn)行這類審核和測試，以便盡早矯正任何問題，并確定和矯正這類問題的來源。 在驗證階段由于產(chǎn)品已接近完成，所以進(jìn)行這類審核和測試也十分重要。
2.5 發(fā)布階段
在發(fā)布階段中，應(yīng)對軟件進(jìn)行最終安全審核 (FSR)。 FSR 的目標(biāo)是要回答下面這個問題。 “從安全的角度看，此軟件是否已準(zhǔn)備好交付給客戶？”一般在軟件完成之前 2 到 6 個月進(jìn)行 FSR，具體時間根據(jù)軟件的規(guī)模決定。 在進(jìn)行 FSR 之前，軟件必須已處于穩(wěn)定狀態(tài)，且只剩一些很小的非安全性更改需要在發(fā)布前完成。
FSR 是由組織的中央安全小組對軟件進(jìn)行的獨立審核。 在進(jìn)行 FSR 之前，來自安全小組的安全顧問向產(chǎn)品小組建議軟件所需進(jìn)行 FSR 的范圍，并為產(chǎn)品小組提供資源需求列表。 產(chǎn)品小組為安全小組提供完成 FSR 所需的資源和信息。 FSR 開始時，產(chǎn)品小組需要填寫一份問卷并與派來進(jìn)行 FSR 的安全小組成員進(jìn)行面談。 所有 FSR 將要求對最初標(biāo)識為安全漏洞，但后來經(jīng)過深入分析確定為對安全性沒有影響的缺陷進(jìn)行審核，以確保分析的正確性。 FSR 還包括審核軟件是否能抵御最新報告的影響類似軟件的漏洞。 對主軟件版本進(jìn)行 FSR 時需要進(jìn)行滲透測試，可能還需要利用外面的安全審核承包商來協(xié)助安全小組。
FSR 不是簡單的通過/失敗測試，F(xiàn)SR 的目標(biāo)也不是找出軟件中所有剩余漏洞，因為這顯然不太可行。 實際上，F(xiàn)SR 是為產(chǎn)品小組和組織的高層管理人員提供：軟件的安全水平以及軟件發(fā)布給用戶后抵御攻擊的能力的總體狀況。 如果 FSR 發(fā)現(xiàn)某類剩余漏洞，正確的反應(yīng)是不僅要修復(fù)發(fā)現(xiàn)的漏洞，還要回到之前的階段并采取其他針對性的措施解決根本原因（例如，提高培訓(xùn)質(zhì)量和改進(jìn)工具）。
2.6 支持和服務(wù)階段
盡管在開發(fā)過程中應(yīng)用了 SDL，最先進(jìn)的開發(fā)方法還是無法保證發(fā)布的軟件完全沒有漏洞，而且有充分的理由證明永遠(yuǎn)都做不到。 即使開發(fā)流程可以在交付之前從軟件中消除所有漏洞，還是可能會發(fā)現(xiàn)新的攻擊方式，這樣過去“安全”的軟件也就不再安全。 因此，產(chǎn)品小組必須準(zhǔn)備好對交付給用戶的軟件中新發(fā)現(xiàn)的漏洞作出響應(yīng)。
響應(yīng)過程包括評估漏洞報告并在適當(dāng)?shù)臅r候發(fā)布安全建議和更新。 響應(yīng)過程還包括對已報告的漏洞進(jìn)行事后檢查以及采取必要的措施。 對漏洞采取的措施的范圍很廣：從為孤立的錯誤發(fā)布更新到更新代碼掃描工具以重新對主要的子系統(tǒng)進(jìn)行代碼審核。 響應(yīng)階段的目標(biāo)是從錯誤中吸取教訓(xùn)，并使用漏洞報告中提供的信息幫助在軟件投入使用前檢測和消除深層漏洞，以免這些漏洞給用戶帶來危害。 響應(yīng)過程還有助于產(chǎn)品小組和安全小組對流程進(jìn)行改造，以免將來犯類似錯誤。
3. Microsoft 實施安全開發(fā)生命周期的情況
自 2002 年初進(jìn)行“安全推進(jìn)”以來，Microsoft 的 SDL 實施不斷發(fā)展。 為了啟動該流程并對已進(jìn)入開發(fā)后期的產(chǎn)品產(chǎn)生影響，安全推進(jìn)將本應(yīng)分布在 SDL 多個階段的活動壓縮為相對短期的活動。 安全推進(jìn)對產(chǎn)品小組的計劃、資源和日程產(chǎn)生了重大影響，如果沒有 Microsoft 高層管理人員的積極支持，實施起來就會困難得多。 安全推進(jìn)將重點放在威脅建模、代碼審核和安全測試（包括滲透測試）上。 在 2002 年末和 2003 年初，在 Windows Server 2003 發(fā)布之前引入了最終安全審核 (FSR)，而 FSR 對 Windows Server 2003 交付時的默認(rèn)配置產(chǎn)生了重大影響。
在進(jìn)行初步的安全推進(jìn)和 FSR 之后，Microsoft 啟動了一個項目來使 SDL 流程正式化。 此項目有四個特殊成果值得特別注意：
•SDL 的強(qiáng)制應(yīng)用策略
•工程人員的強(qiáng)制教育
•產(chǎn)品小組的度量標(biāo)準(zhǔn)
•中央安全小組的角色
以下各節(jié)將分別介紹上述領(lǐng)域
3.1 SDL 的強(qiáng)制應(yīng)用
由于 SDL 產(chǎn)生了顯著的效果（請參閱第 5 節(jié)），Microsoft 決定正式要求對廣泛領(lǐng)域內(nèi)的軟件應(yīng)用 SDL。 在撰寫本文的時候，SDL 正在成為必須對以下類別的所有軟件強(qiáng)制應(yīng)用的流程：
•將用于處理個人或敏感信息的軟件
•將在企業(yè)或其他組織（包括學(xué)術(shù)機(jī)構(gòu)、政府或非贏利機(jī)構(gòu)）使用的軟件
•將連接至 Internet 或在網(wǎng)絡(luò)環(huán)境中使用的軟件
未強(qiáng)制 應(yīng)用 SDL 的 軟件包括不符合以上標(biāo)準(zhǔn)的獨立應(yīng)用程序（例如兒童游戲，像“魔法學(xué)校巴士”系列）。 但是，SDL 可以顯著地避免這種軟件影響運行該軟件的平臺（操作系統(tǒng)或其他軟件）的安全性。
3.2 強(qiáng)制教育
2002 年初的安全推進(jìn)的一個關(guān)鍵方面就是培訓(xùn)了產(chǎn)品小組的全部人員，包括所有開發(fā)人員、測試人員、程序經(jīng)理和文檔管理人員。 Microsoft 已正式要求對其軟件必須實施 SDL 流程的部門的工程師進(jìn)行一年一次的安全教育。 每年需要進(jìn)行知識更新是因為安全性事實上不是一個靜態(tài)的范疇：威脅、攻擊和防御都在不斷的演變。 因此，即使工程師已完全掌握影響其軟件的安全性方面的知識，在威脅發(fā)生變化時也必須接受新的培訓(xùn)。 例如，在過去四年中，整數(shù)溢出漏洞的重要性大大增加了，而且最近發(fā)現(xiàn)一些加密算法存在以前未知的漏洞。
Microsoft 已開發(fā)出一套通用的面向工程師的安全知識簡介和更新教程，以“現(xiàn)場培訓(xùn)”和數(shù)字媒體兩種形式提供。 Microsoft 以該教程作為基礎(chǔ)，然后再按軟件技術(shù)和工程師角色進(jìn)行專門的培訓(xùn)。 Microsoft 正在編寫一套安全教育課程，這套教程將根據(jù)技術(shù)、角色和學(xué)員的經(jīng)驗水平進(jìn)行專業(yè)化的細(xì)分。
很多 Microsoft 合作伙伴和客戶已經(jīng)在詢問何時能為他們提供 Microsoft 安全教育和流程。 Microsoft Press 已根據(jù) Microsoft 在安全性設(shè)計、編碼和威脅建模方面的內(nèi)部實踐出版了書籍，Microsoft Learning 也根據(jù) Microsoft 的內(nèi)部實踐提供了課程。
3.3 產(chǎn)品小組的度量標(biāo)準(zhǔn)
作為一個公司，Microsoft 相信一句名言“您無法管理無法測量的事物?！北M管設(shè)計一套能夠可靠測量軟件安全性的度量標(biāo)準(zhǔn)十分困難，還是有一些明顯可視為軟件安全性代表特征的度量標(biāo)準(zhǔn)。 這些度量標(biāo)準(zhǔn)包括工程人員的培訓(xùn)覆蓋面（在開發(fā)生命周期的開始階段）到在已向用戶發(fā)布的軟件中發(fā)現(xiàn)的漏洞數(shù)。
Microsoft 已設(shè)計出一套安全性度量標(biāo)準(zhǔn)，產(chǎn)品小組可將其用于監(jiān)控 SDL 的實施情況。 這些度量標(biāo)準(zhǔn)監(jiān)控 SDL 在小組內(nèi)的實施，從威脅建模到代碼審核和安全測試，再到提交 FSR 時軟件需具備的安全性。 隨著這些度量標(biāo)準(zhǔn)的持續(xù)實施，既允許小組追蹤自身的表現(xiàn)（提高、不變或下降），也允許將其表現(xiàn)與其他小組進(jìn)行對比。 這些度量標(biāo)準(zhǔn)將定期報告給高級產(chǎn)品小組管理人員和 Microsoft 主管人員。
3.4 中央安全小組
在 2002 年實施安全推進(jìn)之前，Microsoft 已建立了 Secure Windows Initiative (SWI) 小組，該小組的任務(wù)是提升軟件安全性并減少 Windows 的漏洞，并為負(fù)責(zé)開發(fā) Windows 以外產(chǎn)品的產(chǎn)品小組提供安全支持。 SWI 小組在組織和管理 Windows Server 2003 安全推進(jìn)活動中起中心作用，并為自 2002 年開始進(jìn)行的所有安全推進(jìn)活動提供了培訓(xùn)和咨詢支持。 SWI 小組還對 Windows Server 2003 進(jìn)行了 FSR，開創(chuàng)了 FSR 流程。
在 Microsoft，隨著 SDL 的正式推行，SWI 小組已取代中央安全小組的作用。 SWI 小組的責(zé)任包括：
•SDL 的開發(fā)、維護(hù)和改進(jìn)，包括定義流程的強(qiáng)制部分。
•工程師教育課程的開發(fā)、改進(jìn)和推行。
•指派“安全顧問”，這些顧問在流程中對產(chǎn)品小組進(jìn)行指導(dǎo)，為產(chǎn)品小組執(zhí)行審核并確保產(chǎn)品小組的問題得到及時、準(zhǔn)確和權(quán)威性的解答。
•擔(dān)任廣泛的安全主題事務(wù)方面的專家，確保提交給安全顧問或通過其提交的問題得到及時、準(zhǔn)確的解答。
•在軟件發(fā)布之前執(zhí)行最終安全審核。
•對已發(fā)布給用戶的軟件中報告的漏洞進(jìn)行技術(shù)調(diào)查，以確保找到問題的根本原因并作出適當(dāng)?shù)捻憫?yīng)。
在 Microsoft，SWI 小組的存在及其有效性已證實它是實施 SDL 過程中的關(guān)鍵因素。 Microsoft 的目標(biāo)是建立一個開發(fā)更安全軟件的可伸縮流程，要實現(xiàn)此目標(biāo)就需要在所有產(chǎn)品小組內(nèi)廣泛實施安全性要求。 然而，擁有一個高水平的中央安全小組還是對以下工作非常關(guān)鍵：提高公司內(nèi)產(chǎn)品小組的工作效率，并在其創(chuàng)建更安全的軟件方面提供支持。 中央安全小組還可以確保由產(chǎn)品小組之外的人員執(zhí)行 FSR。
4. Microsoft 實施安全開發(fā)生命周期的成果
現(xiàn)在 Microsoft 就得出結(jié)論宣布 SDL 提升了 Microsoft 軟件的安全性還為時過早，但是到目前為止所取得的成果令人鼓舞。
Windows Server 2003 是 Microsoft 實施 SDL 大部分流程的第一個操作系統(tǒng)。 圖 3 顯示了兩個最新的 Microsoft 服務(wù)器操作系統(tǒng)（Windows 2000 和 Windows Server 2003）發(fā)布后一年內(nèi)頒布的安全公告數(shù)。 （在發(fā)布 Windows 2000 的時候，Microsoft 還沒有正式的安全公告嚴(yán)重性分級系統(tǒng)。 Microsoft 已參照當(dāng)前的嚴(yán)重性分級系統(tǒng)對應(yīng)用于 Windows 2000 的每個安全公告進(jìn)行了評估。）正如本文前面所述，Windows Server 2003 開發(fā)時實施了大部分（但不是全部）SDL 流程，Windows 2000 開發(fā)時還沒有實施這些流程。
圖 3. Windows 實施 SDL 之前和之后的嚴(yán)重和重要安全公告數(shù)
有關(guān)嚴(yán)重性類別的定義，請參閱http://www.microsoft.com/technet/security/bulletin/rating.mspx。
其他 Microsoft 軟件發(fā)行版也應(yīng)用了 SDL 的一些要素。 SQL Server 和 Exchange Server 產(chǎn)品小組在發(fā)布 Service Pack（一種聚合安全性漏洞和其他問題的修復(fù)程序的軟件發(fā)行版）之前分別進(jìn)行了安全推進(jìn)（包括威脅建模、代碼審核和安全測試）。 SQL Server 安全推進(jìn)的成果主要體現(xiàn)在 SQL Server 2000 Service Pack 3 中，Exchange Server 安全推進(jìn)的成果主要體現(xiàn)在 Exchange 2000 Server Service Pack 3 中。 圖 4 和 5 顯示了發(fā)布各自的 Service Pack 之前和之后相同期限內(nèi)頒布的安全公告數(shù)（SQL Server 2000 的期限為 24 個月；Exchange 2000 Server 的期限為 18 個月）。
圖 4. SQL Server 2000 實施 SDL 之前和之后的安全公告數(shù)
圖 5. Exchange Server 2000 實施 SDL 之前和之后的安全公告數(shù)
另一個鼓舞人心的例子是 Windows Server 2003 的 Internet 信息服務(wù)器組件 (IIS 6)，在發(fā)布之后兩年內(nèi)，Microsoft 只頒布了一個影響 Web 服務(wù)器的安全公告，并且這個公告所針對的還是在默認(rèn)情況下不會安裝的組件 (WebDAV)。
盡管安全性漏洞的例子比較少而且研究的時間段也有限，但是這些結(jié)果還是為 SDL 的有效性提供了有力的證據(jù)。 Microsoft 將繼續(xù)監(jiān)控 Windows Server 2003 以及 Exchange Server 和 SQL Server Service Pack 中出現(xiàn)的漏洞數(shù)，以觀察這種早期的趨勢是否會繼續(xù)下去。 Microsoft 還將分析其他在全面實施了 SDL 之后交付了新版本的 Microsoft 軟件，以確定安全漏洞的數(shù)量和嚴(yán)重性是否繼續(xù)下降
5. 應(yīng)用安全開發(fā)生命周期的觀察
前一節(jié)展示的數(shù)據(jù)提供了希望 SDL 達(dá)成的“目標(biāo)”的概況。 本節(jié)將嘗試回答一些關(guān)于該流程“如何”工作的問題。 前一節(jié)建立在強(qiáng)有力的數(shù)字基礎(chǔ)上（Microsoft 在跟蹤漏洞報告和安全公告方面非常嚴(yán)格），本節(jié)則建立在 SWI 小組人員所經(jīng)歷的事實基礎(chǔ)上（根據(jù)他們的觀察和意見）。
5.1 SDL 各要素的有效性
SDL 由 大量的子流程組成，這些子流程分布整個軟件開發(fā)生命周期內(nèi)。 已要求 SDL 小組按照有效性區(qū)分這些子流程的優(yōu)先級 — 哪些子流程效果最顯著，哪些子流程已試驗過卻效果不明顯。
SWI 小組的共識是威脅建模是 SDL 中最高優(yōu)先級的子流程。 顯然，威脅建模不能孤立地應(yīng)用：威脅建模促進(jìn)設(shè)計、代碼審核和測試，一個流程如果只實施威脅建模但對模型不采取任何響應(yīng)措施（例如未對緩解措施的有效性進(jìn)行測試），則將不會有任何效果。 缺陷數(shù)形式的統(tǒng)計數(shù)據(jù)不能很好地說明威脅建模的作用，因為威脅建模的主要作用在于確保不產(chǎn)生導(dǎo)致安全漏洞的缺陷。 然而，由于威脅建模在開發(fā)安全軟件流程中的作用極其關(guān)鍵，因此它顯然應(yīng)該排在最前面。
SDL 在 Microsoft 還是一個相對較新的流程，還沒有出現(xiàn)過刪除該流程中的子流程的情況。 但是，對長期研究安全的人員來說，有一個發(fā)現(xiàn)不會令人感到驚訝，即滲透測試不是獲得安全性的好方法。 滲透測試是對主軟件發(fā)行版進(jìn)行的最終安全審核 (FSR) 的要素之一，但是產(chǎn)品小組在整個生命周期中的活動主要集中在威脅建模、代碼審核、自動化工具的使用以及模糊化測試，而不是滲透測試。后面的這些措施在防止或消除安全缺陷方面比經(jīng)典的特定滲透測試更加全面有效。 FSR 的滲透測試要素有助于判斷軟件是否已準(zhǔn)備好可以發(fā)布，而不適合作為發(fā)現(xiàn)和修復(fù)安全缺陷的方法。 如果在 FSR 階段進(jìn)行的滲透測試發(fā)現(xiàn)了大量的安全缺陷，則是因為早期階段不夠有效，正確的處理方法是重新檢查那些階段中所謂已完成的活動，而不是僅僅修復(fù)滲透測試缺陷就發(fā)布軟件。
5.2 工具、測試和代碼審核
靜態(tài)分析工具、模糊化測試和代碼審核的作用是互補(bǔ)性的。 Microsoft 已在靜態(tài)分析代碼掃描工具方面進(jìn)行了大量的投資，這些工具的使用已成為 SDL 必不可少的一部分。 這些工具在發(fā)現(xiàn)許多會導(dǎo)致安全漏洞的編碼錯誤（特別是緩沖區(qū)溢出）方面很有效。 然而，當(dāng)前最先進(jìn)的工具也不能發(fā)現(xiàn)所有錯誤。 SDL 仍然需要進(jìn)行手動代碼審核，一方面是為了檢測到工具未發(fā)現(xiàn)的錯誤，另一方面也是為了確定可以在哪些方面改進(jìn)這些工具。 參考文獻(xiàn)中引用的由 Michael Howard 發(fā)表的 Microsoft Developer Network (MSDN) 文章概述了 Microsoft 要求其工程師在進(jìn)行代碼安全審核時使用的常用方法。
高度重視模糊化測試是最近才對 SDL 進(jìn)行的改進(jìn)，但是到目前為止所取得的成果非常令人鼓舞。 與靜態(tài)代碼掃描工具不同，必須為要測試的每種文件格式和/或網(wǎng)絡(luò)協(xié)議分別構(gòu)建（或至少分別配置）模糊化測試工具；因此，它們通?？梢园l(fā)現(xiàn)靜態(tài)分析工具遺漏的錯誤。 威脅模型有助于產(chǎn)品小組劃分要測試的接口和格式的優(yōu)先級。 模糊化測試的結(jié)果不是完全確定性的（這些工具只運行有限的循環(huán)次數(shù)，不保證能發(fā)現(xiàn)每個缺陷），但是經(jīng)驗表明進(jìn)行適當(dāng)級別的模糊化測試可以發(fā)現(xiàn)一些“感興趣”的缺陷，這此缺陷可能作為安全漏洞處理。
5.3 投資
強(qiáng)制安全培訓(xùn)對 Microsoft 這樣一個擁有大量工程人員的公司來說需要一筆巨額投資。 培訓(xùn)的推行結(jié)合了現(xiàn)場（導(dǎo)師引導(dǎo)）培訓(xùn)班和在線學(xué)習(xí)資料兩種方法。 在線學(xué)習(xí)資料對工作地址遠(yuǎn)離 Microsoft 總部的小型工程小組來說是特別有價值的辦法。 已證明現(xiàn)場培訓(xùn)在對準(zhǔn)備進(jìn)行安全推進(jìn)或其他關(guān)鍵活動的小組進(jìn)行全員培訓(xùn)時特別有效，在這些情況下，Microsoft 的經(jīng)驗表明小組培訓(xùn)的成果不僅可以在課堂培訓(xùn)上有所收獲，還可以在安全推進(jìn)的過程中得到體現(xiàn)。 每個工作組成員都要關(guān)注安全性這個事實使安全培訓(xùn)（通常為半天制）顯得更加重要。
最近幾年隨著 Microsoft 越來越重視安全性，中央安全小組（SWI 小組）得到了迅速成長。 通過精心設(shè)計，該小組相對于 Microsoft 工程人員總數(shù)來說相當(dāng)小，且重視“規(guī)模適當(dāng)”的方法，以確保開發(fā)更安全軟件的責(zé)任和資源植根于產(chǎn)品小組內(nèi)部。 反映這種對規(guī)模適當(dāng)?shù)闹匾暤囊恍┎呗园ǎ褐匾暸嘤?xùn)和工具，設(shè)置安全顧問幫助產(chǎn)品小組解決其自身問題（而不是代替其解決問題），以及通過進(jìn)行審核（包括 FSR）為產(chǎn)品小組就軟件是否已做好發(fā)布準(zhǔn)備提供反饋。
5.4 收益
SDL 的最終檢驗標(biāo)準(zhǔn)是在消除和減少 Microsoft 軟件中的漏洞方面的有效程度。 第 4 節(jié)中總結(jié)的經(jīng)驗表明 SDL 達(dá)到了這個檢驗標(biāo)準(zhǔn)。 Microsoft 還會評估外部報告的漏洞對正在開發(fā)的軟件版本的影響。 最近的經(jīng)驗表明，在新版本中規(guī)劃或?qū)嵤┑陌踩胧┏晒Φ刈柚惯^去對舊版本有效的攻擊的情況越來越多。 最近發(fā)布的 Windows XP Service Pack 2 就通過了這樣的審核，并發(fā)現(xiàn)已規(guī)劃但尚未實施或公開討論的安全更改消除了大量過去對 Windows 先前版本報告的漏洞（由外部安全研究人員向 Microsoft 報告的）。
6. 結(jié)論
Microsoft 的經(jīng)驗表明 SDL 在減少安全漏洞出現(xiàn)方面十分有效。 SDL 的初步實施（在 Windows Server 2003、SQL Server 2000 Service Pack 3 和 Exchange 2000 Server Service Pack 3 中）使軟件安全性得到了顯著提升，而且后續(xù)的軟件版本，更顯示出對 SDL 進(jìn)行改進(jìn)后，軟件安全性得到進(jìn)一步提升。
實施組成 SDL 的要素越多，對安全性的提升也就越多，這也是視為有效流程的一個特征。 該流程尚不完美，還在發(fā)展之中，而且在可以預(yù)見的將來也不會達(dá)到完美或停止發(fā)展。
安全開發(fā)生命周期的開發(fā)和實施對 Microsoft 來說意味著一筆重大投資，也是對軟件設(shè)計、開發(fā)和測試方法的重大變革。 軟件對社會的重要性在不斷增加，對 Microsoft 和整個軟件行業(yè)提升軟件安全性的要求也在不斷提高；因此發(fā)表這篇關(guān)于 SDL 的文章和有關(guān)特定技術(shù)的書籍（請參閱參考文獻(xiàn)）就是為了讓整個軟件行業(yè)分享 Microsoft 的經(jīng)驗。
7. 感謝
本文最初由現(xiàn)有作者從 2002 年末共同努力開始撰寫。 本文草稿隨著 SDL 的發(fā)展不斷進(jìn)行更新，當(dāng)前的版本在 2004 年夏季和秋季完成。 作者向在定義和改進(jìn) SDL 方面做出貢獻(xiàn)的 Matt Thomlinson、Matt Lyons、Jamil Villani 和 Eric Bidstrup（Microsoft Secure Windows Initiative 小組全體成員）表示衷心的感謝。 除了上述對本文做出貢獻(xiàn)的人士，Microsoft 的 Scott Charney 和 Phil Reitinger 以及卡耐基梅隆大學(xué)的 Jeannette Wing 也對草稿提出了特別有幫助的意見。 作者還要感謝 Martin Abadi、Virgil Gligor、Dick Kemmerer、Chris Mitchell、Fred Schneider、Neeraj Suri 和 James Whittaker 為本文提出寶貴的意見和建議。
8. 參考文獻(xiàn)
Mundie, Craig, Trustworthy Computing White Paper
Howard, Michael, Attack Surface: Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users, MSDN Magazine, November 2004
Howard, Michael, Expert Tips for Finding Security Defects in Your Code, MSDN Magazine, November 2004
Howard, Michael and David LeBlanc, Writing Secure Code, Second Edition, Microsoft Press, Redmond, Washington, 2003
Swiderski, Frank and Window Snyder, Threat Modeling, Second Edition, Microsoft Press, Redmond, Washington, 2004
9. 注意事項
本文檔包含的信息代表 Microsoft Corporation 截至發(fā)布日期就所討論的問題發(fā)表的最新觀點。 由于 Microsoft 必須對不斷變化的市場狀況作出反應(yīng)，因此這些觀點不應(yīng)被解釋為 Microsoft 的承諾，并且 Microsoft 不保證所示任何信息在發(fā)布日期之后仍準(zhǔn)確。
本白皮書僅供參考。 對本文檔中的信息，MICROSOFT 不做任何明示、默示或法定保證。
遵守所有適用的版權(quán)法是每個用戶的責(zé)任。 在不限制版權(quán)法所規(guī)定的權(quán)利的情況下，未經(jīng) Microsoft Corporation 明確的書面許可，不得出于任何目的、以任何形式或手段（電子的、機(jī)械的、影印、錄制等等）復(fù)制、傳播本文檔的任何部分，也不得將其存儲或引入到檢索系統(tǒng)中。
Microsoft 可能具有涉及本文檔中主題的專利、專利申請、商標(biāo)、版權(quán)或其他知識產(chǎn)權(quán)。 除非 Microsoft 的書面許可協(xié)議明確規(guī)定，否則提供本文檔并不意味著賦予您這些專利、商標(biāo)、版權(quán)或其他知識產(chǎn)權(quán)的任何許可。
© 2005 Microsoft Corporation. 保留所有權(quán)利。 本白皮書部分內(nèi)容為電氣與電子工程師協(xié)會 2004 年版權(quán)所有。 保留所有權(quán)利。
Microsoft、MSDN、Windows 和 Windows Server 是 Microsoft Corporation 在美國和/或其他國家或地區(qū)的注冊商標(biāo)或商標(biāo)。
