一、《Core.Software.Security.Security.at.the.Source.CN.軟件安全.從源頭開始》

安全開發生命周期

      最著名的SDL模型是可信計算安全開發生命周期，受歡迎的SDL模型有微軟的SDL、Cigital的軟件安全觸點模型、OWASP SDL、思科的安全開發生命周期。兩個非常流行的軟件安全成熟度模型：Cigital的內置安全成熟度模型（BSIMM）和OWASP。BSIMM建立了一個最佳實踐模型，氛圍軟件制造商可以遵循的12類。

• 策略和度量標準
• 符合性和政策
• 培訓
• 攻擊模型
• 安全特征和設計
• 標準和要求
• 架構分析
• 代碼審查
• 安全測試
• 滲透測試
• 軟件環境
• 配置和漏洞管理

      可用于軟件安全的過程和模型有兩個要素：技術（工具）和人力。

      三個主要的工具是SDL的基礎：模糊測試、靜態和動態分析工具。模糊測試是一種自動或半自動化的黑盒軟件測試技術，他為某一計算機軟件程序輸入提供了無效、意外或者隨機數據。必須嵌入到SDL中。靜態分析（SAST）是指在不實際運行程序的條件下，進行計算機軟件分析的方法。主要針對特定版本的源代碼，也有些對象是目標代碼。有三個好處：

• 可以縮短時間
• 不會感到疲憊
• 幫助開發人員了解安全漏洞

動態分析（DAST）是指在真實或者虛擬處理器中運行程序的條件下，進行計算機軟件分析的方法

      兩類人才分別是軟件安全架構師和軟件安全從業者。合格的高級軟件架構師會創造或破壞軟件安全計劃，級別為3或4的高級軟件架構師是極為重要的。軟件安全從業者不僅要知道如何開發軟件，還要了解如何“像黑客一樣思考”并拆解軟件。

      最小特權原則：在計算環境特定的抽象層中，每一個模塊僅僅能訪問合法目的所必需的信息和資源。限制特權提升是威脅建模的重要部分，也是SDL架構A2階段的一個核心組成。保護用戶的隱私是SDL另一個重要組成部分，應被視為SDLC所有階段重要的系統設計原則。

      軟件開發方法：瀑布開發：下一階段開始之前每個階段結束，并且需要大量的文檔。高風險高成本低效率。迭代瀑布開發：整體項目分為不同的階段，每一階段采用傳統的瀑布方法各自執行，比傳統的瀑布方法風險小。敏捷開發：基于迭代和增量的開發方法。需求和解決方案通過自組織、跨職能的團隊之間的協同推進，并且從每一代迭代中產生的解決方案在整個過程中定期回顧和提煉。Scrum是一種迭代和增量敏捷軟件開發方法，用于管理軟件項目、產品或應用程序開發。精益是另外一種日益普及的方法，包括七個精益原則

安全評估(A1)

      安全評估是安全開發生命周期的第一個階段，在這個階段中，要解決四項原則問題：

• 軟件滿足客戶任務和關鍵程度如何？
• 軟件所必需的安全目標是什么？
• 那些法規和政策是適用于確定什么需要保護的？
• 在給軟件運行的環境中又可能存在什么威脅？

      在這一階段，軟件安全團隊提早參與項目并主持發現會議，創建SDL項目計劃。啟動隱私影響評估（PIA），PIA主要包含以下要點：

• 立法摘要
• 所需的工藝步驟
• 技術和技巧
• 其他資源

      安全評估成功的關鍵因素和度量標準

      度量標準

• 軟件安全團隊循環的時間
• 參加SDL的利益相關者的百分比
• SDL活動映射到開發活動的百分比
• 安全目標滿足的百分比

架構（A2）

      在安全開發生命周期的第二階段，安全方面的考慮被帶入軟件開發生命周期，以確保所有的威脅、要求、功能和集成方面的潛在制約因素均被考慮到。

      威脅建模五個步驟：

• 確定安全目標
• 調查應用程序
• 分解它
• 識別威脅
• 確定漏洞

      DREAD模型：潛在損害、可重復性、可利用性、受影響的用戶和可發現性，1-10用于建立風險評級，數字越高，風險越嚴重。DREAD算法用來計算風險值，是DREAD類別的平均值

      成功的關鍵因素

      度量標準

