【第161期 January 31, 2011】
 

研發新視界

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

作者/莊力吉

[發表日期:2010/12/28]


架構的應用


《圖一》The transitive CSC in USIE model


我們以一個例子來展示安全性需求的架構,並說明與原先架構之間的差異,故我們決定延伸使用“CRISTAL UK”中的專案為我們的例子。航空交通控制專案著重在“determining the role of ‘passive surveillance’ in NATS (National Air Traffic Services) future surveillance sys-tems”,其中包含一些關於監控技術的議題,像是ADS-B (Automatic Dependent Surveillance - Broadcast), WAM (Wide Area Multilateration), and Combinations of ADS-B with radar.

Air Traffic Control (ATC) 負責飛機安全並有效的導航機制,其中不同的監控技術被使用來降低意外的風險。被動的監控技術在CRISTAL 專案中稱為ADS-B ,該技術需要飛機在三維空間中主動傳送他們的位置。該專案定義了如果在ADS-B報告則可能式一個可靠的來源。為了更明確的說明我們的方法,並比較原先的架構,我們採用這個應用的方法來探討軟體設計的漏洞。較詳細的監控技術說明,請看參考資料8中的Appendix A。

我們的方法基於參考資料8,而前三個步驟則會在下面章節中檢視,其為Phase 1。位置的安全性需求可以透過這些活動一步一步的建立在圖五中。剩餘的步驟及討論會在下文中說明。

一、安全性需求分析

在Phase 1,我們需要建構適當的安全性需求,而該程序則會透過“CRISTAL UK”的專案一步步說明。


《圖二》The sequence diagram of position report.


  • Step 1-辨識功能性需求. 在這個步驟中,我們辨識系統的功能性目的、系統的概要與功能性需求。功能性需求幾乎都是從功能性目的中產生,而該CRISTAL專案初始的功能性目的則是在參考資料8中賦予。其中功能性目的為︰

    FG1: Provide safe and efficient air traffic management.

    而我們則同樣從參考資料8中取得功能性需求︰

    FR1: Provide positions of aircraft.

    飛機的位置當飛行時將會被傳送到ATC系統,而飛機則會要求GPS回覆飛機的座標。飛機上的GPS接收器會擷取飛機的位置並傳送到ADS-B接收器。該接收器則會傳送接收到的位置到機器中,而該機器則會在需要的時候重新傳送到ATC系統。


  • Step 2-辨識安全性目的. 在這個步驟中,我們從系統概要中的資產辨識安全性目的,像是一般目的的直接與間接的資產。一般的目的則是保密性、完整性和可用性。直概要中直接的資產是GPS訊號、飛機的位置和ATC系統限制授權的操作等等。間接的資產則是飛機上的乘客、飛機擁有者的利益和ATC固有的設備資產等等。首先,我們可以藉由一般性目的參考資料8來定義威脅描述參考資料7:
    • General goal: confidentiality

      T1: {publicizing, airplanes’ position, facilitating terrorist attack}
      T2: {publicizing, airplanes’ position, lost of business secrets}

      原先專案因為該威脅在專案的範疇之外,故選擇忽略威脅T1和T2,旦我們仍將該威脅納入考量因為對於我們的架構有更好的說明。

    • General goal: integrity
      T3: {~correct, airplanes’ position, lost asset due to crash or collision}
      T4: {~correct, airplanes’ position, lost revenue due to in-creased distance}

    •  General goal: availability
      T5: {~available, airplanes’ position, lost asset due to crash or collision}
      T6: {~available, airplanes’ position, lost revenue due to in-creased distance}

      安全性目的將辨識為防止威脅描述中的上列事件。因此安全性目的被簡化為下列︰

      SG1: Protect positions from unauthorized part (avoids T1 and T2)
      SG2: Have correct positions (avoids T3 and T4)
      SG3: Report positions timely (avoids T5 and T6)

    現在我們已經有三個安全性目的來進行下一個步驟,每一個安全性目的則防止特定的威脅。


  • Step 3-辨識安全性需求. 在這個步驟中,我們合併了安全性目的與功能性需求來產生限制的功能性需求。根據這個規則,我們必須獲得三個安全性需求︰

    SR1: [FR1: Provide position of aircraft]: positions shall be authenticated.

    航空控制服務應該避免任何人為因素的利用,像是恐怖,而飛機與ATC系統的相互驗證機制是最重要的考量。因此,飛機的位置應當被驗證並且後果也須被納入考量。SR1 操弄 SG1.

    SR2: [FR1: Provide position of aircraft]: positions shall be accurate.

    The NATS 對於精確度的需求是指飛機必須離所回報的位置只有300米內的誤差。SR2 操弄 SG2.

    SR3: [FR1: Provide position of aircraft]: positions shall be timely.

    The NATS 對於時間的需求是指每一個回報的距離都間距4到6秒內或是飛機進入受控制的領空。SR3 操弄 SG3.

    透過安全性目的來辨識安全性需求後,可以根據我們的方法來建構安全性需求以分析兩元間之間的安全性以及結構層級的保密程度。

