論根據圖形使用延伸的UML驗證軟體設計缺點(上)

作者/莊力吉

前言 現今安全性議題已經被視為軟體開發的標準程序之一，特別是在初始階段，但企業組織仍缺乏實用且正式的方法來增強軟體安全性。軟體安全性包含背景，像是安全性需求、安全性設計、安全性架構分析等等。儘管各方面的考量都已經被滿足，但它們之間仍舊缺乏連貫的方法。所以本文目的是使用延伸的UML在開發與建構階段根據圖形的方法以及安全性需求規範與圖形轉換機制來驗證軟體設計層級可能發生的缺點。本篇安全性機制將依據CSC模型來定義安全性需求規範。CSCs主要是用來針對安全性需求規範在設計層級的安全性所使用的對策。本篇使用實際範例透過安全性驗證的方式來說明。 概述 近年來，隨著資訊安全事件發生的次數逐漸攀升，資訊安全變得越來越重要。我們可以從CERT Coordination Center (CERT/CC) of the SEI(詳參圖一)中所報導的資訊安全漏洞趨勢看到。電腦安全中最重要的而且最核心的部份則是軟體安全，特別是軟體的漏洞。 首先，我們考量所需的安全性必須被建置在軟體中。安全性必須被設計與建置在一套系統開發初期。根據CERT/CC，超過九成的資訊安全事件來自軟體設計的漏洞。因此安全性考量必須在軟體釋出的最一開始就必須被納入。軟體安全中的最佳實務有一系列的活動需要被應用在軟體開發流程中。至今整合安全性到軟體開發生命週期仍是一項艱難的工作。 漏洞簡單的可以分成兩類-建置層級的臭蟲，和設計層級的缺陷。除此之外，McGraw也指出“設計層級的漏洞是最難被處理好的，同時也是最廣泛與最重要的問題。”設計層級的問題包含物件導向系統中的錯誤控制、共享物件與信賴議題。 為了在起始階段有效增進軟體安全性，我們強調軟體開發生命週期中的需求與設計。所以程式碼與建置層級的問題不在此篇文章討論的範疇內。在不同的研究中，圖形化的方法被使用來控制需求與建置的軟體開發，但大多數是非正式的，特別是安全性的考量。因為這個原因，我們提出一套方法，根據圖形使用延伸的UML來辨識與驗證軟體設計的安全性漏洞。 文獻探討 接下來介紹軟體安全的背景讓讀者瞭解最基本的問題。除此之外，並探討相關文獻對於安全性度量的方式。 一、在軟體開發中建置安全性 當McGraw指出軟體安全領域是一個相對較新的議題時，書本和學術在這方面已經從2001年就已經出現了。這代表著科學家、軟體開發人員近年來已經開始有系統地研究軟體安全相關工作。The Build Security In 組織在IEEE Se-curity & Privacy雜誌中發表了一系列有關軟體安全與應用安全的差異在於軟體建置之前或之後來考量安全性。前者著重在建置安全的軟體，像是設計安全的元件、研究各階段彼此之間在設計層級的互相關係等等。後者著重在防範外部的釋出，像是惡意的程式碼攻擊軟體等。現今安全性考量已被定義為主動式的活動，繼續來探討在軟體建置前必須做的事項。 為了使本文具有獨立性，需求與設計的解釋會簡短的描述。需求範疇包含示範錯誤的案例，透過使用者個案和架構來說明惡意破壞者如何攻擊系統、會造成什麼影響以及軟體如何處理這樣子的狀況。設計類別包含兩個相關的部份，商業分析和建構風險分析(我們著重後者)，所以我們從對手的角度來探討元件、模組和它們之間的關係來防止攻擊以及解決的方法。儘管我們知道每個軟體的部份以及它相對應的最佳實務，有效應用的正式方法仍然缺乏實際的解決方案。除此之外，安全性需要被拓展的不只寬度，同時還有深度。 如同Haley等人指出，適當的安全性需求必須滿足三個標準︰定義、假設和滿足性。另外，我們簡短的說明。 定義意思就是其他人必須瞭解安全性需求真正代表著什麼；假設意思是安全性需求必須考量一個分析者針對系統裡的互動性包含隱性以及外顯的假設；滿足性意思是其他人必須能夠定義安全性需求是否能滿足何種安全性目的以及系統是否能滿足何種安全性需求。因此，我們必須基於完整的安全性需求工程的架構來定義適當的安全性需求。安全性需求從安全性目的而來，像是隱密性，而安全性目的則是從功能性需求而來，像是目的。為了簡短的表示我們基於的方法，圖二展示了簡易的架構。在圖二中，我們基於他們流程的前半段來當作本篇文章的基礎，像是辨識功能性需求、引出或修訂安全性目的以及建構安全性需求，但我們提出以不同的方式來指定和驗證安全性需求。在參考資料8中辨識功能性需求與安全性目的與安全性目的和安全性需求的過程中，這是兩兩緊密關係的影響，也是為何我們引用此為我們架構的基礎。 至於安全性規範的需求，K. M. Khan和J. Han 提出一個切實可行的辦法，是關於使元件的安全性配置與CSC可行，並基於三個元素來確保所需的安全性︰安全性操作、安全性屬性和應用資料。這三個元素可以構成一個簡單的公式來描述安全性需求和保證各個獨立的元件與各自之間。作者開發一個活動的界面，不只包含操作和屬。如同作者所說，我們需要建立一個全面性的安全特性複合系統，可以備用來作更進一步的複合為單一元件。因此，我們必須考量建立一個小單位並確保單一元件與它的複合元件都是安全的，那麼我們才可以意味著整個部份都是安全的。 CSC 模型由K.M. Khan and J. Han所提出(詳參參考資料9)，缺乏時間辨識性。因此我們的方法藉由添加時間戳寄來增進可能造成並行攻擊的漏洞。 Abie等人已經提出Security Requirement Language (SRL) 用來描述並建構安全性需求。他們的方法基於延伸first-order 邏輯，並以一系列模型操作和抽象句法為標記的機制。它賦予了新的領域描述需求延伸性，像是安全性，同時也能被定義與重複使用。基於first-order邏輯，SRL 可以用一段簡單的抽象定一來描述任何一個能被循序漸進的需求。在他們的努力中，時間和定義的延伸性有被考量進去。他們使用UML的comment box作為一個標籤以整合SRL，但缺乏安全性的驗證。 他們開發的Macro 工具可以以一個name和一個body來幫助制定需求，所描述的需求資訊定義在comment box的標籤中。這對終端使用者來說有助於使用簡單的定義而非複雜的符號來描述需求。這個 comment box是被標記在每個需要安全性的互動中，但他們的方法缺少緊密的互相聯繫性，像是K.M. Khan and J. Han提出的方法。針對這點，我們合併了他們的特點並提出一個新的方法來增進這樣的缺點。 二、UML圖形的轉換 從元件層級的角度，一個基於圖形的模型已經被展示來評估開發中設計的保密性並能到達一個可以推理的公式。 Liu 等人已經提出一個安全性評估的方式，透過UML循序圖使用圖形轉換的方法，User System Interaction Effect (USIE) 模型。USIE的基本符號標示在圖四中。 在他們的方法中，圖形可以藉由轉換為UML的循序圖後以被評估。儘管USIE模型可以備用來衡量設計層級Information Leakage Channel (ILC)的保密性，該模型中的任一實體無法被保證滿足安全性需求。USIE中使用的線只代表著順序和互相關係的方向性。USIE圖形符號的元件標示在圖三。 InteractionStart節點代表著程序的開頭。每一個USIE模型包含一個InteractionStart節點，和多個RoleEntity 節點，該節點對應UML循序圖中的角色實體。USIE途中的線有三種類別︰NoAttributes，ChangeState和ReturnInformation。首先，第一個不會影響後續角色實體，像是Read() 操作。 第二個代表會改變後續角色實體的狀態或資訊。第三個代表回傳訊息，可能會包含前兩種類型。線以升冪或降冪的方式排序，任一條線有各自的屬性。在本篇方法中，我們將CSC資訊以USIE模型的方式加入到線中來增進節點滿足安全性需求的轉換形態。 三、安全性的驗證 Y. Liu 及 I. Traore(詳參參考資料11)所提出的公式若">則表示如下︰ 其中代表significant資訊洩漏從IA到IB的數量。上述算式可以簡單地辨識兩個USIE模型之間的保密程度。我們利用這樣的方式來提供數值化、有效的驗證機制，儘管它只滿足安全性目的中的保密性。 任兩個USIE模型中的資訊洩漏管道可以以兩種類別辨識。第一種是S 代表signifigant 資訊洩漏管道，若相連的節點會回傳資訊到另一個USIE模型的InteractionStart 節點。. 第二種是S 代表secondary資訊洩漏管道，若相連的節點不會回傳資訊到另一個USIE模型的InteractionStart 節點。資訊洩漏管道在不同的USIE模型中連接著相同的操作，而上述算式則著重在signifigant資訊洩漏管道。 如同上面提到的，Khan 等人已經提出一個方法來驗證元間之間的安全性需求但缺乏節後性與設計層級的安全性需求驗證。因此，我們試著結合這兩種方並提出一個新的機制來滿足互動與結構性的安全性。 安全性需求工程的架構 我們根據C.B. Haley, R. Laney, J.D. Moffett及 B. Nuseibeh(詳參參考資料8)所提出的架構並提出一套架構的機制來同時滿足元件層級和結構層級的安全性考量。在我們的架構中，利用安全性需求工程[8]架構與延伸的UML註記[1]做合併。這樣使得我們可以使用安全性需求架構所產生的結果來定義適當的安全性需求並配合延伸性UML註記進行的驗證。我們的方法可以從兩個層面建構︰Phase 1 安全性需求與UML的整合；Phase 2 圖形結構的分析層級。. Phase 1 延伸H. Abie, D.B. Aredo, T. Kristoffersen, S. Mazaher, 及T. Ra-guin(詳參參考資料1)並整合一正式的安全性需求工程的架構。Phase 2 應用UML圖形在設計層級分析，再進行驗證的機制。 一、安全性需求架構 我們著重在合理的安全性需求描述，一旦一系列的安全性需求被開發後，最重要的部份則是驗證其是否有被滿足。根據[8]所提出的方法，該方式可以透過一個完善定義的流程來進行。安全性需求由安全性目的產生來達成Confidentiality、Integrity和Availability 原則，安全性分析機制則是確保安全性需求是否被滿足。我們將以一個簡單的例子圖五說明完整的安全性需求程序。在圖四中的左邊灰色區域為Phase 1，我們基於完善架構的方法來定義適當的安全性需求，而在圖五中的右邊灰色區域提出我們的機制來合併UML與安全性驗證的機制為Phase 2。 為了確實並有彈性的辨識安全性需求，我們提出一個方法Principal Security Requirement Language (PSRL) ，其延伸了參考資料1和9的做法，來達到下面列出的目的：

