20181215實驗報告——實驗二：電子公文傳輸系統安全性設計方案與實現
- 實驗二 電子公文
- 《The.Security.Development.Lifecycle.CN.軟體安全開發生命週期》
- 第1章 適可而止∶ 威脅正在悄然改變
- 第 2 章 當前軟體開發方法不足以生成安全的軟體
- 第 3 章 微軟 SDL 簡史
- 第 4 章 管理層的 SDL
- 第 5 章第 O 階段∶教育和意識
- 第 6章 第 1階段∶專案啟動
- 第7 章 第 2 階段∶定義並遵從設計最佳實踐
- 第 8 章 第 3 階段∶產品風險評估
- 第9章第4 階段∶風險分析
- 第 10 章 第 5 階段∶建立安全文件、工具以及客戶最佳實踐
- 第 11章 第 6 階段∶安全編碼策略
- 第12 章 第 7階段∶安全測試策略
- 第 13 章 第 8 階段∶安全推進活動
- 第 14 章 第9 階段∶最終安全評審
- 第 15 章 第 10 階段∶安全響應規劃
- 第 16 章第 11 階段∶產品釋出
- 第 17 章 第 12 階段∶安全響應執行
- 第 18 章 在敏捷模式中整合 SDL
- 19 章 SDL 違禁函式呼叫
- 第 20 章 SDL 最低加密標準
- 第 21 章SDL 必備工具以及編譯器選項
- 第 22 章 威脅樹模式
實驗二 電子公文
密碼功能要求
在openEuler(推薦)或Ubuntu或Windows(不推薦)中完成下面任務
瀏覽附件中的《Core.Software.Security.Security.at.the.Source.CN.軟體安全.從源頭開始》，《The.Security.Development.Lifecycle.CN.軟體安全開發生命週期》兩本圖書，總結讀書筆記，重點是SDLsecurity development lifecycle，安全開發生命週期），小組每人要提交一份自己的筆記（markdown文件，每人一份）
小組討論電子公文傳輸系統，如何應用SDL對電子公文系統進行加團，給出一份加固計劃書，其中重點要包含系統資源的分析，基於STRIDE模型的威脅分析以及基於DREAD模型的風險分析，人員分工，開發計劃（每週至少提交一份進展報告），提交安全性設計方案（markdown文件，每組一份，不要髮網上）
參考 《GMT 0007 2012 電子政務電子認證服務應用指南》, GMT 0054-2018 《資訊系統密碼應用基本要求》和 國家標準GB/T 39786-2021《資訊保安技術 資訊系統密碼應用基本要求》提交一份系統安全性設計報告，重點是密碼方案的應用（markdown文件，每組一份，不要髮網上）
密碼演算法庫：
龍脈uKey
Bouncy Castle(支援Java )(https://www.bouncycastle.org/latest_releases.html)
GMSSL 的API（支援Java，Go，PHP） http://gmssl.org/docs/docindex.html
OpenSSL
1.系統密碼功能要求
? 安全性要求是無紙化電子公文傳輸系統首先要滿足的要求。由於網路環境的廣泛性和複雜性等特點，普通電子檔案很容易在網路傳輸過程中被擷取或篡改。而電子公文檔案必須具有保密性、嚴肅性和不可抵賴性的特性，絕對不允許出現此類安全漏洞。為此我們採用了RSA不對稱加密方法，藉助通過國家商業密碼委員會認證的硬體加密產品，實施電子公文檔案的加密操作。具體來說，公文的生成和製作首先要運用公文製作單位的加密狗，通過該單位的硬體私鑰密碼，以時間戳方式進行電子數字簽名，確保該公文的合法性、可識別性、嚴肅性和法律性。在公文的傳送過程中，根據收文單位，獲取對應收文單位的公鑰，以該公鑰對公文檔案進行加密，輸出給收文單位。收文單位獲取收文後，首先通過自己加密狗的私鑰對收文進行RsA解密，再對解密後的收文，以發文單位的公鑰進行收文的電子簽名驗證，確定來文的合法性。整個過程可簡單表示為:公文草件一(電子簽名)。電子公文一(RSA加密)鬥傳輸一(RSA解密)一收文一(電子簽名驗證)。閱讀時，對所有公章等關鍵資訊進行向量化操作，確保這類關鍵資訊不被非法截獲和使用，具體要做以下操作:讀入BMP圖片檔案，接著解讀BMP點陣，構造向量資料，存貯向量資料。以本單位加密狗私鑰對儲存的向量資料進行電子簽名，使向量章具備可識別性和法律嚴肅性。用本單位加密鉤公鑰及時間戳對已簽名公章檔案實施RS八加密，從而構造獲得加密後的公章檔案。
2.密碼技術應用要求
? 要保障電子公文的暢通傳輸，必須儘可能地降低網路傳輸的資料量，以適應複雜的網路環境。因此在資料加密之前，首先要利用Lzw演算法進行資料壓縮處理，使文字檔案的壓縮率將近1/1000從而有效控制公文傳輸的資料量。
3.應用和資料安全
由於電子公文傳輸系統的使用物件涉及政府部門及相關單位實際操作人數較多，因此其操作必須力求簡潔、方便。為此在設計上仿照電子郵件的操作模式，由收件箱·發件箱、系統設定等模組構成，操作人員只要學會電子郵件的收發，就能立即掌握無紙化電子公文傳輸系統的基本操作。
公文接收方瀏覽器如同WEB瀏覽器，其執行環境是複雜和多樣的，優秀的公文接收瀏覽軟體必須能適應多種多樣的軟體環境。為此無紙化電子公文傳輸系統提供了圖檔化的電子公文傳輸模式，從而使公文接收端可以無須與公文的傳送端具有相同的軟體環境，如不需要相同的字型環境、不需要相同的作業系統(要求是WIN9X以上作業系統)、不需要相同的字處理軟體等。
優秀的軟體系統一定是一個開放的系統，必須能夠提供有效的途徑，與使用者的其他相關係統之間進行資料交換。無紙化電子公文傳輸系統提供了以影印件圖片檔案形式輸出公文的能力，使其他系統可以直接引入、利用所接收的公文資料。
第三級密碼應用基本要求
1.物理和環境安全
1.真實性：物理訪問控制的身份鑑別資訊，重要區域進入人員身份
2.完整性：電子門禁系統進出記錄
3.完整性：視訊監控音像記錄
4.宜使用硬體密碼產品實現密碼運算和金鑰管理，符合GM/T0028三級以上密碼模組或通過國家密碼管理部門核准
2.網路和通訊安全
1.機密性+真實性：通訊雙方進行身份認證，防截獲，防假冒，防重用，保證傳輸過程中的鑑別資訊的機密性，網路裝置實體身份的真實性
2.完整性：網路邊界和系統資源訪問控制資訊
3.完整性：通訊過程中的資料
4.機密性：通訊過程中的敏感資料資訊欄位或整個報文
5.建立安全資訊傳輸通道，集中管理安全裝置、元件
6.宜使用硬體密碼產品實現密碼運算和金鑰管理，符合GM/T0028三級以上密碼模組或通過國家密碼管理部門核准
3.裝置和計算安全
1.對登陸的使用者進行身份標識和鑑別，身份標識具有唯一性，身份鑑別資訊具有複雜度且定期更換
2.機密性：遠端管理是實現鑑別資訊防竊聽
3.完整性：系統資源訪問控制資訊
4.完整性：重要資源資訊敏感標記
5.可信計算技術：系統到應用的信任鏈保護重要程式或檔案完整性
6.完整性：日誌記錄
7.宜使用硬體密碼產品實現密碼運算和金鑰管理，符合GM/T0028三級以上密碼模組或通過國家密碼管理部門核准
4.應用和資料安全
1.真實性：應用系統使用者身份——對登陸的使用者進行身份標識和鑑別，實現身份鑑別資訊的防截獲防假冒和防重用
2.完整性：業務應用系統訪問控制策略，資料庫表訪問控制資訊，重要資訊資源敏感標記
3.機密性：傳輸中的鑑別資料，重要業務資料和重要使用者資訊
4.機密性：儲存中的鑑別資料，重要業務資料和重要使用者資訊
5.完整性：傳輸中的鑑別資料，重要業務資料，重要審計資料，重要配置資料，重要視訊資料和重要使用者資訊
6.完整性：儲存中的鑑別資料，重要業務資料，重要審計資料，重要配置資料，重要視訊資料和重要使用者資訊和中藥可執行程式
7.完整性：日誌記錄
8.安全控制：重要應用程式的載入和解除安裝
9.宜使用硬體密碼產品實現密碼運算和金鑰管理，符合GM/T0028三級以上密碼模組或通過國家密碼管理部門核准
5.金鑰管理
資訊系統金鑰管理應包括對金鑰的生成，儲存，分發，匯入，匯出，使用，備份，恢復，歸檔與銷燬等環節進行管理和策略制定的全過程。
1.生成：
金鑰生成使用的隨機數應符合GM/T0005要求，金鑰應在符合GM/T0028的密碼模組內部產生，不得以明文方式出現在密碼模組外；
應具備檢查和剔除弱金鑰的能力。
2.儲存：
金鑰應加密儲存，並採取嚴格的安全防護措施，防止金鑰被非法獲取；
金鑰加密金鑰應儲存在符合GM/T0028的二級及以上密碼模組中。
3.分發：
應採取身份鑑別、資料完整性、資料機密性等安全措施，能抗擷取、假冒、篡改、重放等攻擊
4.匯入與匯出：
應採取安全措施，防止金鑰匯入匯出時被非法獲取或篡改，並保證金鑰的正確性存疑
5.使用：
金鑰應明確用途，並按正確用途使用；
使用公鑰密碼體系之前應驗證公鑰；
應有安全措施防止迷藥的洩露和替換；
金鑰洩露時，應停止使用，病啟動相應的應急處理和響應措施；
按照要求定期更換金鑰，並保證金鑰更換時的安全性
6.備份與恢復
應制定明確的金鑰備份策略，採用安全可靠的祕鑰備份恢復機制；
備份或恢復時要記錄，並生成審計資訊，包括備份或恢復的主體、時間等
7.歸檔
採取有效的安全措施保證歸檔金鑰的安全性和正確性
歸檔金鑰只能用於解密該祕鑰加密的歷史資訊或驗證該祕鑰簽名的歷史資訊；
記錄並生成審計資訊
歸檔金鑰進行資料備份並保護
8.銷燬
應具有在緊急情況下銷燬金鑰的措施如何定義緊急情況？
6.安全管理
制度
1.密碼安全管理制度及操作規範：包括密碼建設，運維，人員，裝置，金鑰等
2.定期重審修訂上文的不足之處
3.明確相關管理制度釋出流程
人員
1.瞭解並遵守密碼相關法律法規
2.正確使用密碼產品
3.建立崗位責任制度，明確職責和許可權，對關鍵崗位建立多人公關機制；金鑰管理，安全審計，密碼操作人員職責互相制約互相監督，相關裝置和系統的管理賬號不得多人共用
4.建立培訓制度，對密碼和金鑰管理人員專門培訓
5.建立關鍵崗位人員保密制度和調離制度，簽訂保密合同
6.建立人員考核制度，建立獎懲制度
實施
1.規劃：
資訊系統規劃階段，責任單位應依據密碼相關標準，制定密碼應用方案，組織專家進行評審，評審意見作為專案規劃立項的重要材料。
通過專家審定後的方案應作為建設，驗收和測評的重要依據。
2.建設：
應按照國家相關標準制定實施方案，至少包含：資訊系統概述，安全需求分析，密碼系統設計方案，密碼產品清單（資質，功能，效能列表，生產單位），密碼系統安全管理與維護策略，密碼系統實施計劃等。
應選用經過國家密碼管理部門核准的密碼產品、許可的密碼服務。
3.執行：
執行前：經密評機構評估通過後方可正式執行
執行後：每年開展密碼應用安全性評估並進行整改；重大安全隱患需停止系統執行，整改通過後再投入
應急
1.制定應急預案，做好應急資源準備
2.事件發生後應及時向資訊系統的上級主管部門進行報告
3.處置完成後，應及時向同級 的密碼主管部門報告事件發生情況及處置情況
電子公文傳輸系統應用基本要求
1.範圍
? 本標準規定了資訊系統第一級到第四級的密碼應用的基本要求，從資訊系統的物理和環境安全、網路和通訊安全、裝置和計算安全、應用和資料安全四個技術層面提出第一級到第四級的密碼應用技術要求並從管理制度、人員管理、建設執行和應急處置四個方面提出第一級到第四級的密碼應用管理要求。
注：第五級密碼應用僅在本標準中描述通用要求.第五級密碼應用技術要求和管理要求不在本標準中描述。
2.規範性引用檔案
? 下列檔案對於本檔案的應用是必不可少的。凡是注日期的引用檔案.僅注日期的版本適用於本文 件。凡是不注日期的引用檔案，其最新版本（包括所有的修改單）適用於本檔案。
3.術語和定義
（1）機密性 ：保證資訊不被洩露給北授權實體的性質。
（2）資料完整性 ：資料沒石遭受以非授權方式所作的改變的性質。
（3）真實性：一個實體是其所聲稱實體的這種特性。真實性適用於使用者、避程、系統和資訊之類的實體。
（4）不可否認性：證明一個已經發生的操作行為無法否認的性質。
（5）加密 ：對資料進行密碼變換以產生密文的過程。
（6）金鑰：控制密碼演算法運算的關鍵資訊或引數。
（7）金鑰管理 ：根據安全策略，對金鑰的產生、分發、儲存、使用、更新、歸檔、撤銷、備份、恢復和銷燬等金鑰全生存 週期的管理。
（8）身份鑑別 ：證實一個實體所聲稱身份的過程。
（9）訊息鑑別碼利用對稱密碼技術或密碼雜湊技術.在祕密金鑰參與下，由訊息所匯出的資料項任何持有這一祕密金鑰的實體，可利用訊息鑑別碼檢查訊息的完整性和始發者身份。
（10）動態口令：基於時間、事件等方式動態生成的…次性口令。
（11）訪問控制 ：按照特定策略?允許或拒絕使用者對資源訪問的一種機制。
4.概述
4.1資訊系統密碼應用技術框架
4.1.1框架概述
? 本標準從資訊系統的物理和環境安全、網路和通訊安全、裝置和計算安全、應用和資料安全四個層 而提出密碼應用技術要求.保障資訊系統的實體身份真實性、重要資料的機密性和完整性、操作行為的 不可否認性;並從資訊系統的管理制度、人員管理、建設執行和應急處置四個方面提出密碼應用管理要求為資訊系統提供管理方面的密碼應用安全保障。
4.1.2密碼應用技術要求維度
? 技術要求主要由機密性、完整性、真實性、不可否認性四個密碼安全功能維度構成.具體保護物件或 應用場景描述如下：
a）機密性技術要求保護物件
? 使用密碼技術的加解密功能實現機密性.資訊系統中保護的物件為：
1）身份鑑別資訊；
2）金鑰資料；
3）傳輸的重要資料；
4）資訊系統應用中所有儲存的重要資料。
b）完整性技術要求保護物件
? 使用基於對稱密碼演算法或、基於公鑰密碼演算法的數字名機 制等密碼技術實現完整性資訊系統中保護的物件為：
1）身份鑑別資訊；
2）金鑰資料；
3）日誌訕錄；
4）訪問控制資訊；
5）重要資訊資源安全標記；
6）重要可執行程式；
7）視訊監控音像記錄；
8）電子門禁系統進出記錄；
9）傳輸的重要資料；
10）資訊系統應用中所有儲存的重要資料。
c）真實性技術要求應用場景
? 使用動態口令機制、基於對稱密碼演算法或密碼雜湊演算法的訊息鑑別碼機制、基於公鑰密碼演算法 的數字簽名機制等密碼技術實現真實性?資訊系統中應用場景為：
1）進入重要物理區域人員的身份鑑別；
2）通訊雙方的身份鑑別；
3）網路裝置接入時的身份鑑別；
4）重要可執行程式的來源真實性保證；
5）登入作業系統和資料庫系統的使用者身份鑑別；
6）應用系統的使用者身份鑑別。
d）不可否認性技術要求保護物件
? 使用基於公鑰密碼演算法的數字簽名機制等密碼技術來保證資料原發行為的不可否認性和資料 接收行為的不可否認性。
4.1.3密碼應用管理要求維度
? 管理要求由管理制度、人員管理、建設執行、應急處置等四個密碼應用管理維度構成?具體如下：
a）密碼應用安全管理相關流程制度的制定、釋出、修訂的規範性要求；
b）密碼相關安全人員的密碼安全意識以及關鍵密碼安全崗位員T?的密碼安全能力的培養.人員 工作流程要求等；
c）建設執行過程中密碼應用安全要求及方案落地執行的?致性和石效性要求；
d）處理密碼應用安全相關的應急突發事件的能力要求。
4.2密碼應用基本要求等級描述
? 本標準對資訊系統密碼應用劃分為自低向高的五個等級,參照GB/T 22239的等級保護物件應具 備的基本安全保護能力要求,本標準提出密碼保障能力逐級增強的要求,用一、二、三、四、五表示。資訊系統管理者可按照業務實際情況選擇相應級別的密碼保障技術能力及管理能力，各等級描述如下：
——第一級，是資訊系統密碼應用安全要求等級的最低等級.要求資訊系統符合通用要求和最低限 度的管理要求，鼓勵使用密碼保障資訊系統安全；
——第二級，是在第一級要求的基礎上增加操作規程、人員上崗培訓與考核、應急預案等管理要求並要求優先選擇使用密碼保障資訊系統安全；
——第三級，是在第二級要求的基礎上，增加對真實性、機密性的技術要求以及全部的管理要求；
——第四級，是在第三級要求的基礎上，增加對完整性、不可否認性的技術要求；
5.通用要求
? 第一級到第五級的資訊系統應符合以下通用要求：
a）資訊系統中使用的密碼演算法應符合法律、法規的規定和密碼相關國家標準、行業標準的有關 要求；
b）資訊系統中使用的密碼技術應遵循密碼相關國家標準和行業標準；
c）資訊系統中使用的密碼產品、密碼服務應符合法律法規的相關要求。
電子公文傳輸系統安全性設計方案
1.安全需求
身份認證
身份認證體現在資料庫登入時連線資料庫的使用者所具有的角色，管理員和普通使用者所屬的資料庫角色是不一樣的，對於特定的表項，普通使用者是沒有檢視和修改的許可權的。
資料機密性
在資料傳輸過程中，要根據實現協商好的密碼協議進行通訊，在資料的傳輸過程中不能被中間黑客截獲未加密的資料。通訊雙方需要實現配置好安全協議、分配好金鑰。
資料完整性
在檔案傳輸時，需要生成相應的MAC值，接收方再次生成MAC與傳送方的MAC比對，比對成功時資料才算有效。
資料不可抵賴性
資料傳輸的過程中，傳送方需要用私鑰對檔案進行簽名，接收方用公鑰進行驗籤，驗證成功才能確定傳送方的身份。簽名和摘要可以同時進行。
2.認證協議
? 身份認證協議包括伺服器和客戶梯兩方完成伺服器對客戶押的身份認證及訪問臉制。具體要求客戶境持有加密卡既儲存RSA私鑰又支援隨機數生成、SHA1SHA-256摘要、RSA簽名等密碼運算功能伺服器持有RSA公鑰,具有隨機數生成、SHA-1/SHA-256摘要、RSA簽名驗證功能(可通過掛接密碼運算軟、硬體產品獲得相關支撐)。協議流程如圖所示
該協議特點:
（1）在初始階段,可生成若干對RSA金鑰對灌入加密卡,每個應用可選用其中的一對金鑰.而加密卡則可為多個應用提供密碼服務;
（2）應用中私鑰不會流出加密卡,也不會被暴力破解,具有高的安全性;
（3）加密卡髮卡過程簡單,部署應用簡便。
2.1密碼裝置訪問介面技術
? 目前,對於商用密碼裝置的功能訪問和開發存在多種介面,包括專用介面和通用介面(也稱為規範性介面)。通常密碼裝置廠商會提供涵蓋兩種形式的介面,供開發呼叫。專用介面對應特定密碼功能,將密碼應用中技術專業性較強的部分封裝起來.開發者無須花費較大的時間成本,即可進行業務開發,但基於專用介面開發的系統在擴充套件性及移植性上會受到限制。對於通用介面,國際和國內均推出了商用密碼領域被廣泛接受的技術規範和標準,國際上有RSA組織推出的PKCS#11標準(Cryptographic Token Interface Standard,密碼令牌介面標準[2),我國國家密碼管理局頒佈的《密碼裝置應用介面規範》(GM/T 0018-2012標準)。遵循通用介面規範開發的系統.在擴充套件性、可移植性、底層裝置相容性等方面有很大的靈活度。但通用介面並不能包涵密碼應用的所有方面,如通用介面規範對金鑰管理部分未提出較多定義.對於金鑰的安全備份和恢復等操作還需藉助專用介面。本文采用專用介面與通用介面相結合的方式。
2.2身份認證協議的安全性設計
2.2.1密碼裝置訪問介面技術
? 目前,對於商用密碼裝置的功能訪問和開發存在多種介面,包括專用介面和通用介面(也稱為規範性介面)。通常密碼裝置廠商會提供涵蓋兩種形式的介面,供開發呼叫。專用介面對應特定密碼功能,將密碼應用中技術專業性較強的部分封裝起來.開發者無須花費較大的時間成本,即可進行業務開發,但基於專用介面開發的系統在擴充套件性及移植性上會受到限制。對於通用介面,國際和國內均推出了商用密碼領域被廣泛接受的技術規範和標準,國際上有RSA組織推出的PKCS#11標準(Cryptographic Token Interface Standard,密碼令牌介面標準[2),我國國家密碼管理局頒佈的《密碼裝置應用介面規範》(GM/T 0018-2012標準)。遵循通用介面規範開發的系統.在擴充套件性、可移植性、底層裝置相容性等方面有很大的靈活度。但通用介面並不能包涵密碼應用的所有方面,如通用介面規範對金鑰管理部分未提出較多定義.對於金鑰的安全備份和恢復等操作還需藉助專用介面。本文采用專用介面與通用介面相結合的方式。
2.2.2身份認證協議的安全性設計
? 本文提出的協議是基於RSA演算法的簽名與驗證原理,是公鑰密碼演算法的一個應用。公鑰密碼演算法意味著公鑰在一定程度上是可以公開的,很可能受到選擇密文攻擊[3].這意味著不能讓私鑰擁有者對任何接收到的隨機訊息都執行數字簽名。本文提出在簽名過程中由加密卡產生另一預處理資料,以保證簽名訊息來源的可靠性,對兩項資料進行處理後再進行數字簽名,可有效防止選擇密文攻擊。在實際應用中或對於安全性要求更高的業務應用,可將RSA金鑰長度升級為更長的RSA2048/4096,或者將RSA演算法替換為ECC演算法或SM2演算法(安全性及金鑰長度可參考ECC演算法)。
3.資料庫加固
4.安全傳輸
安全的電子公文傳輸要求：
資料加密和解密
應該使用安全的密碼協議進行通訊、
保護系統和使用者的金鑰
在資料的傳輸過程中不能被中間人截獲未加密的資料。
資訊摘要計算
傳輸中使用安全的摘要演算法生成相應的MAC值
MAC值需要附在傳輸的資料後面進行驗證
數字簽名及驗證
數字簽名保證資料的不可抵賴性
生成高質量隨機數
通過高質量隨機數對系統進行抗重放攻擊保護
其它與安全有關的系統功能的實現
《The.Security.Development.Lifecycle.CN.軟體安全開發生命週期》
第1章 適可而止∶ 威脅正在悄然改變
1.1 遍佈安全和隱私衝突的世界
隱私與安全
很多人將隱私和安全看做是對同一問題的在不同角度的理解。然而，隱私可以看做是遵守策略的一種方式，而安全則看做是一種執行策略的方式。假如以休息室（Restroom）來作類比，房間門上的標識規定誰能夠進入，但可能並沒有安全措施阻止任何試圖進入的人員。房間門上加把鎖則能夠確保安全，有助於隱私策略的落實。
備註 隱私問題的核心是符合監管部門的要求（Security Innovation 2006）、公司策略和 客戶期望。
備註 風險管理能夠為資料洩漏所帶來風險進行賦值（可貨幣衡量 ）。
警告，有些人抱怨他們無法預設以管理員或根賬戶的身份執行系統。我們對此的答覆是;設定這一策略有助於在 Windows Vista中強制實施基本變更（change）;預設情形下，使用者僅意味著普通使用者而非系統管理員。本地管理員組成員都是使用者，除非需要提升許可權以執行管理任務。雖然以普通使用者身份執行可以獲得一定安全保障，但就隱私保護而言，成效仍有限。事實上，以使用者身份執行的惡意程式碼仍然可以訪問任何敏感資料，只要這些資料能被使用者讀取。
1.2 影響安全的另一因素∶ 可靠性
備註 微軟可信計算最初關注四個方面，其中三個屬於技術方面，可以解決我們之前討論過的問題∶安全、隱私和可靠性（第四個是業務實踐活動）。選擇這三個技術方面並非偶然。
1.3 事關質量
●安全和隱私 例如，使用加密機制來減少隱私類問題，這本身就是一種安全技術。
● 安全和可靠性 例如，DoS 威脅本身就是可靠性問題。
●可靠性和隱私 例如，如果應用軟體崩潰或失效後，在返回的錯誤訊息中記錄了敏 感資訊。這也是一種安全問題。範圍∶你可能也已覺察到，隱私、安全和可靠性方面的內容已經超出了圖中質量環的所在
●安全 如果使用者將惡意軟體裝入計算機，這屬於安全問題，並不是安全質量問題。 ●隱私 如果使用者主動向不可信的攻擊者透漏個人資料，例如在"釣魚"攻擊的情形 下，這便不屬於隱私質量問題。
●可靠性 如果使用者無意中摔倒並帶掉了電源線，這也不屬於軟體可靠性質量問題。
我們想說的是，安全不應被視為一個孤立的問題。只有將其與隱私、可靠性和質量作 為整體進行思考，安全才具有商業價值。從這點出發，你才有充分得理由向高層管理者們 "推銷"安全軟體改進的理念。
重要 導致敏感、機密或個人身份資料洩漏的安全 bug 屬於隱私類問題，並可能導致法律後果。引發可靠性問題的安全 bug 則可能減少系統正常執行時間，並致使系統違反服務水平協議 (SLA )
1.4 主要的軟體開發商為什麼需要開發更安全的軟體
如果你的軟體擁有眾多使用者，那麼改善軟體安全就是理所當然的事情;採用安全更新所帶來的高昂成本則會促使安全、隱私以及可靠性問題得以儘早解決，而不是將這一包袱留給使用者去承受。坦白地說，如果你擁有大量使用者，產品的每一個安全 bug 都會將眾多的使用者置於遭受攻擊或更嚴重的非法利用的風險之下，因為確保補丁百分百的部署程度是完全不可能的，這就意味著大量使用者仍將面臨風險。
1.5 內部軟體開發人員為什麼需要開發更安全的軟體
對於內部開發人員而言，實施 SDL 的主要獲益在於降低隱私和可靠性洩露的風險。儘管有直接的安全收益，但正如我們之前提到的，內部應用軟體的安全收益難以被量化。隱私是高層管理者和風險管理者所關注的風險因素，可靠性則事關正常執行和服務水平協議，將安全與隱私、可靠性捆綁"推銷"，才能獲得安全收益。
面向客戶的電子商務應用軟體存在高風險組成部分，在開發時應當予以特別的關注。
1.6 小型軟體開發者為什麼需要開發更安全的軟體
平心而論，大多數人並不討厭辛勞工作，只是會厭惡重複勞動。修復安全 bug 確實既困難又耗時。你可以選擇立刻投入成本以增加產品安全的概率，也可選擇在後期為此付出 更多代價。作為小型開發者或個人開發者，你可能並沒有太多的閒暇時間，所以在前期落 實較多的安全措施則能夠在後期節省更多的寶貴時間。質量良好的軟體意味著更少的重複 勞動，就會有更多的時間享受滑雪、健身、陪同孩子玩耍、讀書（並非軟體書籍!），或和心儀已久的另一半享受約會的樂趣。在微軟，我們意識到較少的安全漏洞，就意味著可以投入更多的時間關注客戶需要的產品的其他實用特性，並最終贏得更多客戶。
1.7 總結
威脅正在悄然改變，安全和隱私的情形也與 2001 年時大為不同。在互聯互通的今天，利益驅使下的犯罪者充斥著網路社會，因為這裡就是"存放金錢的地方"。沒有任何跡象表明這一趨勢會迅速減緩。
第 2 章 當前軟體開發方法不足以生成安全的軟體
2.1 "只要給予足夠的關注，所有的缺陷都將無處遁形"
2.1.1 稽核程式碼的動力
本章的作者（Michael）曾與數以千計的開發人員進行協作，指導開發人員如何稽核程式碼和設計上的安全 bug。Michael 審查過無數的程式碼。如果說從中獲取了一點經驗的話，那就是他發現大多數人並不喜歡稽核程式碼中的 bug 和漏洞。在稽核程式碼以查詢 bug（包括安全 bug 在內），與開發後續軟體產品的最新特性之間，開發人員更願意選擇後者——編寫新的程式碼。開發人員都極具創新意識，而開發新的特性是表現其創造力的最好方式。另一個不想稽核程式碼的原因則是程式碼稽核過程相當緩慢、枯燥並容易令人厭煩。
備註 微軟進行的分析表明，一名普通開發人員平均每天能夠稽核大約 1500 行 C 程式碼或
2.1.2 理解安全 bug
理解安全 bug 是非常重要的，在第 5章"第 0階段∶教育和意識"將對此進行詳細論述。如果你的工程師對安全 bug 的組成一無所知，在稽核元件的設計或基於該設計的程式碼時勢必會一無所獲。舉例來說，除非你瞭解 HTTP響應分割攻擊（HTTP Response Splitting attack）（Watchfire 2005），否則你就將無法察覺如下程式碼中的安全 bug∶<@ LANGUAGE=VBSCRIPT CODEPAGE = 1252 6> <!--#include file="constant.inc"_-> <!--#include file="1lib/session.inc"--> <6 SendHeader 0,1 *> <!--#include file="1ib/getrend.inc·--> <!--#include file="1ib/pageutil.inc"--><號'<!-- Microsoft Outlook web Access--> '<!-- Root.asp: Frameset for the Inbox window --> '<!-- copyright(c)Microsoft Corporation 1993-1997.All rights reserved.--> On Error Resume Next If Request.QueryString("mode") <>"" Then Response,Redirect bstrVirtRoot + _End If"/inbox/Main_fr.asp?" + Request.QueryString ()這一編碼 bug 存在於微軟 Exchange Server 5.5 的 Outook Web Access 元件中，微軟曾為此釋出安全公告 MSO4-O26（Microsoft 2004）。此類 bug 可能引發諸多安全問題。順便指出，該編碼 bug 起始於 Response.Redirect 行。
2.1.3 人員數量
接下來的問題就是人員數量問題∶ 必須有足夠多的具備相關知識的人員才能夠對程式碼 進行充分的稽核。是的，可能有很多具備安全專業知識的人員已經參與了一些諸如 Apache 和 Linux 核心等的大型專案，但相比較而言，能夠對正在開發的軟體實施程式碼稽核的人員卻出奇的少。 假設我們已經擁有眾多的具備相關能力的人員，他們不僅理解安全 bug 也能對程式碼中的安全錯誤進行稽核。或許你就開始認為可以將"足夠的關注"的說法換為"只要存在大量擁有經驗並樂於找出所有 bug 的人員，就會使得所有 bug 浮出水面"，但是，上述說法 仍然與軟體工程的各項過程毫無關係，這也正是我們的下一個話題。
2.1.4 "關注越多"越容易失去要點
能夠締造優良軟體的開發過程，其目標在於減少設計人員、架構師或者軟體開發人員在最開始引入 bug 的機率。當然在開發過程之外引入的 bug 也仍然屬於 bug，只是不必移除也不會對客戶造成任何負面影響。毫無疑問，程式碼稽核是絕對必要的，但簡單的"查詢bug"並不能形成一個安全軟體的完整過程。將程式碼"扔給"其他人員進行稽核很顯然是在 白費精力。SDL 的目標是減少某人在開發過程中引入安全 bug 的機率。
開源軟體中的許多安全缺陷已存在數年之久，列舉如下幾個例子∶
●15 年 Sendmail E-mail 伺服器（CVE-2003-0161）
●10年 MIT的 Kerberos 認證協議（CVE-2003-0060）
●7 年 SAMBA 檔案與列印服務（CVE-2003-0085）
●5 年 MIT 的 Kerberos 認證協議簇（CVE-2005-1689）
●5 垢 年 Eric Raymond 的 Fetchmail e-mail伺服器（CVE-2002-0146）
2.2 專利軟體開發模式
DL 與 CMMI/TSP /PSP 主要差別在於 SDL 專注於安全和隱私方面，而 CMMI/TSP / PSP 則主要關注提升質量和保持開發過程的一致性，通常並不包含特別規定或安全要求。 儘管這確實是一個值得為之努力的目標，但其潛在的邏輯是"如果質量全面提高，安全質 量理所當然就會提高"。無論正確與否，我們都找不到充分的商業開發案例來證實或反駁這 個觀點。以我們從 SDL 中積累的經驗表明，專用於減少安全和隱私類漏洞的過程和工具的 確能夠提供一致性並提升安全質量，這一點是經過實踐檢驗的。儘管我們對 CMMI/TSP / PSP與 SDL 相比，能在提高軟體安全質量方面究竟有多大效用仍無法給出最終結論，但我 們可以斷言，SDL 最起碼是一個提升安全質量的最優途徑。
2.3 敏捷開發模式
諸如極限程式設計之類的敏捷開發模式（Wikipedia 2006），嘗試通過以快速迭代方式（又 稱為時間窗或者 sprint），來構建軟體以降低軟體開發專案中的全域性風險。這些簡短的週期 性過程則有助於客戶更有效地進行反饋、互動、時間管理以及日程預期。
2.4 通用評估準則
重要 較高的評估等級，例如 EAL4 較之 EAL3 來說，並不意味著"更安全"。
重要 設計規範往往會遺漏那些僅在程式碼中才會出現的重要安全細節。
2.5 總結
當前的軟體開發模式缺乏足夠的安全意識、規定、最佳實踐和規則，歷年來軟體廠商所釋出的安全補丁數量就是最好的證明。為了改變這種狀況，業界必須對當前的工程方法進行改進以締造出更安全的軟體。
第 3 章 微軟 SDL 簡史
3.1 前奏
安全評估
在 20 世紀 80 年代初，美國國家安全域性（NSA）就開始編寫一系列評估準則，以描述抵禦針對作業系統軟體所發起的攻擊的安全特性，以及安全保障措施。這些準則，如可信計算機系統評估準則（TCSEC），即以其封面顏色而命名的橘皮書（DOD 1985），在 20 世紀的 80 年代到 90 年代間，指導了各個廠商作業系統開發團隊的工作。大多數那個時期的商用作業系統都達到了"C2"安全評估級別。更高級別，如 B2、B3 和 A1，則要求在設計階段進行更高級別的模組化以及結構 化，配備詳盡的文件，並且實現滿足國防和國家安全使用者需求的訪問控制模型，本書的作者之一（Lipner）就曾在上世紀 80 年代初期參與過對 NSA TCSEC 草案的評審工作，並後來負責 Digital Equipment 的一個專案，該專案就是開發一個達到 TCSEC A1 級別的系統（Karger 1991）。到 20 世紀 80 年代後期，其他一些政府，包括加拿大和幾個歐洲國家，也都著手編寫本國的、適用於作業系統軟體以及其他型別軟體安全評估的準則。這些國家評估過程大多與歐洲資訊科技安全評估準則，又稱 ITSEC（ITSEC 1991），一致。ITSEC 的結構與TCSEC 有所不同，其安全 特性需求與保障需求是分開進行處理的。到了 20世紀 90 年代中期，形勢發生了一些變化。對廠商來說，商業客戶或者政府客戶都不願意僅僅因為產品是否符合 TCSEC 或者 ITSEC 的某個較高級別而草率做出採購決策，而且商業產品的安全評估事實上仍侷限於在TCSEC C2 級別，（大致）相當於ITSEC 的 E3 級別。美國政 府以及歐洲 ITSEC 的支持者們為了形成一個更為廣泛的評估產品市場並提高效率而不懈努力，雙 方終於在 90 年代後期達成一致，通過了資訊科技安全評估通用準則（Common Criteria for Information Technology Security Evaluation），或簡稱為通用準則（Common Criteria2005）。如今， 通用準則已經被國際社會正式認可了，代號為 ISO 15408。微軟產品曾經歷過眾多評估體制下的評估。因為對於不同的行業來說，客戶可能並不需要也不想購買那些具有TCSEC B2 級別所提供的特性的產品，微軟曾將 Windows NT3.51和4.0 分別提交以評估其是否達到TCSEC C2和ITSEC E3 級別。微軟 SQL Server 2000 也已達到 TCSEC 的"資料庫解釋"中的C2 級別。微軟近年的產品，包括Windows2000、Windows XP、Microsoft WindowsServer 2003、ISA Server 2004，以及 Exchange Server 2003 都已經完全達到通用準則的 EAL4 級別，這也是如此眾多的商業產品所達到的最高級別（Common Criteria2006）。其他微軟產品在本書編寫時仍在評估中。
3.2 新威脅，新對策
與此同時，微軟組建了內部的安全任務組（Security Task Force）檢查漏洞發生的根本原因，並著手策劃開設培訓課程幫助於減少漏洞。STF 所採用的"建議"（recommendations）機制便成為 SDL 的雛形。當我們在7年之後再度回顧時，會發現當初 STF 的報告具有驚的預見性。這些建議的一些關鍵組成部分包括如下幾點。
●專注於管理層承諾的需求。
●專注於工程師意識與培訓需求。
● 採用過程，即現在的威脅建模的前身。
●運用工具和程式碼稽核，以檢測並移除可能導致潛在安全漏洞的常見編碼錯誤。
● 強調安全測試的重要性，包括"像黑客一樣思考"。
●專注於產品正式釋出（post-release）後安全響應過程的需求。
● 建議重組產品部以提升安全性，包括∶
在產品部中建立專門的安全團隊。
定義一個持久的"安全 bug 標準"（security bug bar），以對潛在安全漏洞的嚴重
程度進行評估。
》 追蹤已發現的和已修復安全漏洞，以及從新的安全漏洞中吸取教訓。
3.3 Windows 2000 和 Secure Windows Initiative
PREfix 是微軟的第一個靜態分析工具。PREfix 相關技術來自於微軟收購的一家名為Intrinsa 創業公司。該公司的多數員工進入到微軟程式設計師生產力研究中心（ProgrammerProductivity Research Center ，PPRC）。在 20世紀 90年代後期，PREfix 就能夠通過對從非受信源到堆疊緩衝器的輸入流進行跟蹤，而檢測出一些基於堆疊的緩衝區溢位漏洞。儘管PREfix 在 Windows 2000 上的運用產生了作用，它使某些種類的安全漏洞被移除出去，但微軟研究團隊和 SWI 團隊仍然耗費了數年時間對其進行了再次開發，又發現了一些新型漏洞，才使 PREfix 成為編寫安全程式碼最有效的工具之一。即便如此，從 Windows 2000獲得的經驗告訴 Windows 開發人員，雖然能夠對程式碼進行自動化的分析，但他們仍要對這些自動分析出來的"安全漏洞"加以分析和糾正。
3.4 追求可度量性∶貫穿 Windows XP
備註 PREfix 和 PREfast 的主要區別在於，PREfix 能夠發現存在於多個程式或元件之間的錯誤，而 PREfast 則在單一程式查詢錯誤時更為有效。PREfix 由核心團隊進行維護，並用於週期性掃描所有產品程式碼基。PREfast 則適用於開發人員自行對其程式碼檢測之前進行掃描。PREfast 已經整合在微軟 Visual Studio 2005 的/Analyze 選項中。
3.5 安全推進和最終安全評審（FSR）
2003 年的大部分時間裡，SWI 團隊都一直在為產品部培訓，幫助組織安全推進活動，和開展預釋出產品的稽核（最初被稱為"安全審計"，現在則命名為 Final Security Reviews，FSR，以避免與對即將釋出的軟體進行的財務審計或操作審計相混淆）。所有的這些努力終有回報，此間釋出的產品漏洞率都有不同程度的下降，但 SWI團隊所採用的方式仍然是非正式的。指導該團隊工作的文件在 Windows Server 2003 安全推進的末期已經基本成型（主要由 Michael Howard 完成），當然，SWI 團隊中行之有效的實踐方法，以及所需要注意的問題更多的是成員之間口口相傳。這種方式的有效性有目共睹，只是其本身不太有條理!
3.6 形成軟體安全開發生命週期
向 SDL 2.0 的轉換活動於2004 年 7月1日完成。此時，超過半數的微軟工程人員完成 了 SDL 所強制要求的新安全培訓，符合 SDL 的正式需求也被公開發布在內部 Web 站點上 SWI團隊的成員數在 2004年1月到 6 月間也進一步擴張，以滿足下列職責需求∶
●實施安全培訓;
●開發和更新 SDL自身定義;
●開發和支援實施 SDL 約束所需的支援工具;
●為產品團隊提供 SDL 相關建議和諮詢服務;
●在產品釋出前實施 FSR。
3.7 持續的挑戰
我們知道採用 SDL 中的技術增加了攻擊者的入侵難度，這一點從基於 SDL 過程（以及其前身）所開發的軟體中的漏洞統計得到證明。沒有最好，只有更好。我們還知道，新型漏洞的發現會刺激新的攻擊技術和工具的產生。為此我們需要不斷對 SDL 進行更新，並在此過程中將安全響應機制整合在內。我們編寫本書的目的就在於為其他開發機構提供一個可以提高軟體抗攻擊性的框架，並使其能夠組織好自己的過程，以應對軟體安全所帶來的持續挑戰。
第 4 章 管理層的 SDL
4.1 成功的承諾
4.1.1 微軟的承諾
本書的作者們在"日常工作"中，經常會向微軟客戶以及合作伙伴介紹 SDL 的內部執行機制，並解釋微軟如何利用該過程締造更安全的產品。我們經常聽到的一個問題是∶"SDL的哪個部分或方面對於最終的成功是最重要的?"這個問題實在難於回答，因為 SDL 是由大量相對獨立而又同等重要的階段有機組成的一個整體。在類似微軟這樣的組織中，是否
4.1.2 你是否需要 SDL?
實施 SDL 需要投入大量資金，在管理者們問 SDL 是否必要時，我們也一再強調 SDL並不是廉價工程。事實上，這應該"視情況而定"。如果客戶依賴於你所開發的軟體的安全性，你就有必要確保你所提供的軟體能夠應對種種挑戰。很顯然，平臺類產品、作業系統、資料庫系統、電子郵件和協作伺服器（collaboration servers）都可被歸入此類，因為這些產品必須保護客戶資料的保密性和完整性，而且平臺提供的計算資源即使在遭受惡意攻擊時也應該仍然可用。安全對於其他型別的產品也一樣重要，包括電子商務（Web）應用和與組織內用到的特定應用（在這種應用中必須處理敏感資料，而且不是所有使用者都可信或經過授權）。政府指定的供應商所開發的處理敏感資訊的諸多應用也要求採用更苛刻的安全措施。儘管這些應用的安全機制可能會因所依賴平臺的不安全而被繞過，但是如果突破平臺級的安全措施機制使得攻擊成本上升或不可執行，攻擊者們仍然會將目標對準應用本身。
4.1.3 有效承諾
如果決定在你的組織開發的某些或全部的軟體中採用 SDL，作為管理者，如何確保你的組織的各項投入都有所回報?下面幾段總結了一個管理人員為支援在組織內應用SDL所應採取的行動。口 作出宣告如果你認為對於開發團隊而言實施 SDL 以締造更安全的軟體是非常重要的，就必須明確地表達出來。在微軟，Bill Gates 發出了關於可信計算的電子郵件，但這並不是全部。在我們開始鼓勵各個團隊管理者們加入 Windows 安全推進活動時，Jim Allchin（當時的平臺集團副總裁）就親自啟動了簡要/培訓課程，Brian Valentine（Windows 部門高階副總裁）也在全部門範圍傳送電子郵件，告訴員工我們究竟在做什麼，為什麼這樣做是至關重要的。類似的事情在 Microsoft Exchange 和 SQL Server 產品上也發生過。
4.2 管理 SDL
4.2.1 資源
依據以往經驗，我們知道，決定一種資源是否能被用來實施 SDL 的可變因素很多，而且我們十分了解這些因素影響成功實施 SDL 所需資源的方式。然而，目前我們仍無法給出一套等式來明確說明，例如;"對於既定程式碼量、實現語言和在網際網路上的暴露程度等來說，這就是你在實現 SDL 符合性（compliance）時所應採用的預計開發資源水平的相關因素。"原因之一是在微軟我們並沒有實際地收集更精確的資源資料。與那些以小時計時來進行開發的國防承包商、服務巨頭有所不同，微軟典型的做法是指定某一團隊負責一個或多個產品，然後將整個團隊的成本分攤到產品之中。微軟不會將開發過程中的個體活動所產生的更精細的成本計算在內。所以，當前的 Windows 釋出中都已支付過 Windows 測試人員的薪水，無論這些測試人員是在測試應用相容性，抑或是在進行 SDL 過程中的安全"模糊測試"（fuzztesting)。
4.2.2 專案是否步入正軌?
從第 5 章"第 0階段∶ 教育與意識"開始，貫穿於整個第 2 部分的"安全開發生命週期過程"，我們將詳盡討論 SDL 各個階段所需要執行的活動。在 SDL，的每一階段都要求進行特定的活動，併產生特定的輸出，無論是以文件形式（某些情況下）還是專案作流系統中的 bug 形式，對這些過程輸出都必須進行調查並（多數情況下）加以修復。承擔在產品中實施 SDL 的管理者或負責人應當密切關注輸出成果，以判斷究竟投入過多還是不足。下面列出了一些有助於評估 SDL 的實施質量的關鍵度量指標，使管理者不會在產品交付之時才感到詫異。
4.3 總結
負責人和管理者們在軟體開發組織實施 SDL 的過程中扮演了極為關鍵的角色。管理層的承諾對於團隊成功實施 SDL 和締造更安全的軟體而言，至關重要。對 SDL 的成本和收益進行度量是頗為艱難的。儘管沒有任何權威性的指南闡述對 SDL 對專案開銷和日程安排的影響進行精確度量的方法，但是通過對交付物以及 SDL 各個階段的相關活動實施必要監控，則能夠使管理者更清楚地瞭解專案是否正按照既定軌道進行，SDL 的成本有多少。通過對外部度量指標，比如客戶對安全的滿意度，以及安全事件對產品和服務的影響程度的持續追蹤，可以使管理者類比性地理解實施 SDL 所獲得收益。
第 5 章第 O 階段∶教育和意識
5.1微軟安全教育簡史
5.2 持續教育
5.3 培訓交付型別
5.4 練習與實驗
5.5 追蹤參與度與合規度2
5.6 度量知識3
5.7 實現自助培訓
5.8 關鍵成功因子與量化指標4
5.9 總結
第 6章 第 1階段∶專案啟動
6.1 判斷軟體安全開發生命週期是否覆蓋應用7
6.2 任命安全顧問8
6.2.1 擔任開發團隊與安全團隊之間溝通的橋樑
6.22 召集開發團隊舉行SDL 啟動會議
6.2.3 對開發團隊的設計與威脅模型進行評審
6.2.4 分析並對 bug 進行分類，如安全類和隱私類
6.2.5 擔任開發團隊的安全傳聲簡
6.2.6 協助開發團隊準備最終安全稽核
6.2.7 與相應安全團隊協同工作
6.3 組建安全領導團隊
6.4 確保在 bug 跟蹤管理過程中包含有安全與隱私類 bug
6.5 建立"bug 標準"
6.6 總結
第7 章 第 2 階段∶定義並遵從設計最佳實踐
7.1 常見安全設計原則
7.2 受攻擊面分析與降低
7.2.1 第一步∶該特性真的有那麼重要麼?
7.2.2 第二步∶究竟誰需要從哪裡訪問這些功能?
7.2.3 第三步，降低特權
7.2.4 其他受攻擊面組成部分
7.3總結
第 8 章 第 3 階段∶產品風險評估
8.1安全風險評估
8.1.1安裝問題4
8.1.2 受攻擊面問題
8.1.3 移動程式碼問題
8.1.4 安全特性相關問題
8.1.5 常規問題
8.1.6 分析問卷
8.2隱私影響分級
8.2.1 隱私分級1
8.2.2 隱私分級2
8.2.3 隱私分級3
8.3 統一各種因素（Pulling It All Together）
8.4 總結
第9章第4 階段∶風險分析
9.1 威脅建模產物（Artifact）
9.2 對什麼進行建模
9.3 建立威脅模型
9.4 威脅建模過程
9.4.1 定義應用場景
9.4.2 收集外部依賴列表
9.4.3 定義安全假設
9.4.4 建立外部安全備註
9.4.5 繪製待建模應用的一個或多個數據流圖（DFD）
9.4.6 確定威脅型別
9.4.7 識別系統威脅
9.4.8 判斷風險
9.4.9 規劃消減措施
9.5 利用威脅模型輔助程式碼評審
9.6 利用威脅模型輔助測試
9.7 關鍵成功因子和指標
9.8 放結
第 10 章 第 5 階段∶建立安全文件、工具以及客戶最佳實踐
10.1 為什麼需要文件和工具?
10.2 建立指導性安全最佳實踐文件
10.2.1 安裝文件
10.2.2 主線產品使用文件
10.2.3 幫助文件
10.2.4 開發人員文件
10.3 建立工具
10.4 總結
第 11章 第 6 階段∶安全編碼策略
11.1 使用最新版本編譯器與支援工具
11.2 使用編譯器內建防禦特性
11.2.1 緩衝區安全檢查∶/GS
11.2.2 安全異常處理∶/SAFESEH
11.2.3 資料執行防護相容性∶/NXCOMPAT
11.3 使用原始碼分析工具
11.3.1 原始碼分析工具陷阱
11.3.2 原始碼分析工具的益處
11.4 切勿使用違禁函式
11.5 減少潛在可被利用的編碼結構或設計
11.6 使用安全編碼檢查清單
11.7 總結
第12 章 第 7階段∶安全測試策略
12.1模糊測試
12.1.1 模糊操作檔案格式
12.1.2 網路協議模糊操作
12.1.3 零散模糊測試
12.1.4 通過模糊測試修復發現的 bug
12.2滲透測試
12.3 執行時驗證
12.4 必要時稽核並更新威脅模型
12.5 重估軟體的受攻擊面
12.6總結
第 13 章 第 8 階段∶安全推進活動
13.1 準備安全推進活動…………………………………………………………………………170
13.2 培訓………………………………………………………………………………………………………171
13.3 程式碼評審……………………………………………………………………………………………………… 172
13.4 威脅模型更新…………………………………………………………………………………………174
13.5 安全測試…………………………………………………………………………………………………………… 175
·XX.
僅供個人科研教學使用
13.6受攻擊面 Scrub……………………………………………………………………………175 13.7 文件 Scub…………………………………………………………………176 13.8 是否已足夠?…………………………………………………………………………………………177 13.9 總結……………………………………………………………………………………………………178 參考文獻………………………………………………………………………………179
第 14 章 第9 階段∶最終安全評審
14.1 產品團隊協調………………………………………………………………………………… 182 14.2 威脅模型評審………………………………………………………………182 14.3 未修復的安全 bug 評審……………………………………………………………………………………183 14.4 工具有效性驗證……………………………………………………………………………………………………184 14.5 在最終安全評審完成之後…………………………………………………………………………….184 14.6 總結………………………………………………………………………………………………………………185
第 15 章 第 10 階段∶安全響應規劃
15.1 為什麼準備響應?…………………………………………………………………………………………187 15.1.1 你的開發團隊一定會出錯………………………………………………………………………187 15.1.2 新漏洞一定會出現…………………………………………………………………………188 15.1.3 規則一定會發生變化………………………………………………………………………189 15.2 準備響應…………………………………………………………………………………190 15.3 安全響應與開發團隊……………………………………………………………………………208 15.3.1 組建你的響應團隊……………………………………………208 15.3.2 支援你的全線產品……………………………………………………………………209 15.3.3 支援你的所有客戶…………………………………………………………………210 15.3.4 使你的產品具備更新能力…………………………………………………211 15.3.5 在研究人員之前找到漏洞…………………………………………………212 15.4 總結…………………………………………………………………………………………213 參考文獻………………………………………………………………………………………………………………213
第 16 章第 11 階段∶產品釋出
第 17 章 第 12 階段∶安全響應執行
17.1 遵從你的計劃……………………………………………………………217
·XXI.
僅供個人科研教學使用-
17.1.1 保持冷靜………………………………………………………………………………………………………217
17.1.2 欲速則不達……………………………………………………………………………… 218 17.1.3 留意可能改變計劃的事件………………………………………………………………219
17.1.4遵從你的計劃……………………………………………………………………………………………………220
17.2 盡你所能補救…………………………………………………………………………………………………220
17.2.1 知道該聯絡何人……………………………………………………………………………………220
17.2.2 能建立更新…………………………………………………………………………………………220
17.2.3 能安裝更新………………………………………………………………………………………………221
17，2.4 明確輕重緩急…………………………………………………………………………… 221
17.3 深諳取捨之道……………………………………………………………………………………………………221
17.4 總結……………………………………………………………………………………………………………………222
參考文獻………………………………………………………………………………………………………………………………… 222
第 3 部分 SDL 參考資料
第 18 章 在敏捷模式中整合 SDL
18，1 在敏捷模式中進行 SDL 實踐活動…………………………………………………………………………226
18.1.1 安全教育……………………………………………………………………………………………………………226
18.1.2 專案開始……………………………………………………………………………………………………………226
18.1.3 建立並遵從設計最佳實踐………………………………………………227
18.1.4 風險分析………………………………………………………………………………………………227
18.1.5 建立安全文件、工具以及客戶最佳實踐……………………………………………229
18.1.6 安全編碼與測試策略…………………………………………………………………………………229
18.1.7 安全推進……………………………………………………………………………………………………………231
181.8 最終安全評審………………………………………………………………………………………………232
18.1.9 產品釋出……………………………………………………………………233
18.1.10 安全響應執行……………………………………………………………………………………………233
18.2 利用SDL 實踐增強敏捷模式………………………………………………………………234
18.2.1 使用者 story………………………………………………………………………………………………………235
18.2.2 小發布與迭代……………………………………………………………………………236
18.，2.3 人員輪換…………………………………………………………………………………………………236
18.2.4簡化 …………………………………………………………………………………………………………236
18.2.5 衝刺（Spike）解決方案…………………………………………………………………………236
18.2.6 重構
18.2.7 常規客戶可用性
18.2.8 依據標準編碼………………………………………………………………………………237 18.2.9 優先編寫單元測試………………………………………………………………………238
18.2.10 配對程式設計………………………………………………………………………………………238 18.2.11 多次整合…………………………………………………………………………………………238 18.2.12 將優化留到最後………………………………………………………………………………………238
18.2.13 一旦發現一個bug，就建立一個測試…………………………………………………239 18.3 總結…………………………………………………………………………………………………………… 239 參考文獻…………………………………………………………………………………………………… 239
19 章 SDL 違禁函式呼叫
19.1 違禁API………………………………………………………………………………………………………………242 19.2 為什麼"n"函式會被禁止………………………………………………………………245 19.3 重要告誡……………………………………………………………………………………………246 19.4 選擇 StrSafe ys.Safe CRT…………………………………………………………………246 19.5 使用StrSafe…………………………………………………………………………………………………246 19.6 使用Safe CRT……………………………………………………………………………………247 19.7 其他替代函式………………………………………………………………………………………248 19.8 工具支援………………………………………………………………………………………………248 19.9 ROI和成本影響……………………………………………………………249 19.10 度量和目標…………………………………………………………………………………………249 參考文獻…………………………………………………………………………………………………… 249
第 20 章 SDL 最低加密標準
20.1 高階加密需求…………………………………………………………………………………251 20.1.1 加密技術 ys 低階加密演算法…………………………………………………251 20.1.2 使用加密庫…………………………………………………………………………………252 20.1.3 加密敏捷度………………………………………………………………………252 20.1.4 預設安全加密演算法……………………………………………………………………253 20.2 加密演算法的用法……………………………………………………………………………………253 20.2.1 對稱塊密碼與金鑰長度……………………………………………………254 20.2.2 對稱流密碼與金鑰長度……………………………………………………………………254
·XXIl
_僅供個人科研教學使用
20.2.3 對稱演算法模式 …………………………………………………………………………………………255
20.2.4 非對稱演算法與金鑰長度……………………………………………………………………………………255
20.2.5 雜湊函式…………………………………………………………………………255
20.2.6 訊息認證碼……………………………………………………………………………………256
203 資料儲存以及隨機數生成………………………………………………………………………………………256
20.3.1 儲存私鑰以及敏感資料………………………………………………………………………………256
20.3.2 生成隨機數與金鑰………………………………………………………………………257
20.3.3 使用密碼或者其他金鑰來生成隨機數和加密金鑰……………………………………………257
參考文獻……………………………………………………………………………………………………… 257
第 21 章SDL 必備工具以及編譯器選項
21.1 必備工具
21.1.1 PREfast
21.1.2 FxCop
21.1.3 應用驗證器（Application Verifier）
21.1.4 最小編譯器與 Build 工具版本
第 22 章 威脅樹模式
22.1 假冒一個外部實體或過程
222 算改—個過程
22.3 篡改一個數據流
22.4 篡改一個數據儲存
22.5 抵賴
22.6 過程資訊洩露
22.7資料流資訊洩露
22.8 資料儲存的資訊洩露
22.9 針對過程的拒絕服務
22.10 針對資料流的拒絕服務
22.11 針對資料儲存的拒絕服務
22.12 特權提升
第1章
引 論
1.軟體安全的重要性和相關性。軟體是我們在現實世界中做任何事情的關鍵，同時，
軟體也分佈在最關鍵的系統中。基於此，軟體的安全設計是至關重要的。大多數資訊科技
（Information Technology，IT）相關的安全解決方案已經能夠有效地降低不安全軟體帶來的風
險。為了證明一個軟體安全程式的合理性，必須知曉沒有構建安全軟體帶來的金錢成本和其
他風險的重要性與相關性，以及構建安全軟體的重要性、相關性和成本。總而言之，軟體安
全同樣是一個商業決定，因為它關注避免安全風險。
2.軟體安全和軟體開發生命週期。在這裡，重要的一點是要區分在軟體開發中我們熟知
的軟體安全（software security）和應用程式安全（application security）。儘管這兩個術語經常
互用，但是我們仍然需要區分它們。因為實現這兩個目的的程式在管理過程中存在明顯的不
同。在模型中，軟體安全表示在 SDLC中，應用SDL 構建安全的軟體，而應用程式安全表示
釋出後執行過程中軟體和系統的保護。
3.高質量和安全程式碼。儘管安全程式碼未必是高質量程式碼，同時高質量程式碼也未必是安全
程式碼，但是軟體的開發過程是基於高質量和安全程式碼原則的。你不能擁有不安全的高質量代
碼，更不能擁有劣質的安全程式碼，它們相輔相成。至少，質量和軟體安全程式應該在開發過
程中緊密結合;理想情況下，它們應該是同一組織的組成部分，以及軟體開發工程部門的一
部分。這將在本書中後面的章節中從組織和操作角度進一步討論。
\4. 三個最重要的 SDL 安全目標。所有軟體安全分析和構建的核心是三個最重要的安全因
素∶ 保密性（Confidentiality）、完整性（Integrity）和可用性（Availability），也稱為C.I.A.模型。
為了確保軟體開發是安全的，上述三個特性必須一直作為整個 SDL 過程中的主要組成部分。
\5. 威脅建模和攻擊介面驗證。威脅建模和攻擊介面驗證是 SDL 中最耗時和難以理解的部
分。在當今的敏捷軟體開發中，必須正確處理這個問題，否則無法保證軟體安全。SDL 中的
威脅建模和攻擊介面驗證，將最大限度地避免軟體產品釋出後發現安全漏洞。我們認為這個
功能非常重要，因此本書將專門用一節和一章來關注這個主題。
1.2 軟體安全和軟體開發生命週期
多年來，安全業界對於軟體安全和應用安全存在著一個嚴重的誤解。Gary McGraw 提供
了關於兩者之間差異的一個清晰描述∶
一方面，軟體安全是關於構建安全軟體的∶將軟體設計成安全的; 確保軟體是
安全的;培訓軟體開發人員、架構師和使用者如何構建安全到軟體中。另一方面，應
用程式安全是關於保護軟體和該軟體釋出後執行的系統，當且僅當開發完成後。15】
從第一個大規模針對軟體的攻擊開始，到20世紀 80年代後期，軟體安全已經走過了漫
長的道路。當時軟體並沒有過多地考慮安全問題（如 UNLX 程式碼、TCP/IP 協議棧）。隨著微軟
Windows 以及網頁（Web）的出現，攻擊開始變得複雜和頻繁，因此軟體的安全性才逐漸得到
重視。工業界開始通過各種輔助手段短期修復安全問題。這些因素推動了防毒軟體、防火牆、
反間諜軟體的出現。然而，真正的問題——程式碼是如何開發和編寫的——並沒有得到重視。
這個問題直到最近十年來出現了SDL 實踐才得到重視。許多企業（如微軟）由於軟體安全缺
陷的影響開始意識到通過改善軟體開發實踐，以確保安全的軟體程式碼的重要性。這導致學術
界和軟體巨頭都推薦 SDL 實踐，如微軟等。現在我們有理論和指導原則來幫助我們從軟體開
發一開始就構建安全的程式碼，從而降低出現可能被攻擊者利用的軟體漏洞的可能性。
1.3 程式碼的質量與安全
開發應用軟體的流程，是基於程式碼質量和程式碼安全共同的最佳原則的。這些最佳原則是
軟體行業最佳實踐的概念和設計背後的成因。為了開發經得起時間考驗的安全程式碼，你必須
學會如何將這些原則納入到開發過程中。請記住，安全的程式碼不一定是高質量的程式碼，高質
量的程式碼不一定是安全的程式碼。
1.4 SDL 三個最重要的安全目標
任何一個合格的開發人員都可以編寫非常高效的、可維護的和易於重用的程式碼;但是，
如果該程式碼允許未經授權的使用者訪問應用程式管理的資源，該程式碼就是不安全的。遺憾的是，
在軟體開發生命週期中，安全性仍然是經常被忽視或者投入最少的方面。資訊保安界認為
SDL 最低也是最為重要的三個目標是∶
1.機密性
2.完整性
3.可用性
這三個目標統稱為 C.I.A（Confidentiality， Integrity， Availability）。人們普遍認為，在軟體
開發生命週期中，開發者通過公認有效的方法對C.I.A.進行保證、增強、保護，就認為程式碼
是高可信和安全的。
資訊保安性、機密性、完整性和可用性在《44 U.S.C，Sec.3542》中的定義如下所示。
資訊保安性∶保護資訊和資訊系統，避免未經授權的訪問、使用、洩露、中斷、修改或
破壞，以確保資訊的機密性、完整性和可用性。
機密性∶ 對資訊的訪問和洩露進行限制，包括保護個人隱私和專有資訊的手段。
完整性∶ 防止不正確的資訊修改或銷燬，包括確保資訊不可抵賴性和真實性。
可用性∶ 保證資訊可以實時使用。
1.5 威脅建模和攻擊面驗證
威脅建模和攻擊面驗證也許是 SDL 中最耗時、最不易理解和困難最大的部分。它需要軟
件安全架構師———安全團隊中經驗最為豐富的專家來完成。簡而言之，威脅建模的目的是理
解系統的潛在威脅，確定風險，建立適當的應對措施（有什麼風險?風險嚴重性有多大? 如
何消除風險?）。當在專案生命週期的早期正確地進行威脅建模後，就可以在程式碼提交前發現
軟體設計的安全問題。威脅建模使問題在軟體開發生命週期的早期就得到了解決，從而節省
了大量成本。威脅建模還有助於企業管理軟體風險，並提供將技術風險轉換為業務影響的能
力。基本原則是，在軟體生命週期中越早識別和管理安全風險越好。
第2章
Core Software Security: Security t the Source
安全開發生命週期
2.1 克服軟體安全中的挑戰
如第1章所述，SDL 是軟體安全演化的關鍵步驟，有助於人們重視構建安全的軟體開發
生命週期。過去，軟體產品的利益相關者並不把軟體安全作為—項高度優先的事項。人們認
為，一個安全的網路基礎設施將會提供針對惡意攻擊所需的保護級別。然而，最近幾年，已
經證明單純的網路安全不足以防止這種攻擊。使用者已經可以通過相關技術成功滲透有效的渠
道認證，相關技術包括跨站點指令碼（Cross-Site Scripting，XSS）、結構化查詢語言（Structured
Query Language，SQL）注入和緩衝區溢位漏洞利用技術等。在這種情況下，系統資產被洩露，
資料和組織的完整性也遭到破壞。安全行業一直試圖嘗試通過應急措施來解決軟體安全問題。
首先是平臺安全（OS 安全），然後是網路/周邊安全，以及現在的應用程式安全。我們確實需
要深度防禦來保護我們的資產，但從根本上它是一個軟體安全漏洞，需要通過 SDL 方法進行
修復。
2.2 軟體安全成熟度模型
近年來，兩個非常流行的軟體安全成熟度模型已先後開發並繼續快速地成熟。 一個是
Cigital 的內建安全成熟度模型（Building Security in Maturity Model， BSIMM）m，另一個是
OWASP（Open Web Application Security Project，開放 Web 應用安全專案）的開放軟體保證成
熟度模型（Software Assurance Maturity Model， SAMM）1。BSIMM是一項面向真實軟體安全
措施的研究，幫助你確定軟體安全措施和如何組織工作時間。BSIMM是 Cigital開發的一系
列最佳實踐，分析 9個領先的軟體安全措施的真實資料，並基於成功的公共區域建立框架。
有 12個實踐組織為4個域。這些實踐都用於組織109 個BSIMM活動（BSIMM4共有111 個
活動）。
.3 ISO/IEC 27034∶ 資訊科技、安全技術、應用安全
2011 年，國際標準化組織（International Standards Organization，ISO）/國際電工委員會
（International Electrotechnical Commission，IEC）釋出 ISO/IEC27034-1∶2011中6個應用安全
標準的第 1部分。l該標準提供了一個簡潔並且國際公認的方式來獲得廠商/ 供應商軟體安
全管理流程的透明性。為了配合不同的工程組織，該標準設計具有足夠的靈活性，但為了解
決現實世界的風險，它又足夠具體。
2.4 其他 SDL最佳實踐的資源
還有其他 SDL 最佳實踐的資源，下面介紹其中幾種最流行的資源∶
2.5 關鍵工具和人才
如同所有的安全任務一樣，無論它們的方法是攻擊還是防禦、總要有成功所需的過程、
技術和人力的一個融合。迄今為止，可用於軟體安全的過程和模型已在本節中討論了。有兩
個要素∶一個是技術（工具）方面，它在軟體安全方面提供幫助或製造麻煩;另一是人力（人
才）方面。
2.6 最小特權原則
在資訊保安、電腦科學以及其他領域，最小特權原則
限制特權提升是威脅建模的重要部分，其也是 SDL 架構（A2）階段的一個核心組成部
分，這將在第 4 章討論。特權提升的概念是非常重要的，它是微軟安全開發生命週期卡片遊
戲的主題。旨在培養開發人員和安全專業人員快速、輕鬆地找到軟體或計算機系統的威脅。【5
未經授權的許可權提升攻擊利用程式錯誤或設計缺陷，賦予攻擊者訪問網路及其相關的資料和
應用程式的提升許可權。這些攻擊可以是垂直的（攻擊者賦予自已特權），或水平的（攻擊者使
用已經賦予的相同水平的特權），但假設他擁有具有相似許可權的另一個使用者的身份。
2.7 隱私
保護使用者的隱私是 SDL 過程的另一個重要組成部分，應被視為 SDLC 所有階段重要的系
統設計原則。使用者隱私安全出了問題將導致信任危機。由於在未經授權訪問的使用者越來越多
的情況下，個人資訊在媒體中公開，在軟體和系統中使得客戶的資料得到可靠保護的狀況日
益惡化。此外，許多新的隱私法律法規強調了在軟體和系統的設計和開的包含隱私的重要性。
至於安全性，已經通過的軟體開發生命週期的進度的變更是成本很高的，就是把高成本的隱
私保護方法和技術融入 SDLC的適當階段，以維護個人的隱私，並保護個人身份資訊（PII）
的資料。包含在微軟 SDL 中的一些關鍵的隱私設計原則，包括提供有關資料收集、儲存或者
共享的適當通知，使使用者可以對自己的個人資訊做出明智的決策;使使用者策略和控制可用;
最小化資料收集和敏感性; 以及儲存保護和資料傳送。【5
至關重要的是，隱私保護措施通過 SDL 實現的最佳實踐構建到了 SDLC中。忽略使用者的
隱私問題可能會導致訴訟、媒體負面報道和不信任。我們已經將隱私保護最佳實踐方案部署
到 SDL 中，這將在以後的章節中詳細敘述。
2.8 度量標準的重要性
Lord Kelvin 曾說過，"如果你不能衡量它，就不能改進它。" 【這句格言今天也是如此，
因為它適用於產品的安全性和滿足軟體開發組織的安全狀況精準度量的需求。有意義的安全
指標是至關重要的，因為企業要合作努力應對監管和風險管理要求，
2.10 軟體開發方法
本章前面已經討論了各種 SDLC 模型，並提供了SDL 模型和一般 SDLC 之間對映關係的
直觀概述。應當指出，多個軟體開發方法在各種 SDLC模型中使用。每一個軟體開發方法都
作為應用特定框架開發和維護軟體的基礎，不太關心技術方面，相反關心建立軟體過程的組
織方面。這些開發方法主要是瀑布模型、敏捷及其變種和衍生模型。瀑布模型是最古老和最
知名的軟體開發方法。瀑布模型的顯著特點是它從需求按順序循序漸進的過程。儘管它們包
括傳統和新型的軟體開發實踐的混合，但是敏捷方法在行業中越來越受歡迎。你會發現敏捷、
傳統瀑布或者兩者的混合體。我們將詳細介紹瀑布和敏捷開發模式，並選擇每一個模式對應
的一個或兩個變體用於介紹軟體開發方法。鑑於存在的模型數量，對於 SDL 模型不僅有一個
通用模型，還將按第 9章的具體介紹進行操作。第 9 章描述了 SDL 模型應用到一些最流行的
軟體開發模型中，這些模型你可能會在未來幾年接觸到。
第3章
Core Software Security; Scurity t the Source.
安全評估（A1）∶ SDL 活動與最佳實踐
.1 軟體安全團隊提早參與專案
SDLC 通常有正式的啟動會議，把軟體安全團隊包括在內是非常重要的，以確保安全是
SDLC 的重要元素，並內置於整個過程。現場會議或網路會議給了與會者和利益相關者來大
致認識和了解的重要機會。
3.2 軟體安全團隊主持發現會議
發現會議基本上是一個 SDL啟動會議，在會上關鍵的 SDLC 利益相關者在過程開始時聚
在一起，使安全成為內建的而不是附加的。在發現會議安全規劃中應包括籌備整個系統生命
週期，包括關鍵安全里程碑和可交付成果以及工具和技術的鑑定。特別應考慮到可能需要進
行採購的專案，比如軟體安全性測試和評估工具，以及第三方軟體安全架構師或工程師潛在
的使用可能，（如果需要擴充員工或有客戶要求第三方認證）。其他資源的影響，如主動測試、
認證以及所需的培訓，必須加以考慮。
.3 軟體安全團隊建立 SDL專案計劃
這實際上可以被認為是最初的專案規劃，因為正式的計劃將作為設計階段的成果呈現，
這將在下一章描述。
3.4 隱私影響評估計劃啟動
有許多隱私保護和管理方法。然而，在過去，隱私保護工具是普遍以自組織的方式應用
的，或者是以零碎的方式解決眼前的問題;通常在這些問題解決後釋出。正如安全性，在系
統設計時把隱私作為次要的考慮因素，或者把它作為一個未來探討的問題處理，並不能提供
有效的隱私保護。只考慮解決隱私問題的元件，而不是通過一個全面的設計和實施將導致進
一步的潛在隱私問題。隱私必須是一個基本的設計因素，它要整合到 SDLC 的各個階段。
3.5 安全評估（A1）成功的關鍵因素和度量標準
3.5.1 成功的關鍵因素
設定成功的標準在 SDL 的任何階段都會使其更有效，並有助於在事後瞭解什麼工作有幫
助而什麼沒有。表3-1列出了作者認為成功的標準。然而，每個環境都是不同的，安全團隊
都需要在自己的環境中理解成功的標準。
.5.2 可交付成果
在每一個 SDL 階段，我們將概述該階段可交付成果的關鍵集。這樣做是為了確保所有必
需的活動有一個有形的記錄結果。我們常常看到建立並儲存一個專案管理團隊只是口頭或非
官方的檔案。我們認為，正式檔案應建立並儲存在一箇中央儲存庫，並且有適當的簽名和版
本控制。
第4章|
Core oftware Securty: Securty t the Source
架構（A2）∶ SDL 活動與最佳實踐
4.1 A2 策略一致性分析
軟體的安全策略的目的是確定哪些需要加以保護以及它如何受到保護，包括審查和結合
SDL 外可能會影響開發程序的策略。這些措施可能包括治理軟體或開發或應用在組織中的任
何地方的策略。在這個階段，SDL 的策略域外存在的任何策略都將被審閱。企業安全與隱私
策略可能會指示設計和開發人員必須有什麼樣的安全和隱私功能及它們該如何實現。其他策
略可能包括那些支配使用第三方和開源軟體或組織內部和外部的保障與控制原始碼以及其他
智慧財產權。
4.2 SDL 策略評估和範圍界定
SDL 還提供了一個非常寶貴的指南為軟體開發人員設定其組織的安全標準，應該提供一
個實現路線圖而無需中斷生產高質量軟體應用的核心業務。除非開發組織和管理團隊的高層
領導支援這種模式，否則 SDL 可能會失敗。它必須由簽訂、出臺的政策來驅動，並最好由
CEO 和軟體開發管理團隊提供支援。一個組織本應該有一個書面的和可重複的 SDL 的策略與
方針，以支援 SDLC，其中包括其業務需求，並作為它支援的工程和開發文化的補充。該組
織的文化和成熟度在 SDL 策略的制定中是非常重要的，這樣可以確保它會同時實現可行性和
實用性。管理風格、人員、流程和技術需求（包括產品的整體架構）的複雜性，將有助於確定
怎樣的粒狀或目標來作為重點指導方針。外包開發量，如果有的話，也需要作為這個過程的
一部分被評估。一個內部的開發團隊需要更詳細的程式，而一個外包功能將需要更多的合同
物件、服務水平，以及詳細的可交付物。這些漏洞以及利用外包資源開發的風險將在本書後
面討論。
4.3 威脅建模/ 架構安全性分析
4.3.1 威脅建模
如前所述，威脅建模需要一套特殊的技能、經驗和心態∶團隊內的人不論是誰做這個一
定要像對手一樣思考。資深軟體安全架構師或更豐富的軟體安全冠軍之一通常深諳這個方面。
參與這個過程的開發者或團隊成員不僅必須要懂得怎樣開發軟體，而且要了解如何解構或拆
卸軟體及其架構，同時像對手一樣思考。
微軟首次於1999 年記載了威脅建模方法，自那時以來，它的方法已經發展成為一個行業
標準'。當然，這不是微軟第一次由人來威脅建模，而是第一次將方法形式化或視為一個抽象
的工程活動。
潛在損害
低（值=1）∶洩露瑣碎的資訊。
中（值=2）∶洩露敏感資訊。
高（值=3）∶攻擊者可以顛覆安全體系;得到充分信任的授權;以管理員身份執行;上傳
內容。
可重複性
低（值=1）∶這種攻擊是非常難以再現的，即使有安全漏洞的知識。
中（值=2）∶該攻擊可以重複，但只有一個計時視窗和一個特定的競爭情況。
高（值=3 ）∶該攻擊每次都可重複，並不需要一個計時視窗。
可利用性
低（值=1）∶攻擊需要一個非常熟練技能的人，並深入瞭解每一次可以利用漏洞攻擊
的知識。
中（值=2）∶一個熟練的程式設計師就可以攻擊，然後重複上述步驟。
高（值=3 ）∶一個初學者在很短的時間內就可以攻擊。
受影響的使用者
低（值=1）∶ 很小比例的使用者，模糊的功能;影響匿名使用者。
中（值=2）∶一些使用者，非預設配置。
高（值=3）∶ 所有使用者，預設配置，重點客戶。
可發現性
低（值=1）∶ 這個 bug 是模糊的，而使用者是不可能計算出潛在損害的。
中（值=2）∶ 該漏洞位於產品中一個很少使用的部分，只有少數使用者會碰到它。這需要一
些思考，看看是否有人惡意使用。
Web 應用程式安全框架分類和評估問題【12】
·輸入和資料驗證
你怎麼知道應用程式接收的輸入是有效和安全的?輸入驗證是指額外的處理之前，應用
程式如何過濾、清潔或拒絕輸入。考慮通過入口點限制輸入，並通過出口點編碼輸出。你是
否信任你的資料來源，如資料庫和檔案共享資料?
·身份驗證
你是誰?身份驗證是一個實體證明另一個實體的身份的過程，通常通過證書來實現，例
如使用者名稱和密碼。
·授權
你能做些什麼?授權是應用程式的資源和操作是如何提供訪問控制的。
·配置管理
應用程式以什麼身份執行? 它連線到哪個資料庫?應用程式是如何管理的? 這些設定如
何保證安全?配置管理是指應用程式如何處理這些業務問題。
·敏感資料
應用程式如何處理敏感資料? 敏感資料是指應用程式如何處理必須加以保護的資料，不
論是在記憶體中，在網路上，還是在永續性儲存中。
·會話管理
應用程式如何處理和保護使用者會話? 會話是使用者和 Web 應用程式之間的一系列關聯互動。
·加密
如何保持機密（保密性）? 如何防止篡改資料或資料庫的（完整性）? 對於必須強加密的
隨機值如何提供種子?加密是指應用程式如何強制執行機密性和完整性。
·異常管理
在應用程式中，當一個方法呼叫失敗時，應用程式是怎麼做的呢? 你透露了多少? 你向
終端使用者返回友好的錯誤資訊了嗎?你把有價值的異常資訊傳遞迴呼叫者了嗎?應用程式優
雅地出現故障
4.4 開源選擇
目前軟體行業有日益增加的趨勢，在過去幾年中開源軟體和專有軟體以最低的成本提供
最高價值的服務。兩者的融合稱為"混源"，這已經成為行業的主導做法。因為開源成為軟體
開發領域越來越大的部分，所以瞭解和管理軟體資產的授權將是至關重要的，但是這超出了
我們的討論範圍，這將會被別的軟體開發團隊處理。
4.5 隱私資訊收集和分析
考慮到系統是否能夠傳輸、儲存、建立隱私資訊在 SDLC早期是很重要的。資訊收集、
辨識以及規劃實施適當的保障措施和安全控制（包括解決隱私資訊事件處理和報告需求的流
程）都是在這個階段決定的。SDL 的這個階段就是對隱私影響評估（PIA）的資訊收集和分析
的開始。分析階段決定了PII將如何處理，以確保其符合有關隱私的法律、法規和政策規定;
軟體和開發的整個系統中，收集、維護、以可識別的形式傳播隱私資訊的風險和影響，或在
雲或 SaaS 環境中與它交接的風險和影響。檢查和評估保護和處理用於減輕潛在的隱私風險的
資訊的替代過程。
4.6 成功的關鍵因素和度量標準
4.6.1 成功的關鍵因素
SDL 第二階段的成功取決於 SDLC 如何同步識別威脅、要求，約束功能和整合，以及減
輕風險。第二階段的關鍵成功因素見表4-1。
表 4-1 關鍵成功因素
描 述
關鍵成功因素
1.確定業務需求和風險
按 CIA 定義的業務需求和風險的對映
識別軟體威脅
\2. 有效的威脅建模
\3. 有效的架構威脅分析
分析軟體威脅和威脅出現的概率
4.有效的風險緩解策略
每二個業務需求的風險接受、容忍和緩解計劃
\5. DFD的準確度
威脅建模中使用的資料流圖
成功因素 1∶確定業務需求和風險
在這個階段，關鍵的利益相關者，包括軟體安全團隊明確了業務風險和要求。業務需求
通過資訊保安的 CIA 支柱定義。成功 SDL 週期的當務之急是，儘可能確定所有的要求並日捕
獲需求。
成功因素 2∶有效的威脅建模
有效的威脅建模中是—個複雜和艱鉅的任務。威脅建模的整個風險緩解計劃取決幹這個
任務。威脅模型的任何間隙會導致軟體和/或部署中缺乏有效的安全控制。
|第5章
Core Sofware Security: Security at the Source
設計和開發（A3 ）∶ SDL 活動與最佳實踐
5.1 A3 策略一致性分析
如第 4 章所述，A3 的策略一致性分析是對 A2 策略一致性分析的延續。在這個階段，會
對 SDL 域外部的所有策略進行評估。這是為了保證公司外部的開發機構在軟體開發過程中遵
守公司內部的安全和隱私需求以及開發指南。公司的安全和隱私策略會對需要達到的安全和
隱私特徵進行描述，並指導設計人員和開發人員如何實現這些特徵。其他策略可能針對公司
內部或公司外部在軟體中使用的第三方或開源軟體的管理，控制原始碼以及其他智力成果。
假如軟體安全組是與集中的資訊保安組是分開的，那麼兩個組都要基於所有的原則和策略進
行協作是很重要的，包括開發、版本釋出後的安全支援以及產品的反饋。同樣重要的是在隱
私功能上的合作，無論是集中式組還是外部法律決策。
5.2 安全測試計劃構成
測試活動用來驗證產品釋出後的安全措施是否能有效降低客戶或惡意使用者發現安全問題
的可能。軟體通過安全測試、工件（artifact）、報告和工具對軟體的安全性進行驗證。我們的
目的不是為了證明產品不安全，而是在產品提供給客戶前保證軟體的健壯性和安全性。這些
安全測試方法確實能發現安全 bug，尤其是在那些沒有經歷關鍵的安全開發流程變更的產品
中。安全測試和評估的結果也可能在安全控制中發現缺陷，安全控制用於保護正在開發的軟
件。因此需要制定詳細的行動計劃和里程碑進度，以記錄計劃的整改措施，進而增強安全控
制的有效性，並在軟體釋出之前提供必要的安全措施。
●定義測試指令碼。指令碼是非常詳細且包括測試邏輯步驟的指令集，用於告訴測試人員或
測試工具在測試期間做什麼。功能測試指令碼是一步一步的指令，描繪了一個特定的場
景或情景，包括將會遇到的情況和預期的結果。安全測試指令碼是專門用於測試應用程
序安全性的指令碼。這些指令碼的依據來源於在設計階段生成的威脅模型。誤用用例定義
那些需要保護（資源），什麼型別的攻擊可以訪問這些資源。安全測試指令碼定義了執行
這些攻擊的行為。
●定義使用者社群。定義使用者社群幫助測試人員識別錯誤和風險的可接受程度。
●識別專案障礙物。用例中需要定義必備的和"如果可用"的情景。如果沒有定義，就
需要重新審視測試需求，從而使這些規範文件化。
●識別內部資源。內部資源來自於公司的組織，包括開發商、分析師、軟體工具，有時
還可能有專案經理。
●識別外部資源。外部資源是為了測試應用系統和提交報告而臨時加入專案的人員或工
具。外部資源最適合安全測試，因為他們一般都在安全程式設計技術方面受過嚴格的訓練，
同時他們遠離程式碼和任何內部策略。如果需要外部資源，測試計劃需要回答以下問題;
（1）他們測試什麼?（2）他們的報告提交給誰?（3）他們與誰一起工作? P
我們將軟體的安全屬性和行為劃分為外部實體的和內部實體的∶外部實體包括使用者、環
境和其他軟體; 內部實體包括軟體自身有互動行為並且作為主要測試物件的內部元件。具體
來說，應該驗證軟體以下的屬性和行為∶
●它的行為是可預測和安全的。
●它不暴露漏洞或者缺陷。
5.3 威脅模型更新
在通過第 4 章介紹威脅模型構建過程之後，知道構建過程何時完畢是很重要的。需要回
答以下幾個問題，答案可能取決於商業競爭與安全風險之間的取捨。
\1. 你開發的軟體是否能符合所有相關政策、法規、條例的規定?並且對於每個需求獲得
各個層次的批准?
2.所有的利益相關方是否對威脅建模過程中識別出的安全和風險進行了檢查?相關的架構
師、開發人員、測試人員、專案經理以及其他所有了解軟體的人員都應為威脅模型構建做出責
獻並進行核查。為了保證威脅模型覆蓋全面，應廣泛徵求各方意見。所有相關人員在威脅和風
險的認識上達成一致是很重要的。否則，針對威脅模型實現相關措施的落實會面臨很多困難。
\3. 你是否就建立威脅模型和針對威脅模型採取的應對措施、測試所需的時間和資源與相
關方達成一致?
\4. 你對風險和威脅的排名是否與相關人員達成了共識?如果你是一個軟體購買者，是否
會同意這個排名?
5.4 設計安全性分析和檢查
在 1974年的一篇文章中，來自弗吉尼亞大學的 Saltzer 和 Schroeder，提供了通過保護存
儲資訊所需的軟體和硬體來保護資訊的方法。14文章提出了以下 11 個安全設計原則。
\1. 最小許可權。最小許可權原則主張，對於完成一項任務的個人、程序或其他實體，只在可
完成該任務的最短時間內分配給該實體能夠完成該任務的最小許可權和資源。這種方法避免了
未經授權訪問敏感資訊的情況。
\2. 職責分離。該原則要求，必須滿足多個條件，
5.5 隱私實現評估
筆者認為，最簡潔、清晰並且經過現場檢驗的軟體開發隱私措施評估現場測試流程、指
南來自微軟的三篇重要的文件。
1.開發軟體產品和服務的微軟隱私指南，版本 3.1;2008年9月（Microsof's Privacy
Guidelines for Developing Sofware Products and Services, Version 3.1;September 2008)I
2.微軟 MSDN的 SDL——過程指南——附錄C;SDL 隱私問卷調查（Microasof MSDNs
SDL—Process Guidance—Appendix C: SDL Privacy Questionnaire)l1]
3.微軟 SDL的簡單實現（Microsofts SimplijhedImplementarion ofthe Microsof SDL）1
要確定隱私影響等級以及評估相關工作的流程和指南，請參考"開發軟體產品和服務的
微軟隱私指南"，版本 3.1;2008年9月P和"微軟 MSDN 的 SDL——過程指南——附錄C∶
SDL 隱私問卷調查"P。評級（P1、P2 或 P3）從隱私的角度表現了軟體的風險等級。你只需
要按照指南的步驟就可以完成評估。
·P1∶高階隱私風險。特徵、產品或服務對個人身份鑑別資訊（personally identifiable
information， PI）進行儲存或傳輸，更改相關的配置或檔案型別，或安裝軟體。
●P2; 中級隱私風險。影響特徵、產品或服務的隱私的獨立行為是一次性的、使用者發起
的、匿名資料傳輸的（如，使用者點選—個連結軟體就跳轉到—個外部網站）。
·P3; 低階隱私風險。特徵、產品或服務內部沒有影響隱私的行為。不傳輸匿名或個人
資料，不儲存 PII，沒有配置改變使用者的利益，不安裝軟體
第6 章
Core Software Security; Security at the Souree
設計和開發（A4 ）∶ SDL 活動與最佳實踐
6.1 A4 策略一致性分析
這部分工作是之前章節所講的 A3 策略依賴檢查的延續。我們會在不同階段重複地做策略
分析和檢查工作。策略依賴分析是最為重要的工作，你要堅持通過實際的工作檢查之前的迭
代是否覆蓋了所有策略，而不是通過假設。在這個步驟中，你會驚奇地發現之前的階段和迭
代中會遺漏多少東西。
在這個階段，任何存在於 SDL 域之外的策略都要被檢查（或重新檢查）。這些策略可能包
含當在組織中開發軟體或應用時來自開發組織之外的策略，這些組織維護要遵守的安全與隱
私需求以及指導方針。在開發過程中策略更新以及需求增加也是經常發生的事。因此你最好
能夠對照策略更新列表並確認策略中已經包含了新的需求。
6.2 安全測試用例執行
安全測試是一個耗時的過程，需要適當的準備，確保前後一致，並協調所有利益相關方，
以及對什麼是真正測試內容的深刻理解。安全測試很早就開始，並貫穿整個 SDLC過程。安
全測試方法不同於其他形式的測試，因為安全測試的目的是確認軟體設計中由於不合理的設
計或程式碼編寫問題而暴露的各種安全漏洞。本書的前提是確保原始碼的安全，通過這個層面
的測試，軟體能夠防止許多隻能在網路層面才會暴露的典型安全問題。安全，特別是在設計
層面的安全分析，能夠幫助我們在程式成為大型系統的一部分並且需要高昂的修復代價之前，
發現潛在的安全問題和可能造成的影響。軟體安全是一個動態的風險管理過程，需要平衡修
復安全問題的花費，以對抗攻擊者擁有的技術與資源———直會有聰明的攻擊者把精力投入
在挖掘你軟體的安全漏洞並對軟體造成破壞上。因此，安全測試必須基於利用漏洞以及可能
造成的相關的安全風險評估每個事件的發生概率。
6.3 SDLC/SDL過程中的程式碼審查
程式碼審查對於發現軟體開發過程中的安全缺陷非常有效。適當地執行程式碼審查對於程式碼
安全起到的效果甚至比所有其他活動加起來還要多。程式碼審查可以讓你在程式碼測試或安裝之
前就找到和修復大量安全問題。有 4種分析軟體應用安全性的基本技術∶自動掃描、人工滲
透測試、靜態分析，以及人工程式碼審查。當然，所有這些方法都有各自的優點、缺點、擅長
的方面，以及無法勝任的方面。
6.4 安全分析工具
程式碼安全審查的最終目的是提升產品整體的安全性，使開發組提升安全開發的能力從而
減少程式碼中犯的錯誤。本節討論各種測試方法在整個過程中的功能和角色的細節，包括靜態
分析、動態分析、模糊測試以及人工程式碼檢查。但是在開始前，我們需要認識到每種方法都
有各自的優點和侷限性。
程式碼靜態分析的優點
\1. 使用現有的命令可以使軟體執行
●不需要猜測和解釋行為。
●能夠產生所有軟體可能產生的行為。
\2. 能夠找到程式碼缺陷的精確位置。
3.能夠被培訓過的完全理解程式碼的軟體保障開發人員使用。
\4. 允許快速修復發現的問題。
.4.1 靜態分析
靜態程式分析是在計算機軟體實際上不執行的情況下進行的測試。靜態分析主要用在某
一版本程式原始碼的分析上，它也會用在物件程式碼上。相比較，動態分析實際上是在軟體程
序執行後進行測試的。靜態分析是使用自動化工具進行測試的，不要與人工分析或軟體安全
架構檢查混淆，後者一般包括人工程式碼審查，需要對程式有一定理解。當靜態分析使用得當
時，它相比人工靜態分析的顯著優勢就會顯現出來，它可以使用比開發者更多的安全知識更
頻繁地進行測試。而當確實需要時再使用專業的安全架構師或工程師。
.5 成功的關鍵因素
SDL 第 4 階段的成功依賴於遵從策略，執行安全測試用例，完成不同型別的安全測試，
以及驗證隱私需求。表 6-1 列出了這個階段成功的關鍵成功因素。
表 6-1 關鍵成功因素
描 述
關鍵成功因素
覆蓋所有相關的測試用例
\1. 安全測試用例執行
完成所有型別的安全測試，修復找到的問題
2.安全測試
\3. 隱私驗證和修復
隱私相關控制的有效性，修復找到的問題
按照階段 4更新策略
4.策略合規性檢查
成功因素1∶ 安全測試用例執行
6.2 節提到了安全測試執行計劃成功的標準。
成功因素 2∶安全測試
完成所有型別的安全測試——人工程式碼審查、靜態分析、動態分析、滲透測試和模糊測
試———是很關鍵的。
第7 章
Core Software Security: Security at the Source
釋出（A5）∶ SDL 活動與最佳實踐
.1 A5 策略一致性分析
就像 SDL 的階段（A1）～（A4）討論的那樣，SDL 策略一致性覆蓋了所有有價值的安全
和隱私風險，並且在每個階段都進行分析與更新以覆蓋新的威脅和活動。特別是，策略中的
活動和標準已經在每個 SDL 階段更新，從安全事件根本原因的分析中學習合併的課程，適應
改變的威脅環境，促進工具與技術升級。在隨後的階段，跟蹤 SDL 策略的遵守情況，如果需
要也會跟蹤有高風險問題的專案。從 SDL 的開始階段，正式定義需要遵守的 SDL 專案質量
授權和需求。這個策略變成了管理 SDL 過程的重要部分，包括∶
●歸入標準化 SDL 授權和活動的專案型別
●定義每個 SDL/SDLC 專案階段必須遵守的策略和過程
●設定版本釋出必須滿足的需求
在最後的策略一致性分析中，需要對策略進行檢查從而保證可以支援基於不同開發標準，
如產品型別、程式碼型別和平臺的特殊需求
.2 漏洞掃描
儘管現在沒有人工審查原始碼的替代方法，但是自動化工具依舊有著節省時間和資源的
優勢。安全漏洞掃描特別適合用於執行這個過程的迴歸測試，作為雙重檢查任何可能的安全
漏洞，檢查因為不注意將之前已經確定並修復的安全漏洞又重新引人程式碼。也有這樣的可能，
即其他簡單功能的產品在 SDL 的開始階段有了已經披露的安全漏洞，這些也能夠在最後的安
全審查中發現。軟體產品一般包含 5000 行甚至更多的程式碼，安全漏洞掃描可以作為價效比
高的、節省時間的方法做最後的 SDL 檢查。這些掃描器能夠執行大規模的複雜資料流分析從
而確定人工審查過程中遺漏的安全漏洞點。這些產品通過編譯程式碼庫來分析每條可能路徑以
找到根源級別漏洞，比起人工審查更快更高效。它們也是很好的"檢查檢查者"工具，即對
軟體安全架構師已經進行過人工審查的程式進行審查。
7.3 滲透測試
滲透測試是模擬黑客行為對軟體系統進行的白盒安全分析，以發現由程式碼錯誤導致的
潛在安全漏洞、系統配置錯誤或其他操作環境下的部署缺陷。滲透測試也會用來驗證程式碼
是否按照預期設計實現，驗證是否實現了安全功能，並發現可利用的安全漏洞。白盒測試
需要了解系統是怎樣實現的，從而確保軟體產品的健壯性，以對抗預期和非預期
7.4 開源許可審查
儘管開源軟體是免費的、創新的、高效的，並且使得軟體產品富有競爭力，但是它也必
須按照資產進行管理，遵守許可證，必須像內部開發軟體標準一樣滿足安全需求。有時這些
獨特和複雜的許可可以延期，並防止釋出過程中不適當管理導致的潛在商業風險。遵守開源
要求是很重要的，能避免花費很多金錢和時間的起訴。當產品的一部分使用了開源軟體時，
在 SDL 中管理許可的遵守和安全性上，有兩個主要的部分需要關注。
1.開源軟體協議的遵守。不遵守開源軟體許可要求會導致價格高昂和耗時的起訴，
開庭時間，侵犯版權，媒體披露，不良的公眾形象，不遵守許可會帶來風險和消極的商
業關係。不當的管理和不遵守開源許可也會導致無法對軟體產品提供支援，版本釋出延
期或停滯。
2.開源軟體安全性。SDL、開發團隊以及投資者需要意識到並理解與開源軟體程式碼相關
的安全漏洞會在他們的產品中出現。就像自己開發軟體一樣，所有開源軟體已知的安全漏洞
以及在安全社群公佈的安全漏洞必須在 SDL 過程中使用相同的威脅模型進行確認，評估以及
修復，架構性的安全和隱私審查，風險評估。
第8 章
Core Software Scurity: Security t the Source
釋出後支援（PRSA1～ 5）
8.1 合理調整軟體安全組
首先，我們需要把握每個安全組之間的關係，以及它們對於構建成功的軟體安全程式的
重要性。這樣做意味著∶
●正確的組織定位
·正確的人
·正確的過程
8.1.1 正確的組織定位
儘管在過去幾年裡軟體安全技術已取得了巨大的進步，但是我們依然堅信人是一個成功
的軟體安全程式中最重要的因素，其中包括活動和最佳實踐的實施和管理。為了讓負責軟體
安全的人人盡其用，他們一定是正確的組織的一部分（見圖 8-2）。據報道，本書合著者之一，
James Ransome先生曾經擔任過七個首席安全官（Chief Security Officer， CSO）和首席資訊安
全官（Chief Information Security Oficer，CISO）。基於他的工作經驗和與業內同行的交流，很
顯然，軟體安全功能在理想情況下應該屬於工程（軟體開發）功能，尤其是質量功能。普遍的
共識是，應用程式安全任職人員通常報告給中心資訊保安負責人（CSO/CISO），不能混淆軟體
安全功能。通常情況下，那些在 IT安全團隊中擔任應用程式安全職位的人，善於使用工具進
行測試，但缺乏必要的軟體開發背景來充分解釋執行結果。為了搞清楚這一點，區分軟體和
應用程式安全是至關重要的。也許明晰這種區別的最好方法就是引用 Gary McGraw 的說明∶
.1.2 正確的人
第2 章討論了為了使 SDL 模型成功所需要的人員配置。這包括至少一個主要的軟體安全
架構師，幾個高階和一般的軟體安全架構師，理想情況下，在每個軟體產品的安全組中，至
少擁有一個軟體安全架構師。這種關係如圖 8-3 所示。這樣的人員配置提供了擴充套件的能力，
在每1級軟體產品的每個工程軟體產品開發小組中將有理想的一款軟體安全冠軍（Software
Security Champion，SSC）。人才的另一個要素是組織中的軟體產品傳道者（Software Security
Evangelist，SSE），即組織大到足以有額外的候選人扮演 SSC 的角色，他們在成為 SSC 之前作
為SSE 的候選人存在。SSE 有兩個角色，一個是訓練中的 SSC，另一個作為傳道者的整體軟
件產品安全程式出臺政策、執行政策，以及傳道整體的 SDL 流程。
8.1.3 正確的過程
正確的過程就是到目前為止本書描述的和圖 8-4 總結的核心 SDL 活動與最佳實踐。除
了核心活動和最佳實踐外，我們在圖 8-1中高亮顯示了活動和最佳實踐。迫於壓力，大多數
的公司都要求用最少的資源做最多的事，我估計大多數公司都不會奢侈地將 PRSA 1～5 的
大多數元素作為單獨的組織，而是創新性地將其納入整個軟體的安全方案中，以實現現有
資源的優化利用。
.2 PRSA1∶ 外部漏洞披露響應
產品釋出後的管理關鍵是要建立產品安全事件響應小組（Product Security Incident
Response Team，PSIRT），並與我們推薦的機構在產品釋出後發現安全與隱私問題時共同承擔
責任。無論你的軟體在安全方面和相關的 SDL方面做得多麼好，都會忽略一些問題，因此你
需要做一個計劃以對此作出迴應。重要的是，如果在軟體釋出後經常發現軟體安全漏洞和隱
私問題，就說明通過類 SDL 的過程將"安全"構建到 SDLC中的做法是有缺陷的。這樣的缺
陷會導致各種問題∶釋出後軟體存在的漏洞被披露和利用，從而破壞公司名譽;產品名譽的
破壞導致市場份額的損失; 合同違約或被訴訟，等等。
8.6 PRSA5∶ 安全架構審查和基於工具評估當前、遺留以及併購的產品和解
決方案
8.6.1 遺留程式碼
雖然它們可能曾經被視為不必要的成本負擔，但是我們在 SDL 中強調的最佳活動和最佳
實踐是發現後的結果，即安全並不總是軟體開發過程中的關鍵因素，有時會導致安全漏洞，
以及與待開發軟體的初始成本相媲美的風險緩解成本。遺留程式碼的驗收基於所預期發生的假
設，即必須證明該軟體在功能上是正確的、在操作上是可行的。然而，當涉及軟體安全時，
意想不到的事通常會導致漏洞。這些安全漏洞不僅在費用上是不可接受的，而且從操作性、
功能性和整體風險的角度來看也是不能被接受的。當該軟體支援嵌入式關鍵系統和應用程式
時這一點特別真實，如在國家和地區基礎設施、交通運輸、國防、醫藥和金融中發現的安全
漏洞。在這些應用中，與意想不到的安全軟體和系統漏洞相關的責任、成本、使命和業務影
響，被認為是不可接受的。除了遺留軟體的架構可以被正確評估，並從安全形度分析，否則
變化的影響無法預測，也不能更有效地應用。這就是為什麼在 SDL 中隨後的同樣測試和嚴格
審查必須在遺留程式碼審查中隨後進行∶作為減輕意想不到錯誤的手段。如果按照合適的流程
嚴謹來做，這將在確保安全的程式碼實現方面意義深遠，這在遺留和新的程式碼之間是一致的。
8.7 成功的關鍵因素
外部漏洞資訊披露響應過程
在 SDL 週期的釋出後階段，擁有一個明確定義和記錄的外部漏洞資訊披露響應過程是至關
重要的。利益相關者應該明確，職責分配和責任分配矩陣（可靠的、負責任的、可諮詢的和知
情的（Responsible，Accountable，Consulted， and Informed，RACI）矩陣）應建立。更重要的是，只
有一支團隊應有責任與客戶洽談漏洞和修復。所有其他團隊和利益相關者應該與團隊一起工作，
並確保沒有其他溝通途徑或者任何資訊選擇性地披露給客戶。通常情況下，大客戶或者企業客
戶會被給予優惠待遇，並獲知中小規模企業無法得到的資訊。這不是一個良好的安全習慣。漏
洞資訊或者全部透露給大家，或者全部都不透露。選擇性的披露不是一個好主意，喜歡與客戶
玩保密，在某些情況下可能是非法的或影響什麼是對於所有客戶來說是公平和公正的待遇。
第9章
Core Software Security: Security at the Source
將 SDL 框架應用到現實世界中
9.2 安全地構建軟體
在安全軟體開發的核心，有三個關鍵的活動。圖 9-2描述了在敏捷和瀑布開發中的這三
個關鍵活動及它們的關係。每一個程式設計師必須嘗試編寫安全的、防禦性的和自我保護的程式碼。
對於程式設計師來說，不需要安全路徑也可以理解以他們使用的程式語言必須做些什麼。不同的
程式語言和不同的執行環境需求的側重點不同。實際上，某一種程式語言存在的問題對於另
一種語言可能不值得考慮;程式設計師僅僅需要了解 C/C++ 和 Java 之間的區別即可理解這個事實。
C/C++語言允許記憶體的誤處理，事實上，程式設計師非常容易做一些不安全的操作。相反，Java
語言負責所有的記憶體處理，程式設計師不再需要擔心記憶體的分配和回收。
作時會產生副作用（可以被利用）;漏洞是 bug。最終安全從業人員必須評估風險，這是漏
洞的一部分，它是一個自然的職業。但是，開發人員不關注漏洞。他們只關注正確性。演算法
寫得正確嗎?這段程式碼實現的規範準確嗎?這段邏輯生成正確的路徑嗎?這段程式碼對於之前
從未見過它的人足夠清晰嗎?這段程式碼拒絕無效輸入嗎?這段程式碼會崩潰嗎?崩潰的專案可
以恢復嗎?這些型別的問題使開發人員思考。漏洞通常是錯誤的副產品，通常不是錯誤本身。
9.5 測試
設計和編寫軟體是一門創造性和創新性的藝術，並且也包含相當多的自律性。當嘗試寫
出有安全保障的無漏洞程式碼時，創造性和自律性之間的矛盾是尤其真實的。錯誤是無可避免
的。
SDL 的安全性測試方法的徹底性是關鍵，測試是 SDL 縱深防禦的關鍵所在。測試方法必
須重疊。由於沒有一種測試方法可以滿足所有要求的安全保證，所以用彼此重疊的方法來幫
助確保完備性和對所有程式碼以及會蠕變的漏洞型別進行包裝。圖 9-11 描述了 SDL 中測試方法
的高層次型別。根據經驗，測試方法也是有缺陷的並且可用的工具遠遠說不上完美。不把安
全保證這些"雞蛋"放在一個籃子裡是很重要的。
9.5.3 攻擊和滲透測試
攻擊和滲透測試（A&P）—般是由像最熟練的攻擊者一樣的測試人員完成的。這些測試人
員會偵查目標系統，識別攻擊表面。同時這些測試人員將利用那些專家級的攻擊者常用的工
具去識別那些明顯的錯誤以及隱藏在系統中的微妙的邏輯錯誤。相比較而言，邏輯錯誤是最
難以辨別的。所有錯誤（除了最簡單的邏輯錯誤）都需要人去識別。
第10章
Core Software Security: Security at the Source
整合∶ 應用 SDL 防止現實的威脅
0.1 戰略、戰術和特定於使用者的軟體攻擊
既然我們已經描述了安全軟體的開發實踐，重要的是在這本書末尾，提醒讀者使用這些
實踐的重要性，以防止今天的網路攻擊。在引用幾個行業領導者的話之後，對於以基線保護
為核心的安全軟體開發實踐，我們將給出這種網路威脅的一個深度概述。
10.1.1 戰略攻擊
通常情況下，戰略軟體的目標是對於政府、經濟和社會必不可少的基礎設施功能的應用
程式。關鍵基礎設施的元件包括高速公路、機場與飛機、火車與鐵路、公交系統、船舶、運
輸系統，基礎物資發電廠、電力線的供應網路，以及各種油氣管道和設施，這其中又包括供
水和排汙系統、土地和手機系統、計算機網路、電視和電臺（不僅僅是公開的，還有在特殊
網路中或特殊頻率下被私人或政府實體控制的）、銀行和其他金融機構、安全、消防、醫院，
以及應急服務機構。這些關鍵基礎設施的每個組成元素都必不可少，即使是暫時地停止工作，
也會對整個國家造成巨大的影響。即使某一個領域的基礎設施受到威脅，其結果也是災難性
的。這其中包括電信、能源、交通、供水系統和應急服務系統。當然，戰略攻擊也包括對於
政府部門必不可少的部分，包括國防、情報機構和其他被競爭對手認為具有極高價值的機構。
0.1.2 戰術攻擊
網路戰術威脅通常非常精確並且在技術上很複雜，同時有高度精確的目標。考慮到這種
攻擊戰術的特殊本質，開發成本相當高。與戰略攻擊相比，戰術攻擊的重要性有所降低。在
一些情況下，戰術攻擊可以用於增強攻擊力或增強其他活動，如軍事戰役或者其他特殊利益
行動小組的一個補充活動。考慮到戰術攻擊的精確性，它也可以應用到一系列的破壞活動中。
鑑於戰術攻擊的成本，它們通常由資金充足的私人實體和政府提供資助，這些資助者往往是
全球性受歡迎的國家、企業或特殊利益集團。
10.1.3 特定於使用者的攻擊
指定於使用者的網路威脅本質上可以是戰略性的，戰術性的，或者針對個人，針對個人設
備（要麼是消費性的要麼企業所有的）。使用戰略、戰術或公開可用的方法來利用特定的個人
或者金融、政治、私人利益的一般使用者，將它們作為特定的目標，或作為到達另一個目標的
一種手段，或使用者隨機破解的目標。
在許多方面，絕大多數的戰略和戰術
10.2 應用適當設計、管理和集中的 SDL 克服組織與業務挑戰
我們概述了一個帶有相關角色和責任的組織架構，這些角色和責任特定於在 SDL 模型裡
概述的任務，本書的作者已經實地檢驗和優化了這些任務。本書先前描述的結構能夠有效地
建立，實現和控制本書中的最佳範例，同時它也能夠通過 SDL 模型中的 A1～ A5 來實現成
功的買進和任務的管理。