田曾昊
(航空工業綜合技術研究所,北京 100028)
基于需求建模的軟件安全性分析方法研究
田曾昊
(航空工業綜合技術研究所,北京 100028)
為了提高軟件安全性及可靠性,將需求建模引入針對軟件需求的安全性分析過程,利用系統危險源、典型運行場景、外部輸入輸出接口等建模方法從系統需求分配、動態交互、接口故障處理等開展多角度分析,從而提高軟件質量,并為后續軟件需求分析以及安全性分析工作中提供可復用數據資產。
需求建模;軟件安全性;軟件失效模式
軟件安全性分析屬于軟件確認(Validation)技術,與軟件測試所屬的驗證(Verification)技術共同構成軟件確認與驗證(V&V)工作閉環。分析與識別軟件需求中存在的安全性缺陷,制定相應的控制措施,并落實為軟件安全性需求,從而有效的消除和控制軟件安全性失效導致的系統危險。
在軟件開發過程中,由于技術難度高,軟件需求復雜,開發周期短等困難,軟件中存在安全性缺陷的幾率是很大的。現代化的軟件本身變得越來越復雜,開發一個軟件產品或一個大型系統所需要依靠的技術也越來越多樣化,如果不能在軟件生命周期早期發現軟件缺陷,將可能造成嚴重的后果。特別是對于航空航天、金融、交通等關乎人身財產安全的領域,在軟件生命周期早期發現并定位軟件缺陷對于減少不必要的人力財力成本和改善軟件質量至關重要。在軟件需求分析階段進行軟件安全性分析并結合歷史分析數據可以有效的減少軟件開發成本,提高軟件研制質量。
需求建模是一種軟件安全性分析方法,通過模型驅動從多角度分析軟件安全性缺陷,形成可復用的軟件失效數據庫,有效的防止或控制軟件缺陷的發生,為軟件后續的研制提供質量保證。
● 系統需求建模:依據系統需求或設計文檔,分析系統需求,了解軟件所實現的系統功能、與外部設備或軟件的交聯關系、外部危險源信息等,從而建立外部輸入輸出接口交聯環境模型、外部危險源列表,有效開展系統危險分析;
● 系統危險分析:在系統需求模型基礎上,結合系統背景知識、系統所處環境信息、外部交聯信息等,以初步危險分析(PHA),功能危險分析(FHA)[1~2]等技術為分析手段,分析潛在的系統危險、原因及影響;
● 系統危險控制:針對識別的系統危險及發生原因,從軟件層面上給出控制措施,同時將控制措施落實為系統向軟件分配的安全性需求。
● 軟件需求建模: 依據軟件研制任務書、軟件需求規格說明等文檔,明確軟件功能層次關系、功能動態執行過程以及功能邏輯關系,從而建立功能執行過程模型、功能邏輯模型等,以輔助規范且有效的開展軟件失效模式分析;
● 軟件失效模式識別與影響分析:依據軟件需求模型,以軟件失效模式及影響分析(SFMEA)等技術手段,分析軟件需求中存在的各種失效模式,并明確失效模式對系統的影響;
● 失效模式原因及控制措施:針對軟件需求中存在的各種失效模式,分析其發生原因,即軟件需求中存在的各類缺陷,并依據失效原因提出相應的控制措施,同時將控制措施落實為軟件安全性需求。
系統危險分析核心思想是從系統層面開展分析,即依據軟件所在系統的外部交聯設備、外部接口、危險源等信息,分析可能存在的系統危險及其原因和影響。結合軟件特點,可以從表1所示幾個方面考慮并建立需要的系統危險分析模型。系統危險分析模型見表1。

表1 系統危險分析模型
軟件失效模式分析核心思想是從軟件層面開展分析,即依據軟件需求中的功能、性能等需求項,分析可能存在的軟件失效模式及其原因和影響。結合軟件特點,可以從表2所示幾個方面考慮并建立需要的軟件失效模式分析模型。軟件失效模式分析模型見表2。

表2 軟件失效模式分析模型
系統危險分析模型及軟件失效模式分析模型在分析內容上彼此獨立,但分析過程間是相互影響、相互映射的關系。系統危險分析將所識別的系統危險映射至軟件需求層面,借助于軟件失效分析,確定系統危險的可能軟件原因和失效模式;而軟件失效分析則將所識別的失效模式映射至系統層面,借助于系統危險分析,確定軟件失效模式所可能導致的系統危險。因此,二者共同構成了“系統—軟件,軟件—系統”的雙向閉環分析策略,具體關系如圖1所示。
系統危險分析模型與軟件失效模式分析模型不僅限于上述幾種類型,軟件安全性分析人員可根據軟件特點增加或刪減分析模型。每種模型對于各類的軟件,分析效果也不相同,分析人員需熟練運用分析模型才能取得更好的分析效果。
下面將對軟件安全性分析過程中幾種通用的系統危險建模分析及軟件失效模式建模分析方法進行簡要說明。
3.1.1 輸入模型或信息
建立“外部輸入輸出接口”模型,應明確如下信息:
● 接口類型(離散量、模擬量、總線數據等);
● 接口值域(正常值域、異常值域);
● 外部設備(輸入源、輸出目的);
● 通訊方式(周期型、任務型);
● 相關功能;
● 接口關系(組合、約束等);
● 初始值、安全值;
● 已有接口故障診斷和處理策略。
建立“功能層次關系”模型,應明確如下信息:
● 軟件功能點;
● 相關接口;
● 功能點從屬關系。
3.1.2 分析內容與方法
外部輸入輸出接口分析內容和方法見表3。
3.2.1 輸入模型或信息
明確系統危險源:參考通用危險,結合軟件特點,確定系統危險源。通用系統危險源見表4。

