高可信度電腦運算安全性開發生命週期

Steve Lipner
Michael Howard
安全性工程與溝通
安全性商務與技術單位
Microsoft Corporation

2005 年 3 月

摘要： 本文探討高可信度電腦運算安全性開發生命週期 (Security Development Lifecycle，簡稱 SDL)；這是 Microsoft 為必須承受惡意攻擊之軟體所採用的開發流程。 流程中包含了在 Microsoft 軟體開發流程各階段加入一系列以安全性為重的活動與交付項目。 這些活動與交付項目包括了：軟體設計時開發威脅模型、實作時使用靜態分析程式碼掃描工具，以及在「加強安全性」階段進行程式碼檢閱與安全性測試。 需要 SDL 的軟體在發行之前，均須通過獨立於開發小組之外的另一團隊的最終安全性檢閱。 與未實施 SDL 的軟體相比，通過 SDL 的軟體被外界發掘安全性弱點的次數明顯降低。 本文除描述 SDL 外，並討論將其應用於 Microsoft 軟體之經驗。 (列印張數共 19 頁)

附註   本文為更新版本，舊版為 2004 年 12 月於美國亞利桑那州土桑市 (Tucson) 所舉辨之「2004 年電腦資訊安全應用程式年會」上發表的《高可信度電腦運算安全性開發生命週期》一文。

目錄

本頁內容

1. 簡介1.1 基線流程1.2 安全性開發生命週期概觀2. 安全性開發生命週期流程2.1 需求階段2.2 設計階段2.3 實作階段2.4 確認階段2.5 發行階段2.6 支援與服務階段3. Microsoft 實作安全性開發生命週期3.1 強制應用 SDL3.2 強制教育3.3 產品團隊測量標準3.4 中央安全性團隊4. Microsoft 實作安全性開發生命週期之成果5. 套用安全性開發生命週期之心得5.1 SDL 各元素之效用5.2 工具、測試及程式碼檢閱5.3 投資5.4 成果6. 結論7. 感謝8. 參考資料9. 聲明

1. 簡介

所有軟體廠商均應正視安全性威脅。 安全性是軟體廠商的最基本要求，不僅是市場力量使然，同時也是保護關鍵基礎結構所需，以及建立、保持大眾對電腦運算的信心所致。 對各軟體廠商而言，其中一大難題便是要製作更安全的軟體，不需一再透過補充程式進行更新，也沒有繁瑣的安全性管理負擔。

而軟體產業若要滿足當今安全性改進需求，其關鍵便是需要實施可重覆的流程，能夠穩穩顯著提升安全性。 因此，軟體廠商必須改用更嚴謹的軟體開發流程，該流程必須更重視軟體安全性。 此流程的目標，便是將設計、程式與說明文件中的安全性弱點數量減至最少，並在開發生命週期內儘早偵測、排除這些弱點。 最需要此流程的軟體，則是用於下列用途的企業及消費性軟體：用於處理來自網際網路的資料、用於控制可能受攻擊的關鍵系統，或是用於處理個人識別資訊的軟體。

建置更安全的軟體可分成三個層面：可重覆的流程、工程教育、以及測量標準與責任歸屬。 本文主要探討 SDL 可重覆流程之層面，但是也會討論工程教育，並提供一些整體測量標準以說明至今應用部分 SDL 所造成的影響。

若以 Microsoft 的經驗為準，則其他組織採用 SDL 應不至於對軟體開發增加不合理的成本。 就 Microsoft 的經驗來看，提供更安全的軟體 (意即補充程式較少、客戶較滿意) 的好處顯然超越成本考量。

SDL 牽涉到整合各種能夠提升軟體安全性的措施，進而修改軟體開發組織的流程。 本文將摘述這些措施，並描述如何將這些措施整合到典型的軟體開發生命週期。 修改的目的不在於徹底顛覆現有流程，而是要加入界定周延的安全性檢查點和安全性交付項目。

本文假定在公司內 (或軟體開發組織中) 有一個中心團隊，負責推動安全性最佳實務與流程改善之發展及演化，對整個組織提供專業知識，並在軟體發行之前進行檢閱 (最終安全性檢閱，Final Security Review；簡稱 FSR)。 在 Microsoft 的經驗，這個組織即是 SDL 實行成功和軟體安全性改善的關鍵所在。 有些組織可能會考慮將此「中央安全性團隊」角色委由承包商擔任，或是另聘顧問。 本文描述如何將改善軟體安全性的各步驟整合到一般大型軟體開發組織常用的開發流程。 這些步驟是 Microsoft 為「高可信度電腦運算推行計畫」(Trustworthy Computing Initiative) 所設計並實作的。 改進流程的目的是要減少客戶使用的軟體的安全性弱點，以及減輕這些弱點的嚴重性。 本文所指「高可信度電腦運算軟體開發生命週期」(或稱 SDL) 便是此修改後的軟體開發流程，目前正由 Microsoft 實施。