• 業務微威脅、技術威脅和威脅參與者的列表
• 這個階段之后不滿足的安全目標個數
• 遵守公司政策的百分比
• 軟件入口點的數量
• 風險接受、減輕和容忍的百分比
• 重新定義的初始軟件需求百分比
• 產品中計劃的軟件體系結構的變化數量
• 根據安全要求所需的軟件體系結構更改數量

設計和開發（A3）

      設計和開發是軟件最終用戶最為關心的部分。在這個階段你會做策略一致性分析，創建測試計劃文檔，更新威脅模型(根據需要)，進行安全性設計分析和總結，以及做隱私實施評估等，幫助你安全地部署軟件、建立開發最佳實踐，從而在開發階段的早期消除安全問題和隱私問題。你將會在SDL的設計和開發(A3)以及發布(A4)階段進行靜態分析。

      安全測試的通用步驟：定義測試腳本、定義用戶社區、識別項目障礙物、識別內部資源、識別外部資源。測試技術主要分為白盒、灰盒或黑盒。

• 白盒：從內部的角度測試軟件，包括：源代碼分析、基于屬性、源代碼錯誤注入
• 灰盒：設計測試用例的目的是分析源代碼，同時也使用黑盒技術，包括：源代碼錯誤注入、動態代碼分析、二進制錯誤注入
• 黑盒：從外部的角度測試軟件，沒有關于軟件的任何知識，包括：二進制錯誤注入、模糊測試、二進制代碼分析、字節碼分析、黑盒調試、漏洞掃描、滲透測試。

      成功的關鍵因素和度量標準

設計和開發（A4）

      A4策略一致性分析是A3策略依賴檢查的延續，在這個階段，任何存在于SDL域之外的策略都要被檢查或者重新檢查。安全測試是一個耗時的過程，需要適當的準備，確保前后一致，并協調所有利益相關方，以及對什么是真正測試內容的深刻理解。安全測試貫穿整個SDLC過程，在典型的SDLC周期中，軟件需要通過QA（質量保證）測試，包括單元測試、性能測試、系統測試和回歸測試。安全測試用例執行主要從兩個方面開展：安全機制和安全測試。對軟件產品和相關系統采取的三種特定的測試類型：基準測試、預定測試和探索測試。

      代碼審查對于發現軟件開發過程中的安全缺陷非常有效，代碼審查可以讓我們在代碼測試或安裝之前就找到和修復大量安全問題。有四種分析軟件應用安全性的基本技術：自動掃描、人工滲透測試、靜態分析、人工代碼審查

      安全分析工具包括靜態分析、動態分析、模糊測試和人工代碼檢查。每種方法各有優缺點。靜態分析是在計算機軟件實際上不執行的情況下進行的測試，也稱為靜態應用程序安全分析（SATA）。動態分析是通過再真實或虛擬處理器上運行程序進行計算機軟件分析的方法，也稱為動態應用軟件安全檢測（DAST），用來確認應用軟件產品中的漏洞。模糊測試是一種自動化或半自動化的黑盒軟件測試技術，他為計算機軟件輸入提供非法的、非預期的數據或隨機數據。必須嵌入在SDL中。人工代碼審查是通常對軟件產品進行逐行檢查以發現安全漏洞的方法，有更高的精確性和質量，但是最耗費資源

      成功的關鍵因素和度量標準

發布（A5）

      這是軟件開發生命周期的最后階段，需要確保軟件是安全的，隱私問題已經被解決到軟件發布時可以接受的程度。該階段需要進行漏洞掃描，利用應用程序和數據庫簽名嘗試確認應用程序缺陷的存在。滲透測試是模擬黑客行為對軟件系統進行的白盒安全分析。開源軟件必須按照資產進行管理，遵循許可證，必須像內部開發軟件標準一樣滿足安全需求，所以要進行開源審查。最后要進行最終安全性審查，對所有安全活動進行重新評估以確認軟件產品是否為發布做好準備。還要進行最終隱私性審查**。

      成功的關鍵因素

      度量標準

• 遵守公司策略的百分比
• 安全漏洞掃描和滲透測試發現的安全問題的數量、類型和嚴重性
• 發現的安全問題的修復數量
• 發現的嚴重問題的數量、類型、嚴重性
• 遵守安全和隱私需求的百分比

二、《The.Security.Development.Lifecycle.CN.軟件安全開發生命周期》

