前言
與其說網頁應用程式的威脅模型(Threat Modeling)，不如說是網頁應用程式的弱點(Vulnerability)或風險(Risk)模型較能完整表達接下來我們所要談的有關如何架構安全的網頁應用程式的一個重要過程。開發者通常會有些錯誤的想法，總認為使用了SSL或採用了流行的程式語言開發網頁程式就是安全的，但卻不知安全的網頁應用系統牽涉的範圍很廣，包含你的網頁應用系統的架構、主機本身的安全(例如Web主機、應用程式伺服器及資料庫主機)、應用程式使用的技術、資料交換傳遞及儲存、資料輸入輸出等都可能對你的網頁應用系統造成不同程度的風險。另外，我們也可以用資訊安全的三要素: Confidentiality (機密性) 、Integrity(完整性) ，以及 Availability (可行性)，或稱作CIA Triad，來分析你所設計的網頁應用系統的安全，重點是要有一個風險評鑑的手法與過程。

如圖一，我們先看一下所謂的風險(Risk)與威脅(Threat)、弱點(Vulnerability)及資產(Asset)三者間交互的關係。

圖一

如一所示，風險可以是三者的關係式，風險 = 威脅(Threat) X 弱點(Vulnerability) X 資產(Asset)。從駭客攻擊的角度來看，風險的分類等級可以根據弱點本身能被利用的難易程度(Simplicity), 攻擊者利用此弱點進行攻擊的技術水準(Popularity)及對此系統所造成的衝擊(Impact)來計算弱點所屬風險等級。高風險(High Risk)弱點若被利用可能讓不具經驗的攻擊者直接取得管理者權限,導致系統中斷,拒絕服務攻擊,執行命令,敏感資訊的揭露等；中風險(Medium Risk)弱點若被利用可能讓梢有經驗的攻擊者直接取得非管理者層級權限,但攻擊者可利用進一步的hacking技術來取得管理者權限；低風險(Low Risk)弱點若被利用可能讓具有經驗的攻擊者間接取得某種等級的使用者存取權。

表一

威脅分析模型的流程
通常使用七個階段處理流程來執行應用系統風險評鑑。第一個步驟是要了解你的資訊安全目標是甚麼，你所要進行的評估的範圍是哪些標的，管理階層對此威脅分析的期望是甚麼，關鍵的Business Function及重要的資產是甚麼，客戶對此網頁應用系統的期望及需求是甚麼等等。第二個步驟是建立架構概觀，使用系統架構圖的方式記錄應用程式架構。第三個步驟是分解應用程式的架構，確認應用程式的設計，包括認證、驗證機制及相關子系統。第四個步驟是識別潛在威脅及弱點，識別可能會影響所使用的伺服器及應用程式的潛在威脅及可能弱點。第五個步驟是分析可利用資訊資產弱點之威脅，可以使用OWASP Top 10 網頁應用程式弱點列表及SANS Top 20弱點列表來分析可利用資訊資產弱點之威脅及威脅的目標。第六個步驟需計算威脅的衝擊及等級並研擬處理方案，計算潛在威脅的等級以排定風險處理優先順序，通常是先針對最嚴重的風險等級。 最後一個步驟是撰寫風險評鑑報告以提供高階主管執行風險處理決策之參考。
在應用程式設計階段其實就是為你的系統設計一份Blueprint，Developers需要事先收集各種要求，再將這些Requirements轉換為文件然後開始定義系統的各項功能。威脅模型的分析是利用所設計的應用系統所模擬產生出的Data Flow 觀察應用系統的資料流，再根據本章所提的DREAD評鑑標準來找出可能的潛在威脅。威脅模型分析裡面用的 Data Flow也可算是UML方法的一部分。通常在以上的七個步驟中，要完整分析網頁應用系統的威脅(Threat Profiles)及弱點是比較複雜的一個階段，但它也是最中要的一環。經由Threat Modeling所分析出來的文件可以提供架構師或軟體測試人員一個系統安全的概觀。你可以選擇使用NIST或OCTAVE所定義的風險評估方法來分析這些威脅，理論上所有可能的跟全部系統架構相關的威脅及產生的影響都列示出來當然可以提供相關系統開發及測試人員最完整的資訊，但過多資訊也可能會使系統開發過於繁複，超量的Threat Modeling文件更可能將開發及安全測試人員淹沒。這裏我要介紹的是使用Misuse Cases Scenario的方式來進行，經由找出跟設計面及功能面相關的威脅並針對此威脅找出解決方法。例如：針對使用者忘記密碼這樣的案例，它可能導致的攻擊可能有SQL Injection、拒絕服務攻擊或密碼暴力破解攻擊。Misuse Case Scenario的方法可以幫助程式開發人員更了解駭客入侵系統的方法，開發出更安全的網頁應用程式。