依照 Microsoft 的經驗，在軟體設計及開發階段，安全性團隊必須時常溝通，組織也必須信任該團隊使用敏感的技術性和商業資訊。 為此，較佳的解決方案便是在軟體開發組織內建立安全性團隊 (但是也可能需要聘用顧問以協助建置團隊、訓練成員)。

1.1 基線流程

Microsoft 一般採用的軟體開發流程如圖 1 所示。 就概念而言，此流程為產業典型作法。

圖 1。 標準 Microsoft 開發流程 (按圖放大)

雖然圖 1 顯示五個里程碑，而且看起來像「瀑布式」開發流程，實際上卻是一個螺旋式流程。 實作階段常包括回顧需求與設計，以應對市場需求變化和軟體實作時發生的現實狀況。 除此之外，開發流程也強調必須在幾乎各時間點都能提出可執行程式碼；如此各主要里程碑其實是細分為一系列不同的版本，開發團隊可持續測試並實際使用各版本。

1.2 安全性開發生命週期概觀

根據現實中的軟體安全性經驗，可推導出一組建置更安全軟體的高層原則。 Microsoft 把這些原則稱作 SD³+C──即是安全的設計 (Secure by Design)、安全的預設設定 (Secure by Default)、安全的部署 (Secure in Deployment) 和溝通 (Communications)。 以下簡略說明這些原則之定義：

•

安全的設計：軟體之架構、設計、實作均能保護自己與其所處理之資訊，並能抵抗攻擊。

•

安全的預設設定：現實中軟體的安全性並無法達到完美的境界，因此設計時應假設安全性缺陷之存在。 攻擊者攻擊這些殘留缺陷時，要將傷害降至最低的方法便是讓軟體在預設狀態便偏重其安全性。 例如，軟體應以其最低所需權限執行，不常用的服務與功能應預設為停用，或僅有一小部分使用者可取用。

•

安全的部署：軟體應附有工具和指南，協助使用者及/或系統管理員更安全地使用軟體。 另外，更新的部署也應該簡便易用。

•

溝通：軟體開發人員應預先為日後發現的產品弱點做準備，並應以公開、負責任的態度，和使用者及/或系統管理員進行溝通，協助對方採取防護措施 (如採用補充程式或部署因應措施)。

雖然 SD³+C 的每一個要素均加重開發流程的作業負擔，但是其中第一項與第二項──安全的設計以及安全的預設設定──對安全性有相當大的助益。 安全的設計所要求的流程是一開始就避免留下弱點，而安全的預設設定則需要將軟體之預設風險──即其「受攻擊面」減至最小。

為整合 SD³+C 典範至現有開發流程而實施各種安全性措施後，整體流程組織便如圖 2 所示。

圖 2。 依 SDL 改善之 Microsoft 開發流程 (按圖放大)

本文第 2 節將對 SDL 各要素做概念上的描述。 第 3 節則簡述 Microsoft 實作 SDL 之實際內容。 第 4 節將舉例說明，展示 Microsoft Windows Server 2003 和其他軟體開發初期應用 SDL 之成果；與較早期軟體版本相比，這些軟體的安全性弱點數量較少，而安全性弱點的嚴重性也較低。 第 5 節依據 Microsoft 應用 SDL 之經驗，針對此流程各要素提出心得。 最後，第 6 節提出總結。

2. 安全性開發生命週期流程

如前所述，工程教育並不在本文討論範圍。 但是切記教育課程對於 SDL 之成功佔有關鍵地位。 技術學院和大學的資科系與相關領域應屆畢業生通常訓練不足，上班後無法立即開始設計、開發或測試安全的軟體。 即使是已完成安全性相關課程的人，也極可能僅學習過密碼編譯演算法或是存取控制模型，而不瞭解緩衝區溢位或是規範化誤失。 一般而言，業界軟體設計、工程與測試人員也同樣缺乏適當安全性技術。

在這些情況下，欲開發安全軟體的組織便必須承擔起責任，適當地教育其工程人員。 達成此目標的實際方式，則因組織規模與可用資源而有所不同。 擁有大量工程人員的組織或許有能力制訂內部計畫，持續提供安全性訓練課程給內部工程師；小規模的組織則可能需要依賴外部訓練。 在 Microsoft，所有參與軟體開發的人員每年均需通過「資訊安全複習」訓練。

2.1 需求階段

安全系統開發基本原則之一，便是「自下而上」考量安全性。 許多開發專案會以舊版本為基礎產生「新版」，這時新版本的最初規劃與需求階段，便是製作安全軟體的最佳時機。