• 當定義安全性需求時，我們考量不只建立what – 需求定義還有how –的需求定義。
• 安全性需求定義必須在開發過程中有所幫助，並能表達不只安全性考量還有元間之間的一般互動。
• 安全性需求定義必須在保密性上有延展性，像是訊息驗證、信任、互動獨立性和存取授權等等。
• 當辨識安全性需求時，大多使用者並不熟悉數學化的標記方法。標示方法對使用者來說必須簡單而且清楚容易了解。

The PSRL的組成包含如下：

• logical symbols 以first-order 邏輯組成，像是連結子()，運算子()和邏輯子()
• the operation DoB(A,C) 代表 a principal A use B to do C. 舉個例子EncryptPvt.A (A, {data}) 代表著本體A 使用A 的私密金鑰來加密data ，其中Pvt.A 代表著本體A 的私密金鑰。
• the functions f(X, Y, Z) 的 f 代表著由三個連結參數組成的security purpose；本體X 是組合器約中執行安全相關的操作；Y 是一系列被本體使用的security attributes；Z 是一系列的data or information 藉由security purpose操弄。 舉個例子︰ MessageAuthentication(P, Pub.Q, 　　　　　　{document}.digi_sign(Q))
• 代表著本體 P 使用本體Q 的公開金鑰來對訊息document 做加密的動作，其中Pub.Q 代表本體Q 的公開金鑰，而digi_sign(Q)代表著本體Q 所作的數位簽章。
• a macro facility 允許邏輯化公式的定義可以表示成一個簡單的macro。一個macro 的組成包含一個安全性目的相關的名稱、特定參數的本體，可以幫助使用者習慣簡易、清楚的定義，而非複雜的數學公式。

