軟件開發過程中的信息安全管理

張萍 田闖 李衛

隨著互聯網和大數據的不斷發展，信息化在社會各行業逐漸嶄露頭角，信息安全日漸引起人們的重視。而作為信息化實現的中堅力——軟件開發，如何做好軟件開發過程中的信息安全管理，從而使得開發出的信息化產品更有安全保障，也是信息安全管理中非常重要的一個環節。

一、軟件安全問題的產生

軟件安全問題產生的原因是什么？有的是因為開發者缺乏安全開發的動機，有的則是因為開發者缺乏相關知識，還有的是因為缺乏與安全開發的相關工具。

軟件開發的信息安全管理實現思路是通過在軟件開發生命周期各階段采取必要的、相適應的安全措施來避免絕大多數的安全漏洞。

二、安全的軟件開發模型

隨著軟件安全開發的日益受到關注，多種模型被各大軟件公司和軟件專家提出和研究，例如微軟提出可信計算安全開發生命周期，Gary McGraw博士等提出的BSI系列模型，以及OWASP（Open Web Application Security Project，開放式Web應用程序安全項目）組織提出的CLASP綜合的輕量應用安全過程和SAMM軟件保證成熟度模型等。

其中微軟提出的SDL（Security Development Lifecycle，安全開發生命周期）相對認可度較高，適合大型企業，大型軟件的開發。該模型將軟件生命周期劃分為5+2個階段，每個階段有相應必需的安全活動，如圖1所示：

三、安全軟件開發過程

首先，在開始軟件開發過程之初，開發團隊的所有成員都必須接受適當的安全培訓，了解相關的安全知識，培訓對象包括開發人員、測試人員、項目經理、產品經理等。

（一）軟件安全需求分析

在軟件需求分析階段，不僅要考慮系統的功能需求，還要考慮系統的安全，比如不應該做什么。功能需求、安全需求、安全目標要達到平衡，從安全的角度以風險管理為基礎，建立“威脅”的分析計劃，不僅要從用戶的角度出發考慮系統的功能，還應從攻擊者的角度出發考慮系統的漏洞。

所以，在軟件需求分析階段，需要加入以下的安全方面的考慮：軟件提供的安全功能、軟件如何安全地與用戶交互、安全方面的考慮對軟件開發計劃的影響、軟件的風險評估和威脅模、 軟件的默認功能配置等等。

（二）軟件安全設計

軟件系統的每一項需求，都應該在軟件安全設計階段認真考慮，根據安全需求方案確定的安全目標，對初步風險評估確定的控制措施的具體技術實現而進行安全設計。

安全概要設計階段，包括但不限于：安全體系結構設計、各功能塊間的處理流程、與其他功能的關系、安全協議設計、安全接口設計等。

安全詳細設計階段，作為安全功能的程序設計階段，應當直接指導安全功能的編碼工作。包括但不限于：模塊設計、內部處理流程、數據結構、輸入/輸出項、算法、邏輯流程圖等。

軟件安全設計的核心原則參考如下：

如攻擊面最小化、基本隱私、權限最小化、默認安全、縱深防御、威脅建模等等。其中威脅建模，微軟使用的是STRIDE威脅建模方法，STRIDE的通用步驟如圖2：

威脅建模建議越早越好，一般在設計階段進行，流程是，用程序建模（Diagram）、枚舉威脅（Identify）、緩解威脅（Mitigate）、驗證緩解措施（Validate）。

（三）安全編碼原則

代碼安全編譯、代碼安全審核、對所有輸入數據進行檢查、驗證及過濾。

（四）安全測試

除了軟件開發傳統的單元測試，集成測試，系統測試和驗收測試外，還要有系統的安全測試。安全測試是進行安全性的評估，而不是摧毀或破壞，一般常用模糊測試和滲透測試兩種。

模糊測試，也稱Fuzz測試，一種通過提供非預期的輸入并監視異常結果來發現軟件故障的方法。該測試強制軟件程序使用惡意或破壞性的數據并進行觀察結果的一種測試方法。不夠強壯的程序會崩潰，利用大量的測試用例，查找漏洞或可靠性的Bug，是一種非常有效的漏洞挖掘技術，已知漏洞大部分都是通過這種技術發現的。