在需求階段，產品團隊與中央安全性團隊連絡，要求指派一位資訊安全顧問 (在 Microsoft 實施的 SDL 中則稱「資訊安全夥伴」)，在規劃時負責連絡、提供資源、指導等。 資訊安全顧問將協助產品團隊，檢閱其規劃、提供建議，並確認團隊已規劃足夠資源支援其時程。 資訊安全顧問依專案規模、複雜度與風險，對產品團隊提出安全性里程碑與其達成條件。 從專案開始到最終安全性檢閱和產品發行，該資訊安全顧問都是產品團隊與安全性團隊之間的連絡人。 此外，資訊安全顧問也是安全性團隊與產品團隊管理者之間的連絡人，負責告知管理者其專案之安全性要素是否如預期執行，避免往後流程發生安全性相關的意外事件。

需求階段為產品團隊提供一個機會，讓產品團對能夠考量如何將安全性整合至開發流程、辨認主要安全性目標，以及如何將其對規劃與時程之干擾降至最低，同時將安全性提升至最高。 在流程中，團隊也必須考量如何將軟體的安全性功能與保證措施與其他可能搭配使用之軟體相整合 (為滿足使用者將個別產品整合為一整個安全系統之需求，各軟體間的介面接觸是極重要的考量)。於需求階段所製作的規劃文件應反映出產品團隊對於安全性目標、挑戰以及規劃的整體觀點。 雖然規劃內容在專案進行時也可能做修改，但是若能儘早提出這些內容，便可避免需求被忽略，或是最後才出現突發狀況。

每一個產品團隊都應在此階段考量對安全性功能之需求。 雖然部分安全需求將在威脅模擬階段才出現，但是使用者的需求通常會直接決定哪些安全性功能是必須加入的，才能回應客戶要求。 若需要遵循產業標準，或是如「共同準則」(Common Criteria) 等認證流程，也可能因而產生對安全性功能之需求。 產品團隊應體認這些需求，並將其反映於平時規劃流程中。

2.2 設計階段

在設計階段找出軟體的整體需求及結構。 從安全性觀點來看，設計階段的關鍵元素為：

•

定義安全性架構與設計準則：從安全性觀點定義軟體的整體結構，並辨認有哪些元件的正確運作對安全性至關緊要 (即「受信任電腦運算基礎」)。 找出將全面應用於軟體之設計技術，如層級法 (Layering)、強型別 (Strongly Typed) 語言、最低權限之套用，以及受攻擊面最小化等等 (層級法 指的是將軟體分為定義明確的元件，依此結構化的元件可避免產生循環相依性──各元件分屬不同層級，高層級元件可依存於較低層級元件提供的服務，但是低層級元件禁止依存於較高層級之元件)。架構中個別要素的詳細內容請見個別設計規格，不過安全性設計之整體方向則依此安全性架構而定。

•

書面記錄軟體受攻擊面的元素。 若以軟體無法完全安全為前提，則預設所有使用者均可取用的功能應該僅限於絕大多數使用者所需的功能，且應以最低限度權限安裝。 測量受攻擊面元素，產品團隊便有了持續性的標準可測量預設安全性；軟體若變得更易受攻擊，也能進一步測知。 有時產品功能增強或更好使用，卻因而擴大受攻擊面；若是如此，則在設計與實作階段均需測知、質疑攻擊面擴大的情況，以便軟體能以最安全之預設設定出廠。

•

威脅模擬。 產品團隊在個別元件的層級進行威脅模擬。 元件團隊應用結構化方式，辨識出軟體所需管理的資產以及存取各資產所用之介面。 威脅模擬的流程中將辨識出可能傷害各資產的威脅，以及發生機率 (意即估算其風險)。 元件團隊接著辨識出能夠減輕風險的因應措施──可能像加密的安全性功能，或是像軟體的正確運作以保護資產不受傷害。 如此一來，威脅模擬能協助產品團隊辨識對安全性功能的需求，並找出何處需要進行詳實的程式碼檢閱與安全性測試。 威脅模擬的流程應有工具支援，能將威脅模型擷取為機器可讀格式以供儲存及更新。

•

定義附加出廠條件。 基本的安全性出廠條件應在組織層級便已定義，但是除此之外，個別產品團隊或軟體版本也可能有特定的條件，必須先符合所有條件才可發行軟體。 例如，產品團隊開發將送至客戶且將遭受大量攻擊的更新版軟體時，可能要求新版本必須先持續一段期間未發現外部通報弱點，才能準備對外發行 (換言之，開發流程應事先找出並排除弱點，而非等到外部通報弱點後產品團隊才進行「修補」)。

2.3 實作階段