下面的例子說明了我們方法中macro的觀念： 上述算式說明了一個macro，MessageAuthentication，其中有三個參數：第一個是本體，第二個則是安全性屬性來影響最後的一個參數，也就是訊息。上方的定義辨別了A必須透過使用B 來加密訊息C。也就是說，我們可以說明訊息C 在傳送的過程能被本體A 所驗證。 Macros可以藉由改變參數來進行擴充。Macros包含一個函式庫被包含在PSRL，稱為standard函式庫。該函式庫包含了對應一般安全性需求的macros，像是保密性、訊息驗證等等。因此，使用者可以定義他們的macros、客製化需求並把定義好的macros放入到函式庫中，其中函式庫也促進需求的重複使用。我們使用PSRL來描述一個或多個本體的安全性需求，該本體可已是一個元件、一個類別或是一個角色實體。任何一個本體包含兩種描述：一個required 安全性屬性 R 當作先決條件和一個 ensured 安全性屬性E 當作後置條件。Macro msgAuth 是MessageAuthentication的縮寫，其中代表著下列定義： 下面例子代表著元件X 的安全性需求： 其中Pub.y 是本體Y的公開金鑰，Pvt代表私密金鑰。 The ensured 屬性陳述著X 將提供收據給客戶Y。X 將用Y公開金鑰 (Pub.y) 加密收據 (EncryptPub.y(X, {receipt})) 。另一方面， required 屬性陳述著 X 需要Y 用自己的私密金鑰(Pvt.y)來加密 ({order}.digi_sign(Y )) 貨物訂單作為一個數位簽章。 根據這個格式，我們可以延伸到所有的元件和每個元件的required 和 ensured 屬性。一個元件傳送一個訊息或一個事件來要求服務稱作focal component；軟體元件回應訊息可以視為candidate components。透過元件之間的compositional security contract (CSC) ，系統內的互動可以被辨識、描述以及根據安全性需求來驗證。CSC 是元件之間的互動規則，像是A和B可以被定義如下： 其中C 是一個主要元件A和候選元件B之間的複合安全性契約。E → R 指出 E 造成R或E滿足R。現存的CSC中的Required or ensured 安全性屬性可以被寫成CA,B.RB或 CA,B.EA ，且任一個元件可能含有一個或多個CSC。 安全性描述架構最重要的議題是如何使元件的安全性描述和元件之間的CSC可行。相關CSC更詳細的說明在參考資料9。 二、延伸的UML註記與標示 一個UML模型包含不同的圖形像是使用個案圖、類別圖和循序圖等等，任一個圖形說明著一個軟體開發設計層級的角度。在這些圖形中，循序圖描述了彼此的相互作用以及明確的時間順序。因此，我們選擇最適合本篇文章提出方法PSRL的圖形，循序圖，作為描述安全性需求的圖形。 Macro工具提供使用者用簡單清楚的術語，沒有複雜的數學公式，增進了使用性。為了描述安全性需求，使用者只需要知道相對應的macro與其參數。我們的方法因此以結合PSRL macros與UML循序的的方式說明。 UML不只提供安全性需求描述的各個結構還提供的延伸機制來加入額外的模型元素。UML comment box 機制更提供了彈性。根據不同類型的安全性需求，它們必須能在UML的不同元素中用tags來傳遞。在PSRL中，安全性需求被應用在軟體中的互動性。在UML中，相對應的參數化macros在循序途中被分配到適當元件的tags中。圖六說明了UML循序途中PSRL macros的使用，其中comment box 視覺化了tag的數值，而虛線說明了所連接的元件。 主要元件U 從一個信任的元件C 中購買貨物。U 傳送一個訂單給C 以作為確認。在收到了C 的確認後，U 在貨物系統中將該確認電子化地傳送給候選元件M 做價格的報價。 元件C 不只滿足了元件U 的required安全性屬性，也滿足了U 的ensured安全性屬性。基於這些安全性屬性，產生的CSC (CU,C) 則可以達成U 和 C 需求的一致性。因此屬性最後的結果被儲存在U的 CSC 庫做更進一步的使用。Fig. 6 說明了U 和 C之間產生的CSC結果。 三、圖形轉換與驗證 為了驗證模型中保密性的程度，我們試著轉換UML中的循序圖變成一個簡單易懂而且可驗證的圖形，User Sys-tem Interaction Effect (USIE) 模型。在我們的方法中，我們標記自己的CSC在USIE模型的線中，而這有別於原先的USIE模型。 一個 USIE 模型組成包含兩種節點InteractionStart 和 RoleEntity。 InteractionStart 節點代表著循序途中互動的開頭， RoleEntity 節點則代表著循序途中的一個角色實體。USIE模型中的節點可以直接從相對應的循序圖中轉換。USIE圖形中的線有方向性，並且任一條線都含有屬性。如上面提到的，我們在USIE線中加入了CSC註記。線中的屬性包含了三種類別： NoAttribute、ChangeState和ReturenInformation，且線中的屬性可以被相對應的循序圖中取得。 我們說明一些會被使用來定義USIE模型的基本註記，以及有更詳細的註記說明在圖四及圖三使U = (N, E, <) 代表一個USIE模型，其中N是一系列的節點而E是一系列的線，其 < 則是E 中的方向關係[11]。我們使用Na 來說明模型中的一個節點，其中a 是節點名稱；並使用Ei.Cx,y 來說明模型中的線，其中i 是一個非負數的數字代表著順序，而Cx,y 則是實體x 和 y 之間的CSC。圖八說明了UML的循序圖，而圖九則是它相對應的USIE模型。在圖九中，我們省略了安全性屬性為一清晰的概念轉換圖。 在圖九中，使用者(企業裡的員工)，需要訂購貨物，該流程則被表示在一分散式系統中。首先，使用者需要確認傳送它的需求。透過收取需求，企業系統則會儲存該訊息到記錄系統中，若成功並回傳確認訊息。當使用者從企業取得確認訊息，該訊息則會被自動地傳送到採購系統做預算的統計。該採購系統需要辨識該訊息，也就是驗證該和核可訊息。經過成功驗證後，採購系統會送回預算系統的訊息。 因此，來自信任端CU,C的確認訊息會被使用在CU,R的ensured安全屬性中。所以我們可以驗證使用者與採購系統中的CU,R 滿足驗證性。從圖九萃取出的驗證結果可以被表示在圖九中。當USIE模型被建立，我們可以使用衡量方式來計算他們的保密性程度....(本文待續，下期「論根據圖形使用延伸的UML驗證軟體設計缺點(下)」中，將再深入說明架構應用及相關應用，敬請拭目以待。) 參考資料 1.H. Abie, D.B. Aredo, T. Kristoffersen, S. Mazaher, and T. Ra-guin, “Integrating a Security Requirement Language with UML,” Proc. 7th Int’l Conf. on the United Modeling Language (UML 2004), pp. 350-364, 2004. 2.A. Apvrille and M. Pourzandi, “Secure Software Development by Example,” J. IEEE Security & Privacy, vol. 3, no. 4, pp. 10-17, July-Aug. 2005. 3.“CERT Statistics,” Pittsburgh, CERT CC, http://www.cert.org /stats/cert_stats.html, Aug. 2008. 4.A. Chatzigeorgiou, N. Tsantails, and G. Stephanides, “Applica-tion of Graph Theory to OO Software Engineering,” Proc. 2nd Int’l Workshop on Interdisciplinary Software Engineering Research, pp. 29-35, 2006. 5.R.B. France, D.K. Kim, S. Ghosh, and E. Song, “A UML-Based Pattern Specification Technique,” IEEE Trans. Software Engi-neering, vol. 30, no. 3, pp. 193-206, Mar. 2004, doi: 10.1109/ TSE.2004.1271174. 6.D.P. Gillian, T.L. Wolfe, and J.S. Sherif, “Software Security Checklist for the Software Life Cycle,” Proc. Twelfth IEEE Int’l Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’03), pp. 243-248, 2003. 7.C.B. Haley, R.C. Laney, and B. Nuseibeh, “Deriving Security Requirements from Crosscutting Threat Descriptions,” Proc. Third Int’l Conf. Aspect-Oriented Software Development, pp. 112-121, 2004. 8.C.B. Haley, R. Laney, J.D. Moffett, and B. Nuseibeh, “Security Requirements Engineering: A Framework for Representation and Analysis,” IEEE Trans. Software Engineering, vol. 34, no. 1, pp. 133-153, Jan/Feb 2008, doi:10.1109/TVCG.2007.70754. 9.K.M. Khan and J. Han, “Composing Security-Aware Soft-ware,” J. IEEE Software, vol. 19, no. 1, pp. 34-41, 2002. 10.Z. Lin, B. Mao, and L. Xie, “A Practical Framework for Dy-namically Immunizing Software Security Vulnerabilities,” Proc. First Int’l Conf. on Availability, Reliability and Security (ARES’06), pp. 8, 2006. 11.Y. Liu and I. Traore, “UML-based Security Measures of Soft-ware Products,” Proc. Int’l Conf. on Application of Concurrency to System Design (ACSD 2004), pp. 31-43, 2004. 12.G. McGraw, “Software Security,” J. IEEE Security & Privacy, vol. 2, no. 2, pp. 80-83, Mar-Apr. 2004. 13.N.R. Mead and G. McGraw, “A Portal for Software Security,” J. IEEE Security & Privacy, vol. 3, no. 4, pp. 75-79, July-Aug. 2005. 14.B. Potter and G. McGraw, “Software Security Testing,” J. IEEE Security & Privacy, vol. 2, no. 5, pp. 81-85, Sept-Oct. 2004. 15.K.R. van Wyk and G. McGraw, “Bridging the Gap between Software Development and Information Security,” J. IEEE Se-curity & Privacy, vol. 3, no. 5, pp. 75-79, Sept-Oct. 2005. 16.M. Watson, UK ADS-B in a Radar Environment, EUROCON-TROL, 2006, presentation slides, http://www.eurocontrol.int/ cascade/gallery/content/public/documents/Presentations/S-ession%202%20-%20Trials%20and%20Implementations/Wats-on%20-%20UK%20ADS-B%20in%20a%20radar%20environme-nt.pdf, 2007.