滲透測試是通過模擬惡意攻擊者進行攻擊，來評估系統安全的一種評估方法。該測試是從攻擊的角度測試軟件系統是否安全，使用自動化工具或者人工的方法模擬攻擊者的輸入，找出運行時刻目標系統所存在的安全漏洞。通過滲透測試找出來的問題都是真實的，也是較為嚴重的，但滲透測試一般只能到達有限的測試點，覆蓋率較低。

兩者相比較，Fuzz測試嘗試著通過半隨機的方式進行數據發送，來找出系統的漏洞，這樣極大的降低安全性測試的門檻。然而，Fuzz測試這樣也要求測試人員對被測的系統有更一定深度的了解，才能生成更準確的結果。與滲透測試相比，模糊測試顯然更易于進行。而且，借由自動化的測試工具，模糊測試可以把安全方面的經驗積累集成到測試工具中，從而為組織的持續的安全性測試提供組織財富積累。

安全測試，對測試人員還有一定的特殊要求，比如技術、知識和經驗都很重要，像“壞人”一樣思考安全問題，在做安全測試過程中，要做好系統備份、恢復措施和風險規避等方面的充分準備。

最后，軟件系統發布時必須要包含安全事件響應計劃。該計劃即使在發布時不包含任何已知漏洞的產品，也要包含可能在日后面臨新出現的威脅。此外，還要關注的是，若是產品中有外包的部分，即包含第三方單位開發的源代碼，也需要留下第三方的聯系方式并加入事件響應計劃，以便在發生問題時能夠找到相應的責任人。

綜上所述，我們在軟件開發過程中，要在各傳統階段時，時刻不忘信息安全的管理，總結如下原則和要點：

1.做好信息安全的培訓，要求整個團隊樹立好信息安全的意識；

2.進行充分溝通，包括與客戶、領導、項目經理、團隊中相關干系人等；

3.規范整個生命周期的流程，確保所有項目都與安全團隊保持良好溝通，避免遺漏；

4.增加獨立的安全團隊，并樹立安全部門的權威性，各個項目需由安全部門審核通過后才可正式發布；

5.將安全的技術方案寫到需求、設計等工作文檔中；

6.記錄所有安全相關的缺陷，激勵開發人員編寫更安全的代碼，進行信息安全的知識庫的積累，形成持續改進的良性循環。

四、軟件開發過程中的信息安全管理

那所有軟件的開發是不是都必須完整地遵循軟件“安全開發”過程呢？答案并不是。

軟件同其他產品不同，軟件產品具有明顯的特殊性，軟件產品在開發過程中的信息安全管理也更具復雜性。

首先，考慮完成該軟件開發的整個過程是否達到了一定要求。我們在實踐中不斷總結，以基于ISO9001標淮，同時吸收CMMI的原則，制定的軟件安全開發程序文件和指導書，擬制記錄這些流程操作的記錄表格模板。軟件安全開發過程包含合同評審、采購、項目管理、軟件開發、變更控制、設計評審、文檔控制、測試控制、不合格品控制、現場安裝、售后服務、技術支持、培訓管理等等，保證軟件開發過程體系有效性的管理評審、內審、文件/記錄控制、糾正/預防措施控制等程序文件，從而為安全開發過程的各項操作提供科學合理的指導，以此構成完整嚴密的安全開發過程保證體系。

總之，軟件的安全開發，應具體問題具體分析，結合相應的場景，實際的情況，對軟件安全開發的過程進行定制裁剪，如可以選擇：代碼審核 + 體系結構風險評估，基于風險的安全測試 + 滲透測試，安全需求分析 + 濫用案例開發，代碼審核 + 滲透測試，體系結構風險分析 + 基于風險的測試等等組合方式，有的放矢，綜合平衡考慮各影響因子，按需選用。

五、結論

隨著軟件安全開發的日益受到關注，各種安全管理模型也逐漸出現，但各種理論模型如何和企業的需求有機結合，讓真正簡單適用的模型在組織中落地，讓組織從中獲益，需要所有相關人員從理論到實踐，從實際工作出發，共同探討解決方案，盡早形成軟件組織的自主創新的的安全開發模式。