產品團隊在實作階段撰寫程式碼、測試、整合軟體。 此階段中，任何排除或事先預防安全性缺陷的措施具有極佳效果，可大幅降低最終發行給客戶的軟體版本出現安全性弱點的機率。

威脅模擬所得結果在實作階段是極重要的指南。 開發人員將特別注重程式碼正確性，以排除首要威脅；測試人員則專注於測試並確保這些威脅已被阻絕或減輕。

在實作階段適用的 SDL 元素如下：

•

套用程式撰寫與測試標準。 程式撰寫標準可協助開發人員避免可能導致安全性弱點的程式缺陷。 例如使用較安全、較一致的字串處理與緩衝區操作建構，便有助於避免留下緩衝區溢位弱點。 測試標準與最佳實務則有助於確保測試流程能專注於偵測潛在安全性弱點，而非僅僅留意測試軟體功能是否正常運作。

•

使用安全性測試工具，包括模糊化處理工具。 「模糊化處理」提供結構化但無效的輸入資料給軟體應用程式發展介面 (API) 與網路介面，將偵錯率提升至最高，找出可能導致安全性弱點的錯誤。

•

使用靜態分析程式碼掃描工具。 工具程式可以偵測某些導致弱點的程式缺陷，包括緩衝區溢位、整數溢位與未初始化的變數。 Microsoft 已投資大量資源開發此類工具 (PREfix 和 PREfast 即是使用最久的兩種工具)，並持續依照新發現的程式碼缺陷及軟體弱點進行改善。

•

進行程式碼檢閱。 程式碼檢閱可輔助自動化工具與測試，讓有經驗的開發人員檢查原始程式碼，偵測並排除潛在安全性弱點。 在開發過程中，此為排除軟體安全性弱點相當關鍵的步驟。

2.4 確認階段

在確認階段，軟體功能方面已告完工，即將開始進行使用者 Beta 測試。 在此階段，軟體進行 Beta 測試的同時，產品團隊也開始進行「加強安全性」活動，其中包括了目標集中的安全性測試以及超越實作階段程式碼檢閱範圍的安全性程式碼檢閱。

2002 年初，Microsoft 在 Windows Server 2003 及其他數個軟體版本的確認階段開始採用此加強安全性措施。 加強安全性的理由有二：

•

所述各版本之軟體生命週期已達確認階段，而此階段適合進行所需的集中程式碼檢閱與測試。

•

在確認階段加強安全性，可確保程式碼檢閱及測試是以軟體完成版本為主，並有機會檢閱實作階段開發、更新的程式碼以及未修改的「舊程式碼」。

第一個理由只是時間上的巧合：最初決定進行加強安全性時，正是在確認階段。 但是 Microsoft 也達成結論，在確認階段進行加強安全性活動是好辦法，不但能確保最終軟體符合需求，也能更深入檢閱從較舊版本延用的舊程式碼。

必須特別提出的是，首要程式碼 (即軟體「受攻擊面」所屬程式碼) 的檢閱及測試，對 SDL 數個部分關係重大。 例如在實作階段便應要求進行檢閱與測試，以提早修正任何問題，並辨識、修正問題來源。 在產品即將完成前的確認階段中，也極為重要。

2.5 發行階段

在發行階段，軟體應先通過最終安全性檢閱 (FSR)。 FSR 的目標是要解決一個疑慮： 「從安全性觀點來看，此軟體是否準備好交付給客戶？」依軟體規模而定，FSR 進行時間為軟體完成前二至六個月。 軟體進行 FSR 之前必須是穩定狀態，一直到發行之前，只有非關安全性的小量變更。

FSR 是由組織的中央安全性團隊針對該軟體所進行的獨立檢閱過程。 在 FSR 之前，安全性團隊的資訊安全顧問將事先通知產品團隊關於該軟體所需的 FSR 範圍，並提供所需資源需求之清單。 產品團隊則提供安全性團隊欲完成 FSR 所需之資源及資訊。 FSR 的第一步驟便是由產品團隊填寫問卷，接著由負責進行 FSR 的安全性團隊成員進行訪談。 任何形式的 FSR 均需複檢原先被列為安全性錯誤的錯誤，但是經分析判定不對安全性造成影響，以確保分析的正確性。 FSR 也包括檢閱軟體對於影響類似軟體的新通報弱點的承受能力。 若是軟體重大版本，還需進行穿透測試，甚至可能需聘用外部安全性檢閱承包商，以彌補安全性團隊之不足。

FSR 的結果不是單純的通過或失敗，它的目標也並非是找出所有餘留的軟體弱點；因為這是不可行的。 完成 FSR 之後，產品團隊與組織高階管理人便能瞭解軟體整體的安全性狀態，以及軟體發行後，能夠承受攻擊的可能性。 若 FSR 找出餘留弱點的模式，那麼正確的處理方式並非僅止於修正弱點，而是回到先前階段，針對弱點根源加以改正 (如改善訓練、改善工具等等)。

