一種形式化的嵌入式軟件安全風(fēng)險評估方法

1、一種形式化的軟件安全風(fēng)險評估方法摘 要：基于 Z 語言的基礎(chǔ)上，以軟件的數(shù)據(jù)安全需求，融合了軟件功能與非功能建模元素，提出了一種軟件對象-消息-模型，簡稱為 OMR（Object-Message-Role）；在此軟件對象為評估，以軟件安配置與對象間的為為評估依據(jù)，提出了一種形式化的了應(yīng)用說明。軟件安全風(fēng)險評估模型及評估方法；通過一個實例對該方法進(jìn)行1概述安是軟件的重要非功能屬性之一軟件的安需求主要包括數(shù)據(jù)安全與行為安全，其中數(shù)據(jù)安全包括移的正確性與實時性等。隨著性、完整性以及可用性等，行為安全包括軟件狀態(tài)遷軟件在關(guān)鍵領(lǐng)域的廣泛應(yīng)用，如何在研制過程中保障和評估其安質(zhì)，是國內(nèi)外越來越關(guān)注的研究熱點

2、之一。1.1 研究現(xiàn)狀目前在軟件安全分析與評估方面的研究主要包括模型檢測、故障樹分析、風(fēng)險評估等方法，可分為方法和客觀方法兩種：方法定義了對軟件安分析或評估的指導(dǎo)性過程，多依賴于知識及管理的經(jīng)驗，適應(yīng)性與靈活性較強，但分析或評估結(jié)果帶有主觀因素，只能定性地描述軟件安狀況以及安全保障措施；而客觀方法則根據(jù)軟件體系結(jié)構(gòu)或模塊復(fù)雜性等特性，建立軟件自身或外部環(huán)境（如網(wǎng)絡(luò)環(huán)境等）的模型，以及安分析或評估模型，能夠得到定量的分析或評估結(jié)果?？陀^方法通常采用形式化語言來建立這些模型，形式化語言的優(yōu)點在于其嚴(yán)格的語義結(jié)構(gòu)和分析，與非形式化方法相比，能夠更精確地描述軟件的安約束，且自動化程度更高，但這導(dǎo)致了客

3、觀方法的描述與分析能力依賴于所采用的形式化語言本身?，F(xiàn)有的客觀方法采用的形式化語言主要包括 Petri 網(wǎng)、危險理論、樹、Z 語言、模糊邏輯等方法。文獻(xiàn)1提出了一種基于有色 Petri 網(wǎng)的實時絡(luò)風(fēng)險評估模型，能夠?qū)崟r分析和評風(fēng)險；文獻(xiàn)2提出了一種基于估理論的網(wǎng)絡(luò)風(fēng)險定量評估模型，可實時定量地和總體網(wǎng)絡(luò)風(fēng)險強度；文獻(xiàn)3給出了一種層次計算出主機和網(wǎng)絡(luò)當(dāng)前所的各類分析法與模糊邏輯法相結(jié)合的信息系統(tǒng)綜合風(fēng)險評估模型，通過將評估值進(jìn)行定量描述，從而得出更為客觀的評估結(jié)果。然而，上述研究均面向網(wǎng)絡(luò)進(jìn)行安全風(fēng)險的建模與評估，而非從軟件的結(jié)構(gòu)與行身出發(fā)，無法評估軟件系統(tǒng)的安設(shè)計是否存在缺陷。文獻(xiàn)4提出了一種

4、 p-time Petri 網(wǎng)模型，能夠通過對時間規(guī)約進(jìn)行建模來滿足系統(tǒng)的安全需求，但是并未給出模型的驗證方法；文獻(xiàn)5飛行系統(tǒng)中的模式邏輯（mogic）分析方法；文獻(xiàn)6基于 AIRBUS 和建立了基于失效樹的形式化建模，并給出了相應(yīng)的安ONERA 項目的實踐，采用形式化建模語言 AltaRica，通過故障樹與模型檢測方法開展項目的安驗證。這類研究主要側(cè)重于對軟件行為失效的建模與驗證，而沒有給出軟件數(shù)據(jù)安的建模與驗證方法。形式化方法基于其本身的元素和特性來描述系統(tǒng)的安全結(jié)構(gòu)與安全策略，不同的形式化方法在描述上具有不同的特點與優(yōu)勢，比如 Petri 網(wǎng)、有限自等方法基于軟件的動態(tài)行為進(jìn)行建模，而