二、安全驗證性需求

在Phase 2中,我們利用PSRL來描述前段所辨識出的安全性需求並建構USIE模型來驗證它的保密性。

  • Step 1-整合安全性需求與延伸的UML圖形. 在這個步驟中,我們定義安全性需求並使用PSRL來建構。系統綱要的本體則是GPS、飛機、ADS-B、Machine、ATC系統和員工。SR1 說明了位置(訊息)的驗證性需求,並且我們可以應用這個macro,MessageAuthentication到SR1、SR2和SR3。該macro msgAuth, 是MessageAuthentication的縮寫,代表著下列的定義:



    SR1的需求是驗證訊息,SR2的需求是位置的精確性,而SR3的需求則是時間在合理的區間內。因此,macro可以滿足這三個安全性需求,並在Step 2中驗證是否滿足。

    任一本體的安全性需求可以被描述如下,我們取下列例子做說明:






    《圖三》USIE model derived from 圖二

    根據Phase 1的系統綱要,我們可以描述出相對應的循序圖。系統綱要中的任一元件會被轉換成循序途中的實體,像是GPS、飛機、ADS-B、Machine、ATC和員工。任兩個本體產生的CSC會被寫進comment box中的標籤而標籤的類型則為 “CSCBase”。循序途中的位置回報流程標示在圖二中。


  • Step 2-驗證安全性需求是否滿足安全性目的. 在這個步驟中,我們藉由分析應用在安全性需求中的macro來驗證安全性需求是否滿足安全性目的。Macro msgAuth 是非對稱式加密系統,所以我們可以說該macro滿足了驗證性與完整性。在這個macro msgAuth中,繫結了時間戳記,可以用來辨識訊息交換的時間性。所以安全性需求SR1、 SR2和SR3可以滿足安全性目的SG1、 SG2和SG3。


  • Step 3-建構USIE模型以分析資訊洩漏管道. 在這個步驟中,我們從圖二中的循序圖建構USIE模型。在USIE模型中,我們修改了線上的符號以便於輕易地分辨整個模型的保密性。建構好的USIE模型請看圖三,其中標記了CSC轉換形式以便後續步驟做驗證。我們可以看到本體飛機和ATC系統之間的虛線,說明了CSC的驗證,而遞移的CSC已在參考資料9中被驗證過。圖三說明了如果本體透過授權驗證後的訊息,仍可以被本體續續使用該訊息的本體所驗證。單一的USIE模型可以說明整個航空回報位置的概要,但我們需要另一個USIE模型來驗證保密洩漏的程度。


    《圖四》The crew sequence diagram.



    《圖五》Information leakage channel from IPositionReport to ICrewReadPosition


    為了驗證整個流程的保密性,我們假設一個地勤員工可以存取ATC系統來讀取飛機的位置,那麼crew 與系統的互動可以被標示在圖四。

    若是缺少了驗證的機制,沒有權限的crew 也許可以存取飛機的位置。這兩個USIE模型被標示在圖五,然後需要檢視任何一條邊線的屬性,特別是前一個與後一個是否可能導致資訊洩漏管道的出現。我們使用符號S 來代表significant 資訊洩漏管道,以及公式 Conf (IA → IB)著重在significant 資訊洩漏管道。在我們的例子中,從惡意建置的過程中容易導致安全性的缺失,可以在圖二中看到。 圖五說明了crew存取了存放在公共區域的資料而位置則視為參數,會產生未預期的資料流S。Crew 與ATC系統的互動會允許沒有權限的crew 存取機密資料。


  • Step 4-從模型中驗證保密性. 在這個步驟中,我們分析圖五中的USIE模型,根據資訊洩漏管道來計算IPositionReport與ICrewReadPosition的保密性。圖五中的USIE模型有一條資訊洩漏管道,我們使用公式Conf (IPositionReport → ICrewReadPosition)來計算它的保密性。該參數NOSILC (IPositionReport, ICrewReadPosition) 說明了significant資訊洩漏管道的個數而公式的值須為 1。而後我們得到Conf (IPositionReport → ICrewReadPosition) 的值為 0.5,說明了圖五的保密性。為了解決位置可能會被未授權員工來存取,我們加入Authenticate 來避免,並解決資訊洩漏管道的問題,該方法表示在圖五。另一種設計在圖六由循序圖說明,而crew 的循序圖在圖七。


    《圖六》Secure design of position report.



    《圖七》Crew read position under authenticated mechanism.



    《圖八》USIE model derived from 圖六


    驗證機制可以避免未授權的存取,而USIE模型的安全性設計被標示在圖八。我們可以在圖八中獲得Conf (IPosi-tionReport → ICrewReadPosition) 的值1,且代表著是一個安全的系統。圖九總結了兩個設計的統計度量值。


    《圖九》METRICS VALUES
    Conf = Confidentiality, I = InteractionStart.


    此外,我們獲得額外的資訊,像是CSC的安全性需求。新的實體Authenticate 的CSC安全性需求可以被標示如下:



    當然,實體ATC 與Crew 的CSC在增加了實體Authenticate後應該需要被修改。最後,我們證實了元件層級與結構層級的漏洞可以被增進。首先,增加Authenticate 的解決方法幫助驗證本體來預防機密資料被未授權的本體所存取。第二,安全性設計提供了有效的安全性來防止機密資料透過資訊洩漏管道被存取。因此,在我們的架構中同時滿足了元件層級與結構層級上的安全性。