2.6 支援與服務階段

即使開發過程套用了 SDL，最先進的開發實務也無法支援完全無弱點的出廠軟體──甚至可以合理認定這是永遠不可能的。 就算開發流程能夠排除所有出廠軟體的弱點，新的攻擊方式還是會被發現，而原先「安全」的軟體便會出現弱點。 因此，產品團隊應準備應付出廠軟體新發現的弱點。

應對過程包括評估弱點報告，並適當發行安全性建議公告及更新。 過程中也包含事後剖析通報之弱點，並依需要採取行動。 應對弱點之行動可以是針對獨立錯誤發出更新，也可以是更新程式碼掃描工具以針對主要子系統進行程式碼檢閱。 在應對階段的目標，是從錯誤中學習，並利用弱點通報裡的資訊協助偵測、排除其他弱點，避免弱點出現後對客戶造成傷害。 此應對過程也能協助產品團隊及安全性團隊調整流程，防止類似錯誤再度發生。

3. Microsoft 實作安全性開發生命週期

Microsoft 所實作的 SDL 自 2002 年初「加強安全性」活動之後已有所變化。 為了推動流程，並對開發已久的產品有所影響，「加強安全性」活動集中在短時間內進行，但這應該分散於多個 SDL 階段。 這個活動對於產品團隊的計畫、資源、時程等造成顯著衝擊，若無 Microsoft 高層支持，必定難以進行。 當時加強安全性的重點放在威脅模擬、程式碼檢閱以及安全性 (包括穿透性) 測試。 「最終安全性檢閱」(FSR) 是於 2002 年底至 2003 年初，發行 Windows Server 2003 之前所採用的，其對 Windows Server 2003 出廠預設設定有顯著的影響。

在這些加強安全性活動與 FSR 之後，Microsoft 發起專案建立正式 SDL 流程。 此專案有四項成果值得在此特別提出：

•

強制應用 SDL 的執行政策

•

強制教育工程人員

•

產品團隊測量標準

•

中央安全性團隊角色

下列各節討論此處所列各項。

3.1 強制應用 SDL

因 SDL 成果證實有益 (請參閱第 5 節)，Microsoft 決定正式要求許多不同種類軟體均需套用 SDL。 在本文撰寫之時，任何符合下列條件的軟體均需套用 SDL：

•

將用於處理個人或敏感資訊

•

將用於企業或其他組織 (包括學術、政府或非營利組織等)

•

將連接網際網路或以其他方式用於網路環境

此強制要求 不 適用的軟體包括不符合上述條件之獨立應用程式 (例如幼兒遊戲，如 "The Magic School Bus" (魔法校車) 系列)。 值得一提的是，SDL 也禁止這類軟體干擾軟體作業平台安全性 (即作業系統或其他軟體)。

3.2 強制教育

在 2002 年初期的加強安全性活動之關鍵要素之一，便是全產品群組團隊之開發、測試、管理、文件人員的訓練課程。 Microsoft 已正式需求，若軟體套用 SDL，則組織內的工程師必須每年接受安全教育訓練。 安全性並非靜止不動的領域，威脅、攻擊、防禦方式均不斷在進化，也因此必須持續每年接受訓練。 因此，即使在安全性領域具有一流能力及資格的工程師，也需因應威脅環境之改變而接受額外訓練。 例如，過去四年間整數溢位弱點變得非常重要，最近也在一些密碼編譯演算法發現前所未見的弱點。

Microsoft 開發了共通的安全性簡介與最新消息，同時以「即時課程」與數位媒體格式呈現給工程師。 Microsoft 以此作為基礎，再依軟體技術以及工程師角色之別進行較專業的訓練課程。 Microsoft 目前正在建立一個安全教育課程規劃，將依技術、角色、學生經驗之別提供更專業的課程。

許多 Microsoft 的合作夥伴與客戶紛紛洽詢 Microsoft 安全教育及流程的取得方式。 Microsoft Press 有出版書籍，其內容便是以 Microsoft 內部對於安全性設計、程式撰寫、威脅模擬等措施為基礎；Microsoft Learning 也提供以 Microsoft 內部措施為基礎的課程。

3.3 產品團隊測量標準

身為一個企業，Microsoft 也篤信「無法測量便無法管理」的格言。雖然能夠可靠測量軟體安全性的測量標準難以制訂，但顯然有的標準能夠估測軟體安全性。 這些測量標準包括了工程人員訓練範圍 (在開發生命週期之初) 以及已發行給客戶的軟體弱點發現率。