5、Z 語言、進(jìn)程代數(shù)等方法則面向軟件的靜態(tài)結(jié)構(gòu)與數(shù)據(jù)約束。因此，在眾多形式化方法中，需要根據(jù)所關(guān)注的軟件特性與驗證目標(biāo)進(jìn)行合理的選擇。文獻(xiàn)7給出了一種BLP 模型8的安驗證方法，采用 Z 語言9建立了多級安全（Multilevel Security, MLS）在包含多級客體的系統(tǒng)中的形式化模型，并采用 Z/EVES 定理證明工具驗證模型的安全不變式（invariant）是否滿足 MLS 策略；文獻(xiàn)10定義了一種基于DTE 策略的Z 形式模型，采用 Z 語言形式定義了系統(tǒng)狀態(tài)、基于信息流分析的不變量和安全狀態(tài)，并借助 Z/EVES 工具給出驗證系統(tǒng)安全的形式分析方法，但由于 Z/EVES的性能較差

6、，當(dāng)展開大量的模式時，定理的證明效率將大幅降低；文獻(xiàn)11提出了一種用 Z語言描述的軟件風(fēng)險評估方法，以構(gòu)件、消息、安全以及 Risk proles 等作為風(fēng)險評估的基本結(jié)構(gòu)，采用 Z 語言對這些基本結(jié)構(gòu)以及風(fēng)險計算過程進(jìn)行了形式化定義以及實例研究，該方法能用新的度量標(biāo)準(zhǔn)來支持傳統(tǒng)風(fēng)險評估，并能在動態(tài)和分布式系統(tǒng)中維持準(zhǔn)確和持續(xù)的評估，將風(fēng)險評估Using Z1.2 研究外部環(huán)境相。加Validation of Security-Design Ms現(xiàn)有的大多數(shù)軟件功能模型與安分析模型是分離的，很大程度上增加了軟件安分析與驗證方法的復(fù)雜性。事實上，以面向?qū)ο蟮能浖槔?，其安分析模型與功能模型基于同

7、樣的軟件基本結(jié)構(gòu)或行為，因此二者的建模元素必然是相交的，我們可以先從軟件功能模型中抽取這部分建模元素生成安分析模型的基礎(chǔ)結(jié)構(gòu)，再對其進(jìn)行補充與完善。另一方面，由于軟件具有與物理計算/緊密耦合等特性，我們需要將形式化方法進(jìn)行相應(yīng)的擴展后才能用于軟件的建模。Z 語言以模式（schema）為基本結(jié)構(gòu)，具有“描述性”的特點9，能夠?qū)浖臓顟B(tài)與數(shù)據(jù)約束進(jìn)行較好的表達(dá)，在解決軟件數(shù)據(jù)安全的建模與分析問題時具有較大的優(yōu)勢。因此，本文以 Z 語言的語法結(jié)構(gòu)作為基礎(chǔ)，通過擴展其元模型來定義型。UML 的各類擴展為軟件模型的建立提供了豐富的元素。MARTE（M軟件的安分析模ing and Analysisof

8、Real Time and Embedded systems）12是 OMG 于 2007 年底發(fā)布的一個 UML 擴展標(biāo)準(zhǔn)。由于 MARTE 提出了較完善的時間模型以及非功能屬性、實時/并發(fā)等建模元素，為復(fù)雜軟件的構(gòu)造和分析提供了基礎(chǔ)13, 14，且綜合了以往工業(yè)界和學(xué)術(shù)界在實時領(lǐng)域的最新進(jìn)展，因此受到了廣泛的關(guān)注，已成為軟件建模的常用方法。目前在 UML模型與 Z 語言的轉(zhuǎn)換方面已有一些方法和工具，但均沒有涉及建模元素的形式化語義研究。SecureUML 模型。描述了基于的Role-Based Access Control, RBAC）規(guī)則，建立了一種將軟件功能模型與安全模型相融合的模型，

9、且二者之間具有松耦合的特性。SecureUML 從軟件用戶概念中抽取“”（Role）模型，將其賦于鍵的軟件實體（類），并將每個與一組權(quán)限進(jìn)行關(guān)聯(lián)。軟件功能模型與安分析模型相融合，本文首先借鑒面向軟件的半形式化建模方法 MARTE12以及 SecureUML的建模元素，采用 Z 語言的模式結(jié)構(gòu)定義了一種形式化的次，建立了軟件模型，稱為對象-消息-模型（Object-Message-Role, OMR）；其軟件安全風(fēng)險評估模型（Risk Assessment Mfor Embedded Systems,設(shè)計進(jìn)行分析與驗證；RAMES），并設(shè)計了相應(yīng)的安全風(fēng)險評估流程，對最后，通過一個實例對本文的方