潛在威脅及弱點列表可使用Laundry list或STRIDE模型來列示，亦可考慮使用威脅樹(Threat Tree)的結構加以列示。另外您也可以思考以下跟密碼安全相關的威脅：是否訂定使用者註冊及註銷程序？於系統管理或特殊作業需要，如需設定特殊權限時，是否訂有嚴格管理控制措施? 是否要求使用者對其個人密碼應盡保密責任？是否嚴格管制使用者初次登入電腦系統後必須立即更改預設之密碼？對於忘記密碼之處理，是否有嚴格的身份確認程序？預設之密碼是否以規定之安全程序轉交於使用者，使用者取得密碼確認無誤後需回應系統管理者？使用者存取權限是否定期檢查或在權限變更後立即複檢？密碼長度是否超過六個字元？密碼是否規定需有大小寫字母、數字及符號組成？密碼輸入錯誤，是否訂有次數之限制？應用系統是否具有作業結束後或在一定期間未操作時即自動登出之保護機制？使用者註冊資料是否予以列管並隨時更新？是否定期檢查並刪除重覆或閒置的使用者識別碼？ 一般來說，有很多工具及風險評鑑方法可以達成類似的工作，例如我們也可以藉由掃瞄應用系統的方式找出曝露風險與違反政策的行為、安排資源分配的優先順序以及降低風險，快速、精準地找到所有您應用系統上的弱點與違反政策的行為，並針對其嚴重性安排優先處理順序。並可在資產價值、弱點嚴重性、威脅急迫性與因應對策中取得平衡，將防護重點放在最重要的資產上。管理者可稽核各組修補績效及了解各個function面在應用系統的弱點修補所面臨的困難。

計算威脅的衝擊及等級並研擬處理方案
風險分級是在潛在威脅模型過程的最後階段，用於排序已識別出的潛在威脅的優先順序。必須定義尺規及風險水準計算原則，可考慮使用DREAD模型來幫助計算風險。使用 DREAD 模型，可以經由提出下列問題來得到指定潛在威脅的風險等級：

使用以上的項目來評定每個潛在威脅的等級。使用簡單的方式，例如：高 (1)、中 (2)、低 (3)。風險水準由資訊資產因潛在威脅利用已知的弱點而對網路、主機及應用系統產生的衝擊程度來決定。 例如標示出潛在威脅所產生衝擊的 DREAD 分級：根據風險尺規，計算潛在威脅的風險值，接著計算DREAD衝擊後的結果，然後就可以將總和評量為 12–15 的潛在威脅視為高風險， 8–11 視為中風險， 5–7 視為低風險。請參考圖二。接著著手風險處理方案，依據風險計算結果研擬風險處理方案，一般分為以下幾種：

圖二

• • • 接受風險: 確認資訊資產所面臨的風險並接受可能的風險。
    • 避免風險: 避開可能的風險。
    • 轉移風險: 將風險轉嫁於第三方(如保險公司或其他主管單位執行。
    • 處理風險: 參考企業的資訊安全管理規範及基礎安全防護措施、ISO 27001資訊安全管理作業要點之控制目標與控制或其他可處理風險的解決方案。

圖三顯示出一個風險降低的例子，風險無法完全消除，必須以成本效益的方法來處理風險。

圖三

最後撰寫風險評鑑報告，報告內容包括潛在威脅、威脅發生的潛在目標、風險等級及相關風險處理因應對策等，以提供高階主管執行風險處理決策之參考。報告內容一般包含如下內容。

• • 風險評鑑目的
    • 管理階層的期望
    • 資訊安全政策
    • 系統有變動
    • 新的弱點及威脅發生時(系統商有公告與開發系統相關的新弱點或新威脅)
  • 資訊資產清冊
• 資產名稱
• 資訊安全衝擊
  • 威脅表列
    • Misuse Case Scenario列表
    • OWASP的十大應用程式弱點或其他應用系統威脅列表
  • 風險計算結果
    • 尺規及風險評估結果
  • 風險評鑑報告
    • 處理方案說明表及建議採取措施

參考文件

• Improving Web Application Security: Threats and Countermeasures, MICROSOFT SECURITY DEVELOPER CENTER, Microsoft Corporation, Published: June 2003

• ISO/IEC 17799:2002 CODE OF PRACTICE FOR INFORMATION SECUITY MANAGEMENT