Microsoft 制訂了一組安全性測量標準，供產品團隊審查其執行 SDL 之成效。 這些測量標準涵蓋範圍包括了威脅模擬、程式碼檢閱、安全性測試以及投入 FSR 時軟體的安全性。 由於這些測量標準是依時間而有變化，除了讓團隊追蹤各自表現 (改善、持平或退步) 以外，也用於不同團隊間之比較。 資深產品團隊管理階層以及 Microsoft 高層則是定期接到綜合測量標準報告。

3.4 中央安全性團隊

在 2002 年實施加強安全性之前，Microsoft 便已成立了「安全 Windows 計畫」(SWI) 團隊，目的是改善 Windows 軟體安全性、減少弱點、並對 Windows 開發團隊以外的產品團隊提供安全性支援。 此 SWI 團隊在 Windows Server 2003 加強安全性時扮演中心角色，並從 2002 年開始為所有的加強安全性活動提供訓練課程及詻詢支援。 另外，SWI 團隊也負責執行 Windows Server 2003 的 FSR，為 FSR 流程開先鋒。

在 SDL 正式推行之後，SWI 團隊也成為了 Microsoft 的中央安全性團隊。 SWI 團隊責任包括：

•

開發、維護、增強 SDL，包括流程強制部分之定義。

•

開發、增強、提供工程教育。

•

派任「資訊安全顧問」指導產品團隊執行流程，為產品團隊進行檢閱，並確保產品團隊的疑問能儘快獲得正確、權威性的答案。

•

成為各種安全性主題的專家，確保資訊安全顧問收到或經手的疑問均迅速獲得正確解答。

•

軟體發行前執行最終安全性檢閱。

•

對已發行給客戶之軟體的弱點回報進行技術性調查，確保已瞭解其根源，並已觸動適當層級之回應。

SWI 團隊之可用性和有效性已在 Microsoft 證明為執行 SDL 之關鍵因素。 Microsoft 的目標是發展一個可調整的流程以開發更安全的軟體，而此目標則代表需要將安全性推廣於所有產品團隊。 但是一個中央式且具有優異資格的安全性團隊，對於提升整個公司的產品團隊水準，以及支援各團隊開發更安全的軟體，扮演了關鍵性的角色。 如此也能確保 FSR 是由產品團隊以外的人員執行。

4. Microsoft 實作安全性開發生命週期之成果

目前要提出結論宣稱 SDL 改善了 Microsoft 軟體安全性，為時尚早，但至今的結果令人鼓舞。

Windows Server 2003 是 Microsoft 首次發行實作了 SDL 許多部分的作業系統版本。 圖 3 是 Microsoft 最近兩個伺服器作業系統發行後一年間的安全性公告數量：Windows 2000 以及 Windows Server 2003 (發行 Windows 2000 時，Microsoft 並無正式的安全性公告嚴重性分級系統。 目前已將 Windows 2000 適用之安全性公告依現行嚴重性分級系統加以評估)。如前文所述，Windows Server 2003 開發中套用大部分 (非全部) 的 SDL 流程，Windows 2000 則未套用這些流程。

圖 3。 Windows 套用 SDL 前後之重大與重要安全性公告

嚴重性等級定義請參閱 http://www.microsoft.com/technet/security/bulletin/rating.mspx。

其他 Microsoft 軟體也已套用部分 SDL 元素。 SQL Server 以及 Exchange Server 產品團隊在發行 Service Pack 之前已各自加強安全性 (包括威脅模擬、程式碼檢閱與安全性測試)。Service Pack 即是將安全性弱點與其他問題加以修正整合後所發行的軟體版本。 SQL Server 加強安全性結果已加入 SQL Server 2000 Service Pack 3，Exchange Server 加強安全性結果則是加入 Exchange 2000 Server Service Pack 3。 圖 4 與圖 5 是發行 Service Pack 前後相同期間各自的安全性公告數量 (SQL Server 2000 為 24 個月，Exchange 2000 Server 則是 18 個月)。

圖 4。 SQL Server 2000 套用 SDL 前後之安全性公告

圖 5。 Exchange Server 2000 套用 SDL 前後之安全性公告

另一個令人鼓舞的例子便是 Windows Server 2003 的 Internet Information Server (IIS 6)；發行後兩年間，Microsoft 僅發出一個影響該 Web 伺服器之安全性公告，而此公告還是預設未安裝的元件 (WebDAV)。

雖然安全性弱點採樣不多，時間也不夠，這些結果還是足以證明 SDL 是有效的。 Microsoft 將繼續監視 Windows Server 2003、Exchange Server 以及 SQL Server 之 Service pack 弱點率，追蹤這些初期趨勢是否會持續。 同時也將分析其他的 Microsoft 軟體，追蹤已完全執行 SDL 之新版軟體的安全性弱點數量和嚴重性是否會持續降低。

5. 套用安全性開發生命週期之心得