對SDL的需求

      隱私與安全：隱私可以看作是遵守策略的一種方式，安全則看做是一種執行策略的方式。隱私問題的核心是符合監管部門的要求、公司策略和客戶期望。關于安全還需要考慮的一個因素是與客戶簽訂的服務水平協議（SLA）和維護時間。安全與可靠性存在顯著差別，但有時候可能會產生沖突。微軟可信計算最初關注四個方面，其中三個是技術方面：安全、隱私和可靠性。下圖為質量、安全、隱私和可靠性之間的關系

      當前的軟件開發方法不足以生成安全的軟件，主要有以下四種：

• “只要給予足夠的關注，所有的缺陷都將無處遁形”
• 專利軟件開發模式
• 敏捷軟件開發模式
• 通用評估準則

      “只要給予足夠的關注，所有的缺陷都將無處遁形”不行的原因：大多數人并不喜歡審核代碼中的bug和漏洞，因為過程缺乏創新性且緩慢枯燥令人厭煩。有一個簡單的原則：代碼審核的質量，完全取決于待審核的代碼的多少；必須有足夠多的具備相關知識的人員才能夠對代碼進行充分的審核；“關注越多”越容易失去要點。

      專利軟件開發模式不行的原因：現在有許多開發模式，沒有任何證據表明，這些模式中的任何一種能比其中的另外一種締造出更安全的軟件。多數軟件開發模式在文檔中很少提及“安全”和“質量”。

      敏捷開發模式不行的原因：安全最佳實踐不夠深入。

      通用評估準則不行的原因：CC所提供的知識表明安全相關的特性已經按照預期執行的證據，他的目標并不是確保監控程序不出現任何實現上的安全bug。

軟件安全開發生命周期過程

第0階段：教育和意識

      微軟的bug bush本身是為了找出安全bug，但他的娛樂性遠遠高于其本身涉及的技術。奠定了微軟整個安全教育的根基。還有安全意識演講，應包含可信計算概述、SDL簡介、安全設計基礎、威脅建模、模糊測試介紹、安全編碼最佳實踐。微軟所有工程人員每年必須至少參加一次安全培訓，也可將在線培訓拍下來放到公司內網中。成功的安全教育與意識培訓需要三點

• 管理層明確支持
• 富有經驗演講者
• 持續進行的教育

第1階段：項目啟動

      首先判斷軟件安全開發生命周期是否覆蓋應用。原則上來說，所有的軟件都能從SDL過程中受益。接著指定一個在SDL過程中指引開發團隊安全活動的安全人員，其主要職責是確保最終安全審核能夠完成。這個員工叫做安全顧問。安全顧問是開發團隊與安全團隊之間溝通的橋梁，安全顧問需要召集開發團隊舉行SDL啟動會議，對開發團隊的設計與威脅模型進行評審，分析并對bug進行分類。接著是組建安全領導團隊，確保在bug跟蹤管理過程中包含有安全與隱私類bug。最后建立“bug標準”。

第2階段：定義并遵從設計最佳實踐

      常見安全設計原則：

• 經濟機制：保證代碼與設計盡可能簡單、緊湊。
• 默認失效保護：對任何請求默認應加以拒絕。
• 完全中介：每一個訪問受保護對象的行為都應當被檢查
• 公開設計：與“不公開即安全”的原則相對而言，認為設計本身不應具有神秘感。
• 權限分離：切勿允許基于單一條件的操作過程
• 最小特權：只授予執行操作所必需的最小特權
• 最少公共機制：使諸如文件以及變量等類似的共享資源盡可能少。
• 心理可接受程度

      進行受攻擊面分析與降低，不僅要理解應用的受攻擊面組成，而且還要理解如何才能有效地降低受攻擊面，從而阻止利用潛在的缺陷代碼進行攻擊的攻擊者。ASR主要有一下幾步：確定該特性是否真的很重要、誰需要從哪里訪問這些功能、降低特權。