討論

此節闡述了在應用我們的架構中產生的幾個議題。我們使用PSRL來建構安全性需求,並用一個實際例子來驗證軟體設計保密性,其例子是來自於我們根基於的journal文章。

其中有幾點需要在應用我們架構的時候做探討。第一點,我們前三個步驟基於參考資料8所提出的,而為了比較所以選擇相同的例子。因此,在前三個步驟中,我們從參考資料8獲得了功能性目的、功能性需求、安全性目的和安全性需求。

第二點,我們提出用來建構安全性需求為CSC的PSRL根基於參考資料1和參考資料9。原先SRL最適合的範疇在參考資料9提到,並在ISO/IEC-15408被分類為11種Common Criteria。我們假設原始的SRL可以被應用到所有類型,且我們取用一個子集合的安全性類型user data protection來作架構的說明。

結論

此篇文章為了安全性需求工程提出了一個架構,其中系統綱要中的安全性目的以及功能性需求產生的安全性需求的影響,設計的限制都被納入考量,且透過PSRL使用在CSC中來建立安全性需求的正確性。

在目前的工作中,可以被納入考量的是系統建構的安全性目的。該步驟通常是最容易被忽略的,而重要性卻是不可缺少的一環。專案在進行的初步階段,其實可以運用這樣的架構來檢視整體流程,甚至是細部元件的資訊交換能否被驗證,以及所代表的安全性是否合乎安全性目的。

安全性目的會依照不同的需求有所調整,像保密性及完整性通常會取其一,為了達到完善的保護或者是資料的健全,可以使效率稍微降低的允許程度都是需要被考量的依據。

更多的未來探討可以集中在如何將各種領域的安全性皆能以目前的架構做說明。

參考資料

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.