10、法進(jìn)行了應(yīng)用說明。軟件的安軟件對象-消息-為什么分這三塊安全措施分類依據(jù)，及其對安2.1 對象模型模型2質(zhì)的影響因子確定對象是類的實例。我們考慮基于面向?qū)ο蠼Y(jié)構(gòu)的軟件安，因此以由對象或進(jìn)行通信的軟件數(shù)據(jù)作為安全措施鍵的建模元素。圖定義 2.1. 對象模型的基本數(shù)據(jù)類型包括：（1）塊與硬件軟件對象是抽象的功能單元，記對象類型為 O；本文假設(shè)對象包括軟件模兩種，因此定義一個給定集合 OTYPE：OTYPE=sc|hr（2）對象所擁有的用于或計算的數(shù)據(jù)結(jié)構(gòu)可看成是具有一定安全屬性的軟件資產(chǎn)，本文考慮的資產(chǎn)安全屬性包括安全需求與安全等級。記資產(chǎn)類型為 ASSET，安全需求類型為CONCERN，安全等級

11、類型為 SL，其中 ASSET 為軟件中的數(shù)據(jù)類型集合，另外兩個集合為給定集合。（3）對象中的操作是對象間通信的，其參數(shù)的來源可能是對象自身或其他對象，即 ASSET 類型。記操作類型為 OP，為軟件中的操作名稱集合。（4）對象的安全措施是為保護對象資產(chǎn)的安全需求所采取的本地策略，本文假設(shè)這種策略對安全需求的保護程度可歸一化為0,1區(qū)間內(nèi)的值，且保護程度越大該值越大。記安全措施類型為一個給定集合 SP：SP=encrypt |我們采用 Z 模式結(jié)構(gòu)給出對象模型的形式化定義，包括對象（Objects）、資產(chǎn)（Assets）、對象類型（OTypes）、操作（Ops）、安全等級（Sls）、對象安全措

12、施（Osps），以及四個分配關(guān)系： 資產(chǎn)與安全屬性的關(guān)系（ AssetsAssigns ）、對象與資產(chǎn)/ 對象類型/ 操作的關(guān)系（ObjectsAssigns）、操作與資產(chǎn)的關(guān)系（OpsAssigns）和對象與安全措施的關(guān)系（OspsAssigns）。具體定義如下：MOfObject Objects: O Assets: ASSET OTypes: OTYPE Ops: OPSls: SLOsps: ASSET×SP×CONCERN × RAssetsAssigns: ASSET( SL×CONCERN) ObjectsAssigns: O( ASSET

13、×OTYPE× OP) OpsAssigns: OP( ASSET× ASSET) OspsAssigns: O (ASSET×SP×CONCERN× R)(op, (aiset, aoset)OpsAssigns otOTypes; asetAssets; opsetOps (o, (aset, ot, opset)ObjectsAssignsopopsetaisetaset(o, (a, sp, c, con)OspsAssigns (a, sp, c, con)Osps( otOTypes; asetAssets; opsetO

14、ps; slSls (o, (aset, ot, opset)ObjectsAssignsaaset(a, sl, c)AssetsAssigns)上述模式的謂詞部分約束了兩個一致性條件：（1）在 OpsAssigns 關(guān)系中，對象 o 的操作 op 所使用的輸入?yún)?shù)必須屬于 o；（2）在 OspsAssigns 關(guān)系中，為對象 o 中安全需求為 c的資產(chǎn) a 設(shè)置對象安全措施 sp 時，需滿足 sp 的資產(chǎn)與安全需求屬性是一致的。定義2.2. 軟件操作集合Ops=<operationName>Op，每個操作模式<operationName>Op定義了本地參數(shù)（oAss

15、ets）、輸入?yún)?shù)（inputParas?）、輸出參數(shù)（outputParas!），以及由資產(chǎn)到布爾值的函數(shù) isUsed 與 isChanged。其中，isUsed 標(biāo)記操作是否使將某資產(chǎn)用于計算；isChanged 標(biāo)記操作的執(zhí)行是否改變了資產(chǎn)的值。具體定義如下：<operationName>Op oAssets: ASSETinputParas?: ASSET outputParas!: ASSET isUsed: ASSET isChanged: ASSET oAssetsdom ObjectsdomdomisUsed = oAssetsinputParas?isChang

16、ed = oAssetsinputParas?ranranisUsed = 0,1isChanged = 0,1軟件對象及軟件資產(chǎn)是軟件靜態(tài)結(jié)構(gòu)的基本組成部分，可根據(jù)下面的規(guī)則 1 由MARTE 類圖、對象圖以及分配模型進(jìn)行提?。阂?guī)則 1. 軟件對象可由 MARTE 類圖中的類對象與物理進(jìn)行提取，其中對象名對應(yīng)于類名/名，資產(chǎn)對應(yīng)于類成員/。2.2 消息模型MARTE 順序圖元素對象間的通信是由操作的執(zhí)行所引起的，通信內(nèi)容為源對象所擁有的屬性（資產(chǎn)）。圖定義 2.3. 消息模型的基本數(shù)據(jù)類型包括：（1）消息是軟件對象之間的通信結(jié)構(gòu)，記消息類型為 MSG；與軟件對象的類型相對應(yīng)， 本文假設(shè)消息包

