基於威脅建模的業務安全保障方法
什麼是威脅建模
所謂威脅，通常是指系統的安全漏洞，可能存在於系統的具體實現上，也可能存在於系統的安全策略配置上。安全漏洞往往給攻擊者提供了非授權的訪問和攻擊系統的入口點，達成控制或者破壞系統的目的。
業務風險是一種典型的威脅， ofollow,noindex">如航旅業務往往面臨機票爬取、惡意佔座等業務風險 ，如不能對業務風險進行有效控制，會影響業務正常開展，增加經營成本。
威脅建模是使用抽象的概念來分析系統可能存在的風險。如在業務安全這個維度，通過定位攻擊目標和可利用的業務安全漏洞來提高系統安全性，然後定義防範或減輕系統業務風險的對策的過程。
從某種意義上來說，在日常生活中，我們潛意識中也在不停的實踐著威脅建模。我們會關注每天的天氣和氣溫變化，如果氣溫驟降，就會做出添衣的決策，如果第二天下雨的概率很大，就會做出帶把傘出門的決策，從而達到降低患上感冒的可能性。
為什麼要做威脅建模
完善軟體系統功能設計中的安全設計部分
絕大部分的開發團隊都使用系統需求分析文件、軟體系統設計文件以及功能模組詳細設計文件來規範系統的開發和測試過程；整個開發週期中，只在測試階段引入滲透測試或者安全程式碼審計來提高交付的系統的安全性。
但是，因為設計階段就缺少安全部分的分析設計工作，往往導致滲透測試和安全程式碼審計工作事倍功半，收效甚微。測試人員無法根據缺乏安全設計的設計文件來估算安全測試用例的覆蓋度；研發人員也無法針對發現的威脅快速並高效的提供解決威脅的開發修復途徑和安全產品採購需求。
系統化和量化威脅分析和解決過程
安全程式碼審計和滲透測試是兩種最為常見的發現威脅以提高系統安全性的方式。但是這兩種方式都具備類似的缺點：很難系統化和量化系統的安全性。威脅模型更關注哪些方面可能出現安全問題，通過建模的方式將威脅抽象化和結構化，以圖表幫助確定威脅的範圍，並利用表格和列表的方式來追蹤和更新威脅，實現在開發過程或者運維過程中識別和管理威脅。
提供安全測試的設計和執行的指導
我們使用軟體測試來對軟體產品和階段性的開發結果來進行質量檢驗，力求發現其中的各種缺陷，並督促缺陷得到修復，從而控制軟體產品的質量。作為軟體測試中的一個環節，安全測試的關注點是安全缺陷，保障的是軟體產品的安全性質量。
軟體測試可以使用軟體的需求分析和定義、軟體系統設計、模組詳細功能設計甚至具體編碼實現來指導測試的設計和執行。同樣，通過威脅建模，可以在安全測試的設計和執行中獲得以下指導：軟體系統可能會面臨哪些方面的安全威脅；系統正在遭遇哪些方面的威脅；以及系統現狀能夠抵禦哪些方面的威脅。
提供安全缺陷修復驗證的指導
威脅建模是為了交付安全性更高的軟體、服務或者技術。因此，在找到和定位威脅之後，如何處理和管理威脅也是威脅建模不可或缺的一個部分。威脅建模能夠權衡解決威脅的策略，並指導系統的開發者使用哪些技術和系統配置方式來處理髮現的各類威脅。與功能測試報告相似，表格和列表也可以應用於整體威脅建模漏洞的跟蹤。
如何做威脅建模
下圖是微軟通過實踐過程提出的威脅建模的過程。首先需要預設場景，在場景中，我們需要考慮具體的業務特徵、真實用例以及場景中所用的產品；圖表化能夠幫助我們理解業務場景和系統，以及定位威脅的攻擊面；然後我們需要藉助特定的模型和方法來發現威脅並對發現的威脅進行評級；在處理威脅階段，我們優先處理攻擊難度低並且危害程度的威脅；最後，驗證階段，需要測試是否已經對相關威脅進行有效的處理，達到威脅建模的結果收斂，系統的安全性有效提高。
從安全形度理解正在構建的系統
威脅建模通常從三個維度來建立模型：以資產為核心、以攻擊者為核心、以軟體系統為核心。在實踐中使用哪種建模方式往往根據系統構建者的關注點來決定的。風控或者業務部門關注的可能更多的是資產或者有價值的東西；安全部門關注的更多的是攻擊者，通過利用攻擊庫列表來尋找系統威脅；研發部門關注的更多的是正在構建的軟體或者部署的系統，將威脅模型作為常用的軟體開發模型的補充，來提高軟體系統的安全性。
圖表是幫助我們理解系統的最為趁手的武器。我們通常使用資料流圖（data flow diagram）、統一建模語言UML、狀態圖來理解正在構建的系統。
而當我們在進行威脅建模的時候，我們會將圖表應用於以下三個步驟來理解系統：
a、確認系統資料流模型
b、確認信任邊界
c、確認攻擊面
資料流模型是進行威脅建模的最佳模型，這是因為安全問題往往是在資料流中出現，而不是在控制流中。程序、資料流、資料儲存和外部實體是資料流圖的四個基本要素。下圖顯示的是一個典型的資料流圖模型。
程序：執行中的程式碼，如服務、元件；用圓角矩陣或圓形圖形表示。
資料流：外部實體與程序、程序與程序或者程序與資料儲存之間的互動；用箭頭表示。
資料儲存：儲存資料的內部實體，如資料庫、訊息佇列、檔案等；用中間帶標籤的兩條平行線表示。
外部實體：系統控制範圍之外的使用者、軟體系統或者裝置；用直角矩陣表示。
航旅系統某應用場景資料流圖
在資料流圖確認後，我們需要引入信任邊界對資料流圖進行改進。信任邊界是不同主體匯聚的位置，即實體與其他不同許可權實體之間互動的位置。信任邊界是識別威脅的最佳位置，因為大部分的威脅往往具備跨越邊界的行為，劃分信任邊界的資料流是需要進行威脅分析的元素例項。
對某應用場景的資料流圖引入信任邊界
在確認資料流圖的信任邊界後，我們可以很容易就得到當前場景暴露的攻擊面。攻擊面往往就是一個信任邊界，使攻擊者可以發動攻擊的地方。
找出系統中可能會出現的威脅
藉助業務場景資料流圖和信任邊界的劃分，我們已經對威脅最容易發生在那些地方有了一定的概念，接下去我們需要做的是找出這些威脅點可能會出現哪些具體的威脅。
STRIDE方法是由微軟開發和推廣的用於威脅建模的工具，該方法將威脅分為6個維度來進行評估，幾乎能夠覆蓋目前的絕大部分安全問題。STRIDE是六個單詞的縮寫，分別為：
Spoofing：假冒，偽裝，冒充他人身份。
Tampering：篡改，非法修改資料或者程式碼內容。
Repudiation：否認，否認自己的行為，宣稱自己沒有做過某事。
Information Disclosure：資訊洩露，獲取到自身許可權本不能獲取的資訊。
Denial of Service：拒絕服務攻擊，消耗系統資源，影響系統的可用性。
Elevation of Privilege：提權，獲取到更高的系統許可權。
結合資料流圖的基本元素，使用STRIDE方法作為威脅維度來對各基本元素進行威脅分析，可以得出以下表格：
表格所描述的是作為基本元素會面臨哪些維度的威脅。比如外部實體可以被偽造，並否認自己發起的行為。資料儲存幾乎不會被偽造，但是往往面臨資料被篡改，機密資料洩露以及被拒絕服務攻擊使不能服務的威脅，同時，資料儲存是否會面臨否認的威脅需要根據資料儲存的用途，當資料儲存用於審計的場景下，可能會面臨偽造的威脅。
接下去我們可以使用該表格對具體業務場景進行業務風險分析，如對本文上述航旅某業務場景中的各個要素進行潛在威脅定位，可以得出以下表格：
在使用STRIDE方法分析完特定業務場景下資料流圖中的所有元素示例的潛在威脅以後，我們已經得到一個抽象的威脅定位圖表。接下去我們需要根據攻擊庫來進行威脅列舉，對各個潛在威脅構建威脅描述和攻擊方法，並輸出一個威脅列表，對每一個威脅項進行描述。
頂象技術在航旅、電商等現實業務攻防中積累下來的資料和經驗，累積了豐富的業務風險攻擊庫和相應的防護方法，以威脅編號T1和T4舉例輸出威脅項描述如下所示：
對可能會出現的威脅評級並處理
使用STRIDE方法對業務場景的資料流圖分析完畢後，我們已經獲取到當前系統在該業務場景下所面臨的潛在威脅。接下去我們就需要一個個處理這些威脅。
在我們確認威脅處理方法之前，我們不得不以 “妥協”的想法認清一些現實：首先，有一些威脅是無法根除的，我們只能降低這些威脅發生的機會，或者提高威脅發生的門檻；其次，有一些威脅雖然存在，但是發生的概率很低，而且一旦發生，帶來的危害也很小。我們需要找到一些機制來判斷是否真的需要投入成本去修復這些漏洞。
正因為如此，我們需要採用威脅評級的方式，對我們定位出的威脅項進行評分，然後根據系統的實際情況和評分結果來權衡處理威脅的方式，是解決威脅還是緩解威脅或者接受威脅。
威脅評級有很多種方式，如DREAD與CVSS（Common Vulnerability Scoring System）方法。不同評級方法對威脅進行評級的維度和風險等級的計算方法會略有不同，但是總體來說，威脅的級別等於威脅發生的概率乘以威脅帶來的潛在損失。在實際事件中可以根據系統或者業務場景特徵選擇合適的評級方法甚至對其進行調整使其適應實際情況。
DREAD風險模型的計算方式：
威脅等級[忽略(0),嚴重(10)]=（危害性[0,4]+復現難度[0,4]+利用難度[0,4]+受影響使用者[0,4]+發現難度[0,4]）/2
以威脅編號T4舉例，其威脅等級計算過程如下：
危害性（Damage）：3分：洩露機密資料，或資金損失較大。
復現難度（Reproducibility)：1分：很難復現，復現成功率較低，需要多種因素限制並對技術有較高要求。
利用難度（Exploitability）：2分：熟練攻擊者可攻擊，需自定製指令碼或高階攻擊工具。
受影響使用者（Affected Users）：1分：一般邊緣業務的少量使用者；
發現難度（Discoverability）：1分：發現漏洞很困難，可以通過猜測或者監測網路活動來發現。
因此威脅編號T4的威脅等級 = （3+1+2+1+1）/ 2 = 4，中危級別，威脅的處理方法為使用HTTPS協議代替HTTP協議進行資料傳輸，或使用頂象技術裝置指紋和風控引擎產品，對使用者登陸事件獲取實時安全防護。
輸出威脅項中威脅級別和威脅處理方法如下所示：
類似過程可輸出威脅編號T1的威脅級別和威脅處理方法如下所示：
在對所有的潛在威脅例項進行威脅評級和威脅處理方法舉例之後，我們可以根據系統的業務特徵，選擇合適的方式來處理潛在威脅。
結語
威脅建模是一種方法論，也是一種分析模型，它並不是針對風險的解決方案。但是通過對軟體或系統的威脅建模，可以幫助系統的構建者找出最適合系統和業務場景的風險解決方案。
威脅建模提供了一組規範的工具和方法用來幫助我們處理系統中潛在的安全風險，交付更安全的系統。最理想的情況是，我們在開始構建系統的時候，將安全需求分析引入系統需求分析步驟，在系統概要設計和詳細涉及階段引入威脅建模分析部分，並將其作為測試階段安全測試工作的指導，輸出測試報告的同時輸出安全報告。
在現實中，很多已經上線的系統依然面臨著各種的潛在威脅和業務風險，頂象技術在 航旅 、 電商 等現實業務攻防中依靠積累下來的資料和經驗，累積了豐富的業務風險攻擊庫和相應的防護措施，通過對現有業務系統的威脅建模，輸出全鏈路、多環節縱深風控體系，能有效保障業務的健康運營。