表4 通用系統危險源
3.2.2 分析內容與方法
系統危險源分析內容和方法見表5。

表5 系統危險源分析內容和方法
3.3.1 輸入模型或信息
明確系統所在設備的可能運行階段,飛機如起飛、巡航、復飛、下降、滑行等。明確在設備運行階段下,軟件的各種可能運行場景。
3.3.2 分析內容與方法
典型運行場景分析內容和方法見表6。

表6 典型運行場景分析內容和方法
3.4.1 輸入模型或信息
建立“工作模式遷移模型”,應包含如下信息:
● 明確軟件在運行過程中所可能進入的工作模態,包括初始化、自檢、維護、控制管理、數據處理、下電等;
● 明確各工作模態的進入條件、退出條件、相關約束等信息;
● 明確可以相互遷移的工作模態之間的遷移關系,包括時序遷移、條件遷移、約束遷移等信息;
● 明確不能相互遷移的工作模態;
● 明確工作模態之間的邏輯關系,包括互斥關系、組合關系等。
3.4.2 分析內容與方法
工作模式遷移分析內容和方法見表7。
3.5.1 輸入模型或信息
建立“功能控制過程模型”,應包含如下信息:
● 明確工作模態下所有功能點的執行操作信息;
● 明確功能控制過程中的條件遷移、時序遷移、約束遷移、順序遷移等控制邏輯;
● 明確各執行操作之間的邏輯關系,包括組合關系、約束關系等;
● 明確功能控制過程中的數據流向信息。
3.5.2 分析內容與方法
功能控制過程分析內容和方法見表8。
3.6.1 輸入模型或信息
建立“功能控制過程”模型。
3.6.2 分析內容與方法
功能交互關系分析內容和方法見表9。
對分析記錄數據進行整理與合并,形成軟件安全性問題單,并在此基礎上形成軟件通用系統危險數據庫和通用失效模式數據庫,見表10。
其中:
● 問題編號:軟件安全性問題的唯一標識;
● 分析對象:功能點或需求點;
● 問題原因:描述軟件安全性問題的觸發條件與需求層面原因;
● 安全性問題:描述在滿足“問題原因”的前提下,軟件運行時所可能產生的失效模式;
● 問題影響:描述軟件安全性問題產生后,在系統層面所可能導致的后果;
● 系統危險:描述軟件安全性問題所可能導致的系統進入的危險狀態;

表8 功能控制過程分析內容和方法

表9 功能交互關系分析內容和方法

表10 軟件安全性問題單格式
● 控制措施:描述為避免由于軟件安全性問題而導致系統進入危險狀態,所提出的安全性要求。
● 重要度[4]:軟件安全性問題重要度等級見表11;

表11 軟件安全性問題重要度等級

表12 軟件安全性問題類型

表13 軟件安全性問題解決方案
本文基于需求建模研究了一套軟件安全性分析方法。需求建模可將軟件功能、狀態遷移、輸入輸出等要素進行可視化轉換,使軟件安全性分析更易于開展。同時,使用需求建模的方法可以保證軟件安全性分析的充分性,分析效果得到提升。
然而,為了發揮系統危險數據和失效模式數據的作用,還需要在如下幾個方面進行考慮:
建立系統危險數據及失效模式數據管理系統。在本文中僅給出了軟件安全性分析過程中產生的系統危險數據和失效模式數據格式。在數據管理系統中,還需對系統危險及失效模式數據進行提取[5]、存儲,以為后續的使用打下基礎。
對系統危險數據及失效模式數據進行挖掘并應用。在進行相關軟件模塊開發的需求階段,應充分參考系統危險數據及失效模式數據,確保類似問題不再出現或得到有效控制,減少軟件缺陷,提高軟件質量。
[1] 劉建軍,孫有朝. 功能危險分析在大型復雜系統中的應用[J]. 民用飛機設計與研究,2004(1):35~40.
[2] 孫春林,劉東宇. 功能危險分析在飛機剎車系統中的應用研究[J]. 機械設計與制造,2011(2):89~91.
[3] 周育才. 功能樹與FMEA的高效運用[J]. 質量與可靠性,2005(1):16~18.
[4] GJB/Z 102A-2012. 軍用軟件安全性設計指南[S].
[5] 王丙磊. 系統級軟件FMEA方法及輔助分析工具的研究[D]. 國防科學技術大學,2009.
T-65 [文獻標識碼] C [文章編號] 1003-6660(2017)04-0038-05
10.13237/j.cnki.asq.2017.04.010
[收修訂稿日期] 2017-05-03
(編輯:雨晴)