前一節提出的資料概略說明 SDL 所要達成之目標為何。 本節則嘗試回答關於此流程如何運作之問題。 在前一節所使用的是實際數據──Microsoft 嚴密追蹤弱點通報與安全性公告──本節則是使用 SWI 團隊成員的心得與意見等資料。

5.1 SDL 各元素之效用

SDL 是由大量的子流程元件所組成，各流程分散於軟體開發生命週期不同的階段。 此處要求 SWI 團隊依各子流程效用排定其優先順序──哪些最有效、哪些則是試過後效果較不顯著。

SWI 團隊的共識為，威脅模擬為 SDL 首要元件。 當然，威脅模擬並非獨立執行：威脅模擬會推動設計、程式碼檢閱及測試，若是僅執行威脅模擬而不針對其結果採取行動 (例如未測試因應措施之效用)，則流程便不會起作用。 如錯誤數量等統計數字常會低估威脅模擬的重要性，因為威脅模擬的貢獻便是確保一開始就避免出現可能導致安全性弱點之錯誤。 但是威脅模擬對於開發安全軟體所扮演的角色佔有舉足輕重之地位，能夠突顯流程重點，因此列為最優先項目。

SDL 在 Microsoft 歷時尚短，因而流程中未有元件遭移除。 不過其中一個發現會在資深安全性研究人員意料之中：穿透性測試並非提升安全性的有效方式。 穿透性測試是最終安全性檢閱 (FSR) 的元素之一，但是產品團隊於整個生命週期所專注的是威脅模擬、程式碼檢閱、自動化工具的使用和模糊化測試，而非穿透性測試。 後幾項措施比傳統的特殊穿透性測試更能預防、排除安全性錯誤。 FSR 中的穿透性測試有助於判斷軟體是否已達發行標準，它不是尋找、修正安全性錯誤的方法。 若是 FSR 的穿透性測試能夠有效找出安全性錯誤，即代表之前各階段效果不佳；此時正確的應對方式應是回到各階段，完成應完成的作業，而不是只修正穿透性測試找出的錯誤後就發行軟體。

5.2 工具、測試及程式碼檢閱

靜態分析工具、模糊化測試、程式碼檢閱等是相輔相成的。 Microsoft 於靜態分析程式碼掃描工具投資甚鉅，這些工具的使用也與 SDL 密不可分。 這些工具能夠有效找出許多可能造成安全性弱點的程式錯誤──尤其是緩衝區溢位錯誤。 但是即使是最先進的工具也無法找出所有錯誤。 SDL 還是需要人工檢閱程式碼；一方面可找出工具所忽略的錯誤，一方面也可找出工具尚需改善之處。 Michael Howard 撰寫的 Microsoft Developer Network (MSDN) 文章 (參考資料中所列) 大致說明了 Microsoft 工程師進行程式碼安全性檢閱的一般方式。

模糊化測試最近才成為 SDL 大力推行的重點，但是至今已成果斐然。 與靜態程式碼掃描工具不同的是，模糊測試工具必須針對欲測試的各檔案格式及/或網路通訊協定而建置 (或至少需要設定)；因此，模糊化測試也常能找出靜態分析工具所忽略的錯誤。 威脅模型能協助產品團隊判斷需優先測試的介面與格式。 模糊化測試結果並非是決定性的結果 (工具執行次數有限，也不保證能找出所有錯誤)，但根據過去經驗，只要做到能力所及的模糊化測試，便可能找出較「特殊」的錯誤，若是置之不理則很可能被利用成為安全性弱點。

5.3 投資

強制性的安全性訓練課程對於 Microsoft 這麼大的公司而言，是可觀的投資。 訓練課程是結合了現場教學 (由講師主持) 與線上教材。 線上教材能夠提供訓練課程給遠離 Microsoft 總部之小型工程團隊，非常有用。 現場教學則是針對正準備進行加強安全性或是其他關鍵活動之團隊全員進行訓練，效果很好──依 Microsoft 經驗，這些情況下除了課堂授課以外，實際進行加強安全性也能達到團隊訓練的效果。 安全性訓練課程 (通常為半天課程) 中，群組成員因為專注於安全性而能事半功倍。

Microsoft 近幾年間愈來愈注重安全性，因此中央安全性團隊 (SWI 團隊) 也隨之發展。 依其設計，團隊規模和 Microsoft 整個公司工程部門比起來是屬於小型團隊，並著重「可調整」的方法，以確保各產品團隊掌握開發更安全的軟體之責任與資源。 一些反映出此理念的策略包括了對訓練課程及工具之注重、提供資訊安全顧問協助產品團隊解決各自的問題 (而非替各團隊解決問題)、用檢閱措施 (包括 FSR) 提供產品團隊關於軟體可發行與否的意見等。

