安全開發生命週期（SDL）是一個幫助開發人員構建更安全的軟體和解決安全合規要求的同時降低開發成本的軟體開發過程。 安全應用從安全設計開始，軟體的安全問題很大一部分是由於不安全的設計而引入的，微軟用多年的經驗總結出了安全開發生命週期（SDL），並提出了攻擊面最小化、STRIDE威脅建模等多種方法輔助安全人員對軟體進行安全設計。安全設計對於軟體安全的重要性尤為可見。

文章目錄

一、安全開發生命週期（SDL）是什麼？

SDL介紹

安全開發生命週期（SDL）即Security Development Lifecycle，是一個幫助開發人員構建更安全的軟體和解決安全合規要求的同時降低開發成本的軟體開發過程。 自2004年起，微軟將SDL作為全公司的計劃和強制政策，SDL的核心理念就是將安全考慮整合在軟體開發的每一個階段:需求分析、設計、編碼、測試和維護。從需求、設計到釋出產品的每一個階段每都增加了相應的安全活動，以減少軟體中漏洞的數量並將安全缺陷降低到最小程度。安全開發生命週期 (SDL)是側重於軟體開發的安全保證過程，旨在開發出安全的軟體應用。

SDL安全活動

簡單來說，SDL是微軟提出的從安全形度指導軟體開發過程的管理模式，在傳統軟體開發生命週期 (SDLC) 的各個階段增加了一些必要的安全活動，軟體開發的不同階段所執行的安全活動也不同，每個活動就算單獨執行也都能對軟體安全起到一定作用。當然缺少特定的安全活動也會對軟體的安全性帶來影響。

圖1：微軟SDL安全活動簡圖

我曾今有幸參加過微軟安全專家Michael Howard及Taha Mir關於SDL及威脅建模的培訓，作為《軟體安全開發生命週期》一書的作者，Michael Howard不只一次強調，安全培訓是SDL最核心的概念，軟體是由設計人員設計，程式碼是有開發人員編寫。同樣，大部分軟體本身的安全漏洞也是由設計及編碼人員引入，所以對軟體開發過程中的技術人員進行安全培訓這點至關重要。

可以看到在整個SDL週期中，除了安全培訓這項活動，還在軟體釋出後增加了安全應急響應的相關活動，而目前國內大多數公司目前已經基本上具備了安全應急響應的活動和職能部門，同時包括安全編碼規範、程式碼審計、滲透測試等安全活動也都已經基本具備甚至個別企業已經比較成熟。但在軟體設計階段的安全活動則相對較少，據我瞭解僅個別大型跨國企業才擁有安全設計等相關的安全活動。而根據微軟多年的實踐和經驗，軟體的安全問題很大一部分是由於不安全的設計而引入的。在設計階段造成的安全缺陷在後期修復的成本和時間都相對較高。STRIDE威脅建模的創始人之一Taha Mir曾說過“safer applications begin with secure design”，即安全應用從安全設計開始，相應的微軟SDL也提出了若干核心的安全設計原則，並提出瞭如攻擊面最小化、STRIDE威脅建模等多種方法輔助安全人員對軟體進行安全設計，本文就針對當前國內企業在軟體設計階段安全活動發展相對欠缺的安全設計進行探討。

二、安全設計核心原則

SDL安全設計核心原則:

• Attack Surface Reduction：攻擊面最小化
• Basic Privacy: 基本隱私
• Least Privilege: 許可權最小化
• Secure Defaults: 預設安全
• Defense in Depth：縱深防禦
• Threat Modeling：威脅建模

2.1 攻擊面最小化

攻擊面是指程式任何能被使用者或者其它程式所訪問到的部分，這些暴露給使用者的地方往往也是最可能被惡意攻擊者攻擊的地方。

攻擊面最小化即是指儘量減少暴露惡意使用者可能發現並試圖利用的攻擊面數量。軟體產品的受攻擊面是一個混合體，不僅包括程式碼、介面、服務，也包括對所有使用者提供服務的協議。尤其是那些未被驗證或者遠端的使用者都可以訪問到的協議，安全人員在攻擊面最小化時首先要對攻擊面進行分析，攻擊面分析就是列舉所有訪問入庫、介面、協議一劑可執行程式碼的過程，從高層次來說，攻擊面分析著重於:

• 降低預設執行的程式碼量
• 限制可訪問到程式碼的人員範圍
• 限定可訪問到程式碼的人員身份
• 降低程式碼執行所需許可權

常見的攻擊面分析技巧如下表:

表1 攻擊面分析常用技巧

攻擊面最小化在微軟的應用實踐示例:

表2 攻擊面最小化微軟實踐示例

2.2 基本隱私

使用者使用軟體時無可避免個人資訊被收集、使用甚至分發，企業則有責任和義務建立保護個人資訊的保護措施，抵禦敵對攻擊行為，確保使用者基本隱私的安全性。隱私安全是建立可信任應用程式的關鍵因素。