17、括軟件模塊間的消息以及軟/硬件間的消息兩種，因此定義一個給定集合MTYPE：MTYPE=ss|sh（2）消息的安全措施是為保護資產(chǎn)安MSP。我們給出消息模型的形式化定義，包括消息（Msgs）、消息類型（MTypes）、消息安全措施（Msps），以及兩個分配關(guān)系：消息與消息類型/源對象/操作/消息內(nèi)容/目的對象的關(guān)系（MsgsAssigns）和消息與安全措施的關(guān)系（MspsAssigns）。具體定義如下：所采取的通信策略，記消息安全措施類型為MMOfMsg OfObjectMsgs: MSG MType: MTYPEMsps: ASSET×SP×CONCERN ×

18、RMsgsAssigns: MSG( MTYPE×O×OP×ASSET×O) MspsAssigns: MSG(ASSET×SP×CONCERN × R)(msg, (mt, os, op, m, od)MsgsAssigns ( ots, otdOTypes; asets, asetdAssets; opsets, opsetdOps (os, (asets, ots, opsets)ObjectsAssigns(od, (asetd, otd, opsetd)ObjectsAssigns masetsopopsets(m

19、t=ssots=scotd=sc)(msg, (m, sp, c, con)MspsAssigns (m, sp, c, con)Msps( otOTypes; asetAssets; opsetOps; slSls (o, (aset, ot, opset)ObjectsAssignsmaset(m, sl, c)AssetsAssigns)上述模式的謂詞部分約束了三個一致性條件：（1）在 MsgsAssigns 關(guān)系中，由對象 os至對象 od 的消息 msg，其消息內(nèi)容 m 必須是 os 的資產(chǎn)，且消息的操作 op 必須是os 的操作；（2）在 MsgsAssigns 關(guān)系中，源對象 o

20、s 與目的對象 od 的類型與它們之間的消息類型是符合一致性的；（3）在 MspsAssigns 關(guān)系中，為消息 msg 中安全需求為 c 的消息內(nèi)容m 設(shè)置消息安全措施 sp 時，需滿足 sp 的消息內(nèi)容與安全需求屬性是一致的。軟件動態(tài)模型的基本組成部分，可根據(jù)下面的規(guī)則 2 由MARTE 模型進(jìn)行消息是提?。阂?guī)則 2. 消息可由 MARTE 順序圖中的操作元素進(jìn)行提取，其中源對象 os/目的對象 od對應(yīng)于順序圖中的名，數(shù)據(jù) m 對應(yīng)于順序圖中的消息。模型SecureUML 元素2.3定義 2.4.（1）模型的基本數(shù)據(jù)類型包括：名稱與權(quán)限的二元關(guān)系，是之間可以有繼承（但不循環(huán)繼承）。記名稱

21、類型為一個給定集合 ROLE。（2）權(quán)限是分配給用戶的某一（類）軟件資產(chǎn)的操作范圍，記權(quán)限類型為一個給定集合 PER；本文假設(shè)權(quán)限包括只讀、只寫、讀寫三種，因此定義一個給定集合 PTYPE：PTYPE=read|write|both模型的形式化定義，包括（Roles）、權(quán)限（Pers）以及四個分配關(guān)系：我們給出資產(chǎn)與權(quán)限的關(guān)系（PersAssigns）、與權(quán)限的關(guān)系（RolesAssigns）、之間的繼承關(guān)系（Inherits）和繼承關(guān)系下的權(quán)限分配關(guān)系（InheritsAssigns）。具體定義如下：MOfRole Roles: ROLE Pers: PERPersAssigns: PER(

22、ASSET×PTYPE) RolesAssigns: ROLE PER Inherits: ROLE ROLEInheritsAssigns: ROLE PERroleInherit+id Roles=空(p, (a, pt)PersAssigns InheritsAssigns = (r, p) | r,ir: Roles; p: Pers (r, ir)(roleInherit+id Roles)(ir, p)RolesAssigns 上述模式的謂詞部分對的循環(huán)繼承進(jìn)行了限制。定義 2.5. 用戶模型的基本數(shù)據(jù)類型包括用戶與用戶的標(biāo)識，記用戶類型為 USER，用戶標(biāo)識類型為 ID

23、。我們給出用戶模型的形式化定義，包括用戶（Users）、用戶標(biāo)識（Uids）以及個分配關(guān)系：用戶與用戶標(biāo)識的關(guān)系（UidsAssigns）和用戶與具體定義如下：的關(guān)系（UserAssigns）。MMOfUser OfRoleUsers: USER Uids: IDUidsAssigns: IDUSERUserAssigns: USER ROLE軟件安全風(fēng)險評估方法3文獻(xiàn)11中的研究工作是以靜態(tài)模型所描述的構(gòu)件間通信為風(fēng)險模型，但是該模型建立在一般的軟件結(jié)構(gòu)基礎(chǔ)上，不支持物理、進(jìn)程分配與調(diào)用等軟件特有元素的風(fēng)險評估。本文借鑒文獻(xiàn)11的分布式風(fēng)險分析特性，將軟件對象作為一次風(fēng)險軟件安全風(fēng)險評估模型

24、及評估計算的單元，以軟件流程。通過由為為評估依據(jù)，設(shè)計了一種軟件的 MARTE 模型中抽取風(fēng)險評估模型，將軟件的建模與風(fēng)險評估兩個階段融合貫通，提供統(tǒng)一的架構(gòu)。軟件安全風(fēng)險評估模型（Risk Assessment Mfor Embedded Systems, RAMES）給出系統(tǒng)安全需求、劃分安全等級；建立 OMR 模型；給出者與注入風(fēng)險，計算對象風(fēng)險風(fēng)險。RMP 風(fēng)險評估過程圖3.1 RAMES模型首先，我們給出本文所使用的一些風(fēng)險評估相關(guān)概念說明：指為了獲取某個資產(chǎn)的權(quán)限而使用系統(tǒng)函數(shù)的行為。安全需求：利益相關(guān)者想要避免的一種后果，包括潛在的安全事故所引起的影響或損失，安全需求是安全目標(biāo)的

25、一種形式，可定義在一個/多個/某一級別的資產(chǎn)上。風(fēng)險：軟件對象的某一安全需求的的影響程度。某一安全需求的的影響程度?；蛲{的可能性，以及或威脅所引起的對該對象安系統(tǒng)風(fēng)險：軟件的或威脅的可能性，以及或威脅所引起的對軟件總體安注入風(fēng)險：由所引起的風(fēng)險，用于模擬系統(tǒng)風(fēng)險的來源，注入的風(fēng)險根據(jù)消息模型在軟件對象間進(jìn)行。由于安全風(fēng)險的是由于消息所引起的，因此建立軟件安全風(fēng)險評估模型的關(guān)鍵是建立消息模型。消息路徑即為風(fēng)險的路徑，并且還需考慮對象的輸入風(fēng)險策略，在消息模型中表現(xiàn)為對或傳機制等。由以上設(shè)計思想得到的與輸出風(fēng)險之間的關(guān)系，也就是對象內(nèi)部的安全輸數(shù)據(jù)時所采用的安全技術(shù)，如加密算法、軟件安全風(fēng)險評估

26、模型如圖 1 所示。*Msg0.1*Asset*Risk0.1input-output-likelihood: R cost: Rconcern: Concern0.1*SLConcernCtrl1圖 1軟件安全風(fēng)險評估模型定義 3.1 (軟件安全風(fēng)險評估模型).軟件安全風(fēng)險評估模型 RAES 是一個十元組，如式 1 所示。其中 ATTACKER 為合，SR 為系統(tǒng)風(fēng)險。者集合，IR 為注入風(fēng)險集合，H 為風(fēng)險狀態(tài)集RAES = (O, Asset, SL,Concern, Msg,Ctrl, A, IR, H , SR)（式 1）定義 6 (風(fēng)險類型).對象的風(fēng)險值由對象或其他威脅的可能性（

27、likelihood）、遭受后的影響值（cost）以及所影響的安全需求（Concern）共同決定。其中，影響值與該對象資產(chǎn)的安全等級（SL）相關(guān)聯(lián)，具體的關(guān)聯(lián)函數(shù)由系統(tǒng)安全策略決定。Risk likelihood: concern: Concerncost: RiskValueinvariants在上面的定義中，RiskValue 為風(fēng)險值類型，由于現(xiàn)有的安全標(biāo)準(zhǔn)中都以等級來表示風(fēng)險大小，因此本文將 RiskValue 定義為一個取值范圍為 0 到 n 的正整數(shù)。定義 6 (者、注入風(fēng)險). 注入風(fēng)險中包括風(fēng)險來源、注入對象和風(fēng)險，其中風(fēng)險來源為某一者，者以給定集合的形式給出；注入對象表示受到

28、而遭破壞或被獲取讀寫權(quán)限的軟件對象；而風(fēng)險則以風(fēng)險類型進(jìn)行定義。O*Hazard<irName>IR attacker: AinO: OinRisk: Risk定義 7 (風(fēng)險狀態(tài)). 通過風(fēng)險計算得出的軟件對象風(fēng)險的集合即為對象的風(fēng)險狀態(tài)。<objectName> Hazard |<objectName>Orisk: Risk定義 8 (系統(tǒng)風(fēng)險). 系統(tǒng)風(fēng)險指所有者所引起的風(fēng)險集合。SystemRisk attacker: Arisk: Risk3.2 基于RAMES模型的軟件安全風(fēng)險評估流程軟件安全風(fēng)險評估流程如下：識別軟件資產(chǎn)并給定其安全需求 Con

29、cern 與安全等級 SL； 建立軟件的消息模型 Msg；給出注入風(fēng)險集合 IR，根據(jù)資產(chǎn)的安全等級以及消息模型，計算每個對象的風(fēng)險狀態(tài) H，得出的結(jié)果為一個 Risk 類型的集合；根據(jù)每個對象的風(fēng)險狀態(tài)，計算出每個注入風(fēng)險所對應(yīng)的系統(tǒng)風(fēng)險 SR。（1）（2）（3）（4）風(fēng)險評估流程完成后，需要對評估結(jié)果進(jìn)行分析與處理。在本文的方法中，若某個對象o 的關(guān)于某個安全需求 c 的風(fēng)險狀態(tài)小于注入風(fēng)險，則說明注入風(fēng)險的對象 o與o 之間沒有路徑，即二者之間的安全機制是有效的；若得出關(guān)于 c 的風(fēng)險狀態(tài)等于注入直接的風(fēng)險，則說明 o與o 之間的安3.2.1對象風(fēng)險狀態(tài)的計算設(shè)計可能存在漏洞或缺陷，需要

30、返回建模階段進(jìn)行修改。為了計算一個對象對與其通信的其他對象輸出的風(fēng)險，必須把所有的輸入消息和輸出消息間的關(guān)系都列舉出來。因此，某一種安全需求，計算從某一個對象輸出的威脅路徑分兩步：對一個給定的輸出消息，列舉所有可能的威脅路徑；從中選擇輸出風(fēng)險最高的路徑作為。風(fēng)險計算狀態(tài)函數(shù)是用于計算風(fēng)險狀態(tài) Hazard 的操作，包括 Enumerated、Exported 以及 HazardCal 三個操作。其中，Enumerated 枚舉對象的所有輸出消息可能引起的輸出風(fēng)險； Exported 選取對象的輸出消息可能帶來的影響每個安全需求的最高風(fēng)險；HazardCal 計算對象的風(fēng)險狀態(tài)集合。這三個操作的

31、分別如下：（1）Enumerated 操作中，集合中的結(jié)果是由兩種途徑得來的：每個與資產(chǎn) ai 相關(guān)的輸出消息 msg 的輸出風(fēng)險；每個與輸入消息 m 相關(guān)的輸出消息 msg 的輸出風(fēng)險。Enumerated: Msg×Risk Exported: Msg×Risk HazardCal: RiskEnumerated |<objectName> Hazardmsg: Msgrisk: Risk ( i getAC(assetsi) = getRC(risk) )(ctrssetsi, msg, getRC(risk) )= getL(risk) )getCOST

32、(risk) = getSL(assetsi) m Msg, r Risk ( (m, r) Exported )getRC(r) = getRC(risk) getOD(m)= getOS(msg) getCOST(risk) = getCOST(r)getL(r)*ctrlMM( m, msg, getRC(risk) ) = getL(risk) （2）Exported 操作在 Enumerated 中選取每個輸出消息 msg 帶來的最高風(fēng)險。同一安全需求的Exported |<objectName> Hazardmsg: Msgrisk: Risk(msg, risk) &

33、#172; r Enumerated Risk (msg, r) Enumerated getL(r) > getL(risk) getRC(r) = getRC(risk) （3）HazardCal 操作描述了是對象被后所引起的風(fēng)險，該集合中的風(fēng)險值 risk 包括了與該對象資產(chǎn)的輸出風(fēng)險以及對與該對象通信的其他對象的輸出風(fēng)險，同時滿足集合中的風(fēng)險值都是最高風(fēng)險值。HazardCal |<objectName> Hazardrisk: Risk i getAC(assetsi) = getRC(risk) ( m Msg ( getOD(m) = <objectNam

34、e>O ) (m, risk) Exported ) ¬ r Risk r HazardCal getRC(r) = getRC(risk) getL (risk) < getL (r) 3.2.2系統(tǒng)風(fēng)險的計算系統(tǒng)的每一個注入風(fēng)險總是對應(yīng)于一種安全需求 c，即者總是有影響系統(tǒng)某種性質(zhì)的期望。對于每一個對象 i 的關(guān)于安全需求 c 的注入風(fēng)險 inRisk，HazardAssess 操作找出對象 i 的風(fēng)險狀態(tài)<objectNamei>Hazard 中所有關(guān)于 c 的輸出風(fēng)險 ri，并將 ri 的可能性與注入風(fēng)險 inRisk 的可能性相乘，得出注入 inRi

35、sk 的者所引起的風(fēng)險值。所有的 systemRisk的集合即為系統(tǒng)的整體風(fēng)險評估結(jié)果。系統(tǒng)風(fēng)險計算函數(shù) HazardAssess 如下：HazardAssess | <objectNamei> HazardsystemRisk: P SystemRisk inRisk: ZMInRisk, r getHR (<objectNamei> Hazard) getHO(inRisk) = objectNamei getSA(systemRisk) = getIA(inRisk) getRC( getSR(systemRisk) = getRC(r) getL(getSR(s

36、ystemRisk) = getL(r) * getL(getIR(inRisk)4實例應(yīng)用4.1 軟件模型本文以某指揮軟件為例，對提出的軟件安全風(fēng)險評估方法的應(yīng)用進(jìn)行說明。該示例軟件完成的功能分為數(shù)據(jù)收集、計算決策以及執(zhí)行任務(wù)三個步驟，相應(yīng)的功能模塊包括傳感器模塊、數(shù)據(jù)處理模塊、設(shè)備模塊以及指控模塊。軟件的工作流程是將傳感器模塊采集的數(shù)據(jù)至數(shù)據(jù)處理模塊進(jìn)行計算，將計算結(jié)果給設(shè)備模塊，完成任務(wù)的執(zhí)行，同時由指控模塊對各模塊進(jìn)行指揮與以及 Controller，類圖如圖 2 所示。示例軟件共包括四個類：Sensor、Computer、DeviceControllerComputer-rank :

37、 int-SData : int-RData : int-manage+start()+startCpt()+startDev()+postProcess()+RcvSData() : int+Compute(in SData : int) : int+SendRData(in RData : int)11-manage1-compute11-executeDevice-RData : int-FBData : int1+RcvRData() : int+GetFBData(in RData : int) : int+SendFBData(in FBData : int)圖 2 示例軟件模型4

38、.2 風(fēng)險評估模型示例軟件的數(shù)據(jù)類型包括三個：傳感器原始數(shù)據(jù) SData、計算結(jié)果數(shù)據(jù) RData 以及設(shè)備反饋數(shù)據(jù) FBData。我們考慮影響示例系統(tǒng)安的類屬性，根據(jù)安需求為其賦予安全等級與安全需求，并建立軟件的消息4.2.1安全等級與安全需求模型與相應(yīng)的安全函數(shù)。示例系統(tǒng)中的安全需求 Concern 設(shè)置為性（C），根據(jù)我國標(biāo)準(zhǔn)，資產(chǎn)的安全等級 SL 劃分為非密，四個等級，分別用整數(shù) 03 表示，<<enumeration>>iteration+1.10Sensor-SData : int+GetSData() : int+SendSData(in SData :

39、int)-sensors-compute* 1數(shù)值越大密級越高。在建立風(fēng)險評估模型時，首先需要根據(jù)軟件模型識別軟件對象的鍵資產(chǎn)，按照 2.2 節(jié)的定義將資產(chǎn)與安全需求相關(guān)聯(lián)并設(shè)置相應(yīng)的安全等級，具體如表 1所示。表 1 安全等級4.2.2消息模型為了清晰地描述對象間的通信關(guān)系，建立示例系統(tǒng)的消息模型，我們對軟件對象間的通信關(guān)系進(jìn)行分析。軟件中傳輸?shù)南钆c數(shù)據(jù)，前者僅作為發(fā)起或結(jié)束某項任務(wù)，或者作為對硬件設(shè)備令，操作的參數(shù)，也不在對象中進(jìn)行，如啟動傳感器的 start()操作發(fā)出等；而后者是用于計算或的消息，將于軟件的內(nèi)存或數(shù)據(jù)庫中，因此一般密級較高。我們在消息模型中主要考慮數(shù)據(jù)消息，根

40、據(jù) 2.2節(jié)的定義對每個消息進(jìn)行描述，圖 3 為消息模型的示意圖，圖中的粗體矩形代表軟件對象， 以虛線與對象連接的矩形代表該對象的資產(chǎn)，箭頭代表消息的傳輸路徑，箭頭上的變量為消息的數(shù)據(jù)類型。RdataFBDataSDataRdataSensorComputerDeviceSdataRDataRdataFBDataSData圖 3 消息模型示意圖4.2.3風(fēng)險函數(shù)由于件設(shè)備軟件的開放性，必然存在系統(tǒng)外部的風(fēng)險來源，可能的風(fēng)險來源包括作為硬外部進(jìn)行交互的 Device 對象，以及系統(tǒng)的數(shù)據(jù)來源 Sensor 對象。我們根據(jù)圖 3中描述的消息模型，以表格形式給出軟件對象的風(fēng)險函數(shù)。將資產(chǎn)與輸入消息作

41、為行、系數(shù)在本文中取 0、0.5輸出消息作為列，以風(fēng)險系數(shù)作為表格內(nèi)容。其中，風(fēng)險和 1 三級，分別代表“不存在風(fēng)險”、“風(fēng)險大幅度降低”以及“風(fēng)險無”。 由于安全需求只包括性，因此在表格中將其省略。設(shè)置風(fēng)險函數(shù)的基本準(zhǔn)則如下：（1）對象內(nèi)部若未采用加密技術(shù)、認(rèn)證、等安全，則風(fēng)險系數(shù)為 1；否則，視加密算法強度、密鑰長度等將風(fēng)險系數(shù)設(shè)為 0 或 0.5；（2）系數(shù)為 1；若僅用于內(nèi)部計算、不存在輸入消息若直接用于輸出，則風(fēng)險輸出路徑，則風(fēng)險系數(shù)為 0；否則，風(fēng)險系數(shù)為 0.5。表 2 給出了示例軟件中各對象的風(fēng)險函數(shù)。以安全等級最高的 FBData 為例，假設(shè)其傳輸過程中采用了加密算法，但FB

42、Data 的對象 Device 并未采用此，CtrlAM ( FBData, FBData, C )=0.5。表格中其他部分以此類推。等機制，因表 2 風(fēng)險函數(shù)SensorSendSDataRdata FBDataControllerAssetSDataRDataFBDatarankConcern12314.3 風(fēng)險計算4.3.1 注入風(fēng)險首先，我們給出一組假定的者 A：A = a A 中的每一個者對應(yīng)一個注入風(fēng)險，其中風(fēng)險可能性（likelihood）的取值范圍為0,1，風(fēng)險影響（cost）表示為與注入對象資產(chǎn)的最高安全等級相關(guān)的一個函數(shù)：aInRisk attacker = ainO =

43、ControllerOinRisk = aRiskaRisk likelihood = 0.2concern = C a getASSETS(ControllerO) cost = getCOST ( max ( getSL(a) ) )4.3.2計算對象風(fēng)險狀態(tài)本文提出的風(fēng)險評估方法需要對每一個鍵資產(chǎn)進(jìn)行風(fēng)險計算，得到的過程與結(jié)果可用表格的形式來。風(fēng)險狀態(tài)的計算是一個迭代的過程，需要逐行進(jìn)行計算，直到結(jié)果不再變化為止。每一行的風(fēng)險計算過程如下： 根據(jù)對象當(dāng)前的風(fēng)險狀態(tài)， 依次計算Enumerated、Exported 與 HazardCal，得到該對象的最高風(fēng)險，并在對應(yīng)的單元格中。以安全等

44、級最高的 FBData 為例，初始的風(fēng)險可能性設(shè)為 1、安全需求為性 C、安全等級為 3，因此初始風(fēng)險為（1，C，3）。計算結(jié)果如表 3 所示，同樣由于安全需求只包括性，因此在表格中將其省略。表 3 FBData 的風(fēng)險狀態(tài)計算過程4.3.3計算系統(tǒng)風(fēng)險將各對象的風(fēng)險狀態(tài)結(jié)果進(jìn)行綜合，可以如表 4 所示的系統(tǒng)風(fēng)險狀態(tài)。表 4 示例系統(tǒng)的風(fēng)險狀態(tài)對象SensorComputerDeviceController風(fēng)險狀態(tài)1，11，21，30.5，3迭代次數(shù)SensorComputerDeviceController0001，301001，30.5，3CtrlAMSData1ComputerSendR

45、DataCtrlAMSData-RData1CtrlMMRcvSData0DeviceSendFBDataCtrlAMRData-FBData0.5CtrlMMRcvRData0根據(jù)注入風(fēng)險與注入對象的風(fēng)險狀態(tài)，可以得到注入風(fēng)險集合aInRisk下的系統(tǒng)風(fēng)險：systemRisk = ( a，(0.1，C，3) 通過對該結(jié)果的分析，我們可以給出對示例系統(tǒng)的安在 Controller 對象不存在完整的路徑。結(jié)論如下：從 Device 對象到5總結(jié)與展望的風(fēng)險評估方法，采用 Z 語言對風(fēng)險評估軟件的 MARTE 模型與風(fēng)險評估模型相本文提出了一種軟件數(shù)據(jù)安模型與風(fēng)險計算過程進(jìn)行了形式化定義，并將關(guān)聯(lián)，使步研究軟件的建模與安分析階段能夠更好的融合。在本文的基礎(chǔ)上，可以進(jìn)一軟件行為安的風(fēng)險評估方法，以及考慮由開放環(huán)境所導(dǎo)致的軟件外部物理環(huán)境引起的風(fēng)險及其評估方法。參考文獻(xiàn)動態(tài)風(fēng)險評估模型的研究 D; 北京交通大學(xué), 2010.12.,峰, et al. 基于理論的網(wǎng)絡(luò)風(fēng)險評估模型 J. 電子科技大學(xué)學(xué)報,2007, (06): 1198-1201.峰,生. 信息系統(tǒng)的模糊風(fēng)險評估模型 J. 通信學(xué)報, 2007, (04):351-56+64.,4 S. C. Dutilleul, F. De