5.4 成果

SDL 的最終考驗即是其對於排除、減輕 Microsoft 軟體弱點是否有效。 根據經驗──於第 4 節中概述──SDL 已通過此考驗。 Microsoft 也評估外部通報的弱點對於開發中軟體版本之影響。 根據最近的經驗，有愈來愈多為新版本規劃或實作的安全性措施能夠阻擋對舊版本有效的攻擊。 不久前發行的 Windows XP Service Pack 2 即是以此方式檢閱過，發現其中已規劃但尚未實作或公開討論的安全性變更，已經能夠排除外部研究員所通報的舊版 Windows 的弱點。

6. 結論

根據 Microsoft 的經驗，SDL 可有效減少安全性弱點發生次數。 初步實施 SDL (於 Windows Server 2003、SQL Server 2000 Service Pack 3 及 Exchange 2000 Server Service Pack 3) 後，便已明顯改善軟體安全性；而之後的軟體版本，實施改善後的 SDL，也似乎更進一步改善了軟體安全性。

逐步實施 SDL 各元素，可以逐漸累積改善成果，這是流程發揮效用的跡象。 此流程並不完美，也尚在演變階段──在可見的未來內也不大可能達到完美的程度或是停止演變。

安全性開發生命週期之開發與實作，代表的是 Microsoft 投入的大量投資，也代表了軟體設計、開發、測試的方式有了大幅的改變。 社會對於軟體日漸倚重，Microsoft 以及整個產業因而必須持續改善軟體安全性；為此，Microsoft 將論述 SDL 的本文以及討論特定技術的書籍 (請參閱參考資料) 出版，和同業分享 Microsoft 的經驗。

7. 感謝

本文最初是於 2002 年末，由目前的作者共同撰寫。 隨 SDL 演變，草稿也跟著更新，現行版本則是於 2004 年夏季至秋季間進行編修。 本文作者希望向 Matt Thomlinson、Matt Lyons、Jamil Villani 和 Eric Bidstrup 致謝 (以及整個 Microsoft 安全 Windows 計畫團隊)，感謝他們對於 SDL 定義及其修訂之貢獻。 除前所列之外，Microsoft 的 Scott Charney 和 Phil Reitinger 以及卡內基美隆大學的 Jeannette Wing 對本文草稿提供了非常有幫助的意見。 作者也要感謝 Martin Abadi、Virgil Gligor、Dick kemmerer、Chris Mitchell、Fred Schneider、Neeraj Suri 和 James Whittaker 對本文提出意見與建議。

8. 參考資料

Mundie, Craig, Trustworthy Computing White Paper (高可信度電腦運算白皮書)

Howard, Michael, Attack Surface: Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users (受攻擊面：減少未受信任使用者可取用的程式碼，降低安全性風險), MSDN 雜誌, 2004 年 11 月

Howard, Michael, Expert Tips for Finding Security Defects in Your Code (專家秘訣：找出程式裡的安全性缺陷), MSDN 雜誌, 2003 年 11 月

Howard, Michael 與 David LeBlanc, Writing Secure Code (寫出安全的程式碼), 第二版, Microsoft Press, Redmond, Washington, 2003

Swiderski, Frank 與 Window Snyder, Threat Modeling (威脅模擬),Microsoft Press, Redmond Washington, 2004

9. 聲明

本文內所含資訊代表 Microsoft Corporation 在出版當日對所討論的議題的最新看法。 Microsoft 必須對變化的市場環境作出回應，因此本文不應解釋成 Microsoft 針對此方面所做的承諾，而 Microsoft 也不能保證任何在本文出版日期之後所發表的資訊正確性。

此白皮書僅供參考之用。 MICROSOFT 對本文件中的資訊不提供任何明示、暗示或法定之擔保。

使用者有責任遵守所有適用之著作權法。 在不限制著作權法所賦權利的前提之下，若未取得 Microsoft 明確的書面許可，本文件任何部分均不得予以重製、儲存於或導入檢索系統、以任何型態、方法，或為任何目的而傳送 (電子、機械、影印、錄音錄影、或其他方法)。

Microsoft 對本文內所討論的事物可能擁有專利權、專利應用權、商標、著作權或其他的智慧財產權。 除 Microsoft 書面授權合約所明示規定者外，提供本文件並非授予 貴使用者上述專利權、商標、著作權或其他智慧財產權。

© 2005 Microsoft Corporation. 著作權所有，並保留一切權利。 本白皮書部分為 © 2004 電子電機工程師協會 (Institute of Electrical and Electronics Engineer, Incorporated)。 著作權所有，並保留一切權利。

Microsoft、MSDN、Windows 及 Windows Server 皆為 Microsoft Corporation 在美國及/或其他國家中的註冊商標或商標