在軟體設計時考慮使用者基本隱私的必要性及意義有:

• 履行法律規定和義務
• 增加客戶的信賴
• 防止堵塞部署

對於特殊的軟體或者全球性的產品，設計人員需要明確軟體的行為及針對人群。尤其要考慮當地國家的法律法規，如美國兒童網路隱私保護法COPPA(Children’s Online Privacy Protection Act)等，企業在開發產品、服務時有必要制定明確的隱私準則，對獲取、記錄使用者隱私的相關產品需有明確的要求和指導建議。

Tips:

• 只收集程式必須用到的隱私資料，並明確告知使用者並徵得使用者同意;
• 微軟對於使用者隱私資料如密碼、口令等均需要加密儲存，最低要求是sha256+salt，對於更高要求的則使用PBKDF2演算法加密儲存;

2.3 許可權最小化

如果一個應用程式或網站被攻擊、破壞，許可權最小化機制能夠有效的將潛在損害最小化。常見的許可權最小化實踐如:

• 普通管理員/系統管理員等角色管理
• 檔案只讀許可權/檔案訪問許可權等訪問控制
• 程序/服務以所需最小使用者許可權執行

在進行軟體設計時，安全設計人員可以評估應用程式的行為及功能所需的最低限度許可權及訪問級別，從而合理分配相應的許可權。如果程式特定情況必須要較高級別的許可權，也可以考慮特權賦予及釋放的機制。即便程式遭到攻擊，也可以將損失降到最低。

Tips:

• Windows系統中網路程序、本地服務、使用者程序的許可權都較低且互相獨立，分別為NETWORK SERVICE、LOCAL SERVICE、user許可權，只有核心的重要程序實用SYSTEM許可權;
• 最新版本的Office程式開啟不可信來源的文件時，預設時不可編輯的，同時也是預設不可執行程式碼的，即使存在緩衝區溢位漏洞，也不會執行shellcode等惡意程式碼;

2.4 預設安全

預設安全配置在客戶熟悉安全配置選項之前不僅有利於更好的幫助客戶掌握安全配置經驗，同時也可以確保應用程式初始狀態下處於較安全狀態。而客戶可根據實際使用情況而決定應用程式安全與隱私的等級水平是否降低。

Tips:

• 在Win 7之後的Windows作業系統中，DEP(資料執行保護)預設是開啟的。使用者可設定選項改變DEP的狀態;
• Win 10預設啟用安全防護軟體Windows Defender，使用者可選擇關閉;

2.5 縱深防禦

與預設安全一樣，縱深防禦也是設計安全方案時的重要指導思想。縱深防禦包含兩層含義：首先，要在各個不同層面、不同方面實施安全方案，避免出現疏漏，不同安全方案之間需要相互配合，構成一個整體；其次，要在正確的地方做正確的事情，即：在解決根本問題的地方實施針對性的安全方案。

縱深防禦並不是同一個安全方案要做兩遍或多遍，而是要從不同的層面、不同的角度對系統做出整體的解決方案。

Tips:

• 針對XSS的防護，除了要對使用者輸入的特殊符號進行過濾，還要區分是否是富文字進而進行相應編碼操作，在輸入時過濾的同時在輸出時也進行過濾操作。
• 即使做了十足的過濾、編碼等安全防護，為了更一步確保緩解XSS攻擊，Web站點也可以對Cookie啟用HTTP-Only屬性，確保即使發生XSS攻擊，也可以阻止通過指令碼訪問Cookie的操作。

 2.6 威脅建模

威脅建模是一種分析應用程式威脅的過程和方法。這裡的威脅是指惡意使用者可能會試圖利用以破壞系統，和我們常說的漏洞並不相同。漏洞是一個特定的可以被利用的威脅，如緩衝區溢位、sql注入等。

作為SDL設計階段的一部分安全活動，威脅建模允許安全設計人員盡在的識別潛在的安全問題並實施相應緩解措施。在設計階段把潛在的威脅發現有助於威脅的全面和更有效的解決，同時也有助於降低開發和後期維護的成本。威脅建模的一般流程如下:

• 與系統架構師及設計人員溝通，瞭解設計詳情
• 使用成熟的威脅建模方法分析當前設計潛在的安全問題
• 提出安全建議及對潛在威脅的緩解措施
• 對安全設計進行驗證並對整個設計方案進行回顧並再次確認

微軟使用的威脅建模方法是STRIDE威脅建模方法。為了便於安全人員快速便捷的進行威脅建模，微軟開發基於STRIDE威脅建模方法的SDL Threat Modeling Tool[2]威脅建模工具，該工具可以幫助安全人員畫資料流圖、分析威脅、生成並匯出威脅建模報告。

三、STRIDE威脅建模方法

3.1 STRIDE介紹