第3階段：產品風險評估

      安全風險評估被用于判斷系統中易受攻擊的漏洞級別。需要考慮以下幾個問題：安裝問題、受攻擊面問題、移動代碼問題、安全特性相關問題、常規問題、分析問卷。

      隱私影響分級是產品風險評估的第二部分，這個分級包括三個策略值：隱私分級1，隱私分級2和隱私分級3。如果應用滿足以下任何一項，就具有最高可能性隱私分級，因而要求具有最高隱私保護職責。

      應用傳輸匿名數據給軟件開發人員或者第三方，則被劃分為隱私分級2.如果應用不包含1和2中任何一種行為，則被劃分為隱私分級3.

      統一各種因素：一旦確定應用程序的安全與隱私風險，就必須在日程表排出響應時間，以確保應用相應的技能以及努力來減少客戶所面臨的全面風險。

第4階段：風險分析

      威脅建模產物是描述應用背景信息并定義高層應用模型的文件，通常包括：應用場景、外部依賴性、安全假設、外部安全備注。威脅建模過程如下：

• 定義應用場景
• 收集外部依賴列表
• 定義安全假設
• 創建外部安全備注
• 繪制數據流圖
• 確定威脅類型
• 識別系統威脅
• 判斷風險
• 規劃消減措施

      威脅模型可以用來輔助代碼評審和測試。

第5階段：創建安全文檔、工具以及客戶最佳實踐

      創建指導性安全最佳實踐文檔，主要包括以下幾類：安裝文檔、主線產品使用文檔、幫助文檔、開發人員文檔

第6階段：安全編碼策略

      使用編譯器內置防御特性，這些保護性的代碼是由編譯器自動添加，無需開發人員進行干預，主要的防護選項：

• 緩沖區安全檢查：/GS
• 安全異常處理：/SAFESEH
• 數據執行防護兼容性：/NXCOMPAT

      使用源代碼分析工具本身并不能使軟件變得更安全，很容易落到陷阱中。但源代碼分析工具也有益處。切勿使用違禁函數，減少潛在可被利用的編碼結構或設計，使用安全編碼檢查清單。

第7階段：安全測試策略

      模糊測試最初用于發現可靠性bug，后來證明其也可以發現某類安全bug。模糊操作旨在通過反復解釋代碼分析數據結構，也可稱之為解析器，有三種：文件格式解析器、網絡協議解析器、API和其他零散解析器。滲透測試是一個用于在信息系統在中發現脆弱性的測試過程。還有一種測試方式就是運行時驗證。

第8階段：安全推進活動

      一次成功的推進活動需要周密的計劃以及從一開始就被列入日程計劃中的時間投入。軟件開發團隊最低程度也需要接受專門的培訓，以使其對安全推進活動的期望值以及推進流程等有所了解。計算機上運行的所有代碼或成為你軟件的一部分的代碼都必須被評審，而且該評審與代碼年限沒有關系。架構師和程序經理們需要對威脅模型進行不止一次的評審。在安全推進活動期間的程序化管理方式推動重估受攻擊面的任務完成，會獲得兩個主要的收益：好的安全習慣和有助于推動代碼評審任務的優先程度評級。最終，編寫終端用戶文檔的作者和編輯們都應當對他們所有的草稿文檔進行評審，以驗證安全最佳實踐是正確無誤的，且文檔中沒有述及潛在有危害的實踐。

第9階段：最終安全評審

      完整的最終安全評審過程有四個步驟，一是產品團隊協調，這一部分不是純技術性的活動，團隊必須填寫一個調查問卷。二是再次評審威脅模型，三是未修復的安全bug評審，驗證那些標記為“暫不修復”的安全bug是否可真正對其不予理睬。四是工具有效性驗證。

第10階段：安全響應規劃

      為什么準備響應？因為開發團隊一定會出錯，新漏洞一定會出現，規則一定會發生變化。準備安全響應包含兩個過程，第一是建立一個安全響應過程，第二就是每一個產品開發團隊的責任，組建一個安全響應中心

      產品團隊有效的執行響應過程是十分必要的，有兩個指導原則，一是準備安全響應的時間應位于漏洞被上報之前；二是每一個軟件團隊都必須做好安全響應準備。主要步驟：組建相應團隊、支持全線產品、支持所有客戶、使產品具備更新能力、在研究人員之前找到漏洞。

第11階段：產品發布

      如需軟件被簽字通過，安全與隱私團隊就必須認可以下事實：SDL過程被正確無誤地貫徹落實了。

第12階段：安全響應執行

      遵從你的計劃，如果有新上報的漏洞，保持冷靜，記住欲速則不達，留意可能改變計劃的事件，遵從你的計劃；盡你所能補救，深諳取舍之道