STRIDE威脅建模是由微軟提出的一種威脅建模方法，該方法將威脅型別分為Spoofing（仿冒）、Tampering（篡改）、Repudiation（抵賴）、Information Disclosure（資訊洩漏）、Denial of Service（拒絕服務）和 Elevation of Privilege（許可權提升）。這六種威脅的首字母縮寫即是STRIDE，STRIDE威脅模型幾乎可以涵蓋目前絕大部分安全問題。此外，STRIDE威脅建模方法有著詳細的流程和方法。

3.2 威脅建模流程

STRIDE威脅建模的一般流程如下:

• 繪製資料流圖
• 識別威脅
• 提出緩解措施
• 安全驗證

圖2: STRIDE威脅建模流程

3.2.1 資料流圖

資料流圖(Data Flow Diagrams)包含外部實體(External Entity)、處理過程(Process)、資料流(Data Flow)、資料儲存(Data Store)，安全人員與系統架構師及設計人員溝通，瞭解設計詳情並畫出資料流圖後還需要標註信任邊界（Trust Boundary），針對簡單的Web應用的資料流圖如下:

圖3: 資料流圖示例及元素型別

3.2.2識別威脅

STRIDE威脅建模方法已經明確了每個資料流圖元素具有不同的威脅，其中外部實體只有仿冒（S）、抵賴（R）威脅，資料流只有篡改（T）、資訊洩露（I）、拒絕服務（D）威脅，處理過程有所有六種（STRIDE）威脅，儲存過程有篡改（T）、資訊洩露（I）、拒絕服務（D）威脅，但如果是日誌型別儲存則還有抵賴（R）威脅。具體可以對照如下表格進行威脅識別:

表3 資料流圖元素對應的不同威脅

3.2.3 緩解措施

根據不同的資料流圖元素及威脅，相應的緩解措施也不相同。如本文示例資料流圖中外部實體使用者的仿冒威脅，其緩解措施簡單來說就是對使用者身份進行認證。對於一個Web應用來說，緩解仿冒威脅不僅需要較強的認證機制，還需要防止惡意攻擊者用暴力破解、口令猜測等方法繞過認證從而造成仿冒使用者的威脅。如果筆者來提出該使用者仿冒威脅的緩解措施的話，詳細措施如下:

• 對使用者訪問進行帳號密碼、證書等身份認證;
• 使用者帳號密碼認證過程中，如果出現三次密碼錯誤，則增加驗證碼機制。輸入驗證碼且正確再進行身份認證;
• 當用戶認證5次後仍然驗證失敗，則在30分鐘內禁止該帳號登入;
• 使用者密碼必須包含數字、字母及特殊字元，且長度在8位以上，如果業務安全需要則增加密碼過期機制，每隔6個月提醒使用者修改密碼;

在提出緩解措施時，有的時候不僅要考慮安全問題，同時也要考慮軟體的易用性，所以不同的威脅，不同的應用場景。其緩解措施也要隨之而改變以提高應用安全的同時也能給使用者帶來較好的互動體驗。

微軟對於常用的威脅給出了其常用的標準緩解措施，並在具體實施時已將常用的緩解方案及措施整合為獨立的解決方案或者程式碼模組。可以方便同類應用直接使用。

3.2.4 安全驗證

在威脅建模完成後，需要對整個過程進行回顧，不僅要確認緩解措施是否能夠真正緩解潛在威脅，同時驗證資料流圖是否符合設計，程式碼實現是否符合預期設計，所有的威脅是否都有相應的緩解措施。最後將威脅建模報告留存檔案，作為後續迭代開發、增量開發時威脅建模的參考依據。

四、總結

SDL的核心理念是將安全考慮整合在軟體開發的每一個階段:需求分析、設計、編碼、測試和維護。從需求、設計到釋出產品的每一個階段每都增加了相應的安全活動，以減少軟體中漏洞的數量並將安全缺陷降低到最小程度。本文重點介紹了設計階段的安全活動指導思想及STRIDE威脅建模，但SDL的其它階段的不同安全活動也同樣對軟體安全有著重要影響。同時本文介紹的安全設計原則僅為指導思想，安全設計人員還需要掌握一定的安全攻防知識，具備一定的安全攻防經驗才能更好的設計出安全的方案及軟體應用。另外根據筆者經驗，在實際的安全設計工作中，對於不同軟體及應用場景其面臨的安全問題也不同。隨著網際網路時代發展，目前已經不在是單純的軟體時代了，類似通訊裝置、移動端應用、智慧硬體、雲端、大資料等新形態的應用都面臨的自身特有的安全問題。安全設計人員要考慮的也要更多，但安全設計的核心原則還是相差無幾。由於篇幅及筆者經驗有限，本文所述如有不妥之處可以與筆者聯絡交流。

五、參考文獻

[1] https://www.microsoft.com/en-us/SDL/process/design.aspx

[2] http://www.microsoft.com/en-us/sdl/adopt/threatmodeling.aspx

[3] Introduction_to_Threat_Modeling

[4] Simplified Implementation of the SDL

[1] https://www.microsoft.com/en-us/SDL/process/design.aspx

[2] https://www.microsoft.com/en-us/sdl/adopt/threatmodeling.aspx