教你如何避免威脅建模7大“坑”

什麼是威脅建模？

開放Web應用程式安全專案（OWASP）將威脅建模描述為“用於識別、量化和解決與應用程式相關的安全風險的結構化方法”。它本質上涉及在構建或部署系統時，戰略性考慮的威脅，因此在應用程式生命週期的較早階段就可以實現對預防或減輕威脅的適當控制。

威脅建模讓企業對最可能影響系統的各種網路威脅進行系統性識別和評價。有了這些資訊，企業就可以按照一定的邏輯順序，利用適當的對策來處理現存的威脅，並且從具有最大風險的威脅開始。

威脅建模主要包括三大主要元素：

· 資產：應保護哪些有價值的資料和裝置

· 威脅：攻擊者可能對系統實施的行為

· 漏洞：有哪些漏洞讓攻擊者對系統構成威脅

事實上，威脅建模當然並非什麼新概念，但卻很少有組織以認真的態度去實現它。ThreatModeler Software公司創始人兼執行長ArchieAgarwal認為，威脅模型的最佳實踐仍在不斷湧現。他說，

最大的問題是缺乏對威脅建模的理解。其實存在很多種方式來實施威脅建模，但是公司在構建的過程中仍然感到困難重重，主要原因是，企業對於威脅建模的整體構建過程缺乏清晰地認識，企業無法確定如何將其視為一個流程，以及如何擴充套件它。

根據Agarwal和其他一些安全專家的說法，人們在進行威脅建模時可能易犯如下七種錯誤：

威脅建模7大坑

1.過於以應用程式為中心

Agarwal指出，組織在構建威脅模型時，最易犯的錯誤之一就是隻關注應用程式本身。他說，對於威脅建模而言，企業應該嘗試瞭解整體情況，而不僅僅是一個孤立的應用程式。
企業還需要考慮基礎架構、資料庫、共享元件、第三方互動和部署環境等因素。威脅可能會因應用程式是內部部署還是正在雲端執行，或可以通過移動裝置和其他計算端點訪問而有所不同。
如果企業正在轉向雲端計算，則需要雲端計算的威脅模型。企業的應用程式和資料是否會執行在專用的基礎架構或共享伺服器和資料庫上呢？需要記住的是，當威脅建模時，企業不僅需要關注應用程式，還需要關注與應用程式相關的所有事情。開發人員在構建應用程式和部署應用程式時，需要考慮到一些修復時會遇到的問題。

2.關注漏洞而不是威脅

IDC分析師PeteLind strom表示，組織可能犯的一個錯誤就是過分關注漏洞，而對威脅關注不足。檢視資料流和控制流，並確定應用程式中可能存在哪些漏洞是非常重要的步驟。此外，企業需要更加明確地檢視威脅，並確定輸入和輸出的位置，以便清楚地瞭解自己可能將面臨的風險。企業還需要儘可能地考慮到所有攻擊可能，以防攻擊者破壞您的控制元件，影響資料的機密性、完整性、可用性、生產力和專有性。
Lindstrom解釋稱，

現在，人們正在談論‘熔斷’（Meltdown）和‘幽靈’（Spectre）對於資料保密性的嚴重影響。但是，其對於資料完整性或可用性影響如何呢？攻擊者是否有能力操縱這些記憶體表或插入資料？需要謹記的是，企業有針對特定漏洞的控制措施，而這並不意味著攻擊者不會找到利用漏洞的新方法。

3.過分關注實時威脅

SANS研究所新興安全趨勢總監John Pescatore表示，在構建威脅模型時，不要過分追求最新的威脅，或過分關注特定的威脅參與者或行為型別。勒索軟體和加密軟體可能是當前對企業安全性影響最大的威脅。但是，企業不要專門針對這些威脅進行建模，而要專注於控制，以緩解影響系統機密性、完整性、可用性的任何威脅。
Pescatore繼續道，同樣地，針對企業的威脅究竟是否來自中國、俄羅斯或是塞爾維亞的行為者並不重要。因為無論他們是誰，都明確地知道如何實踐自己的攻擊操作。對於企業而言，最重要的是要知道面臨這些威脅時應該怎麼辦。

企業的重點應該放在建立可重複的流程上，以便能夠在每次發生變故時及時做好應對準備。完成這一過程的關鍵，是擁有一套標準的流程或方法，無論威脅的新穎性如何，該流程/方法每次都能以相同的方式完成。此外，企業還需要知道自己想要保護什麼，以及從哪裡開始落實。

4.威脅建模的威脅對映錯誤

Agarwal說，如果企業對於構建威脅模型的想法，只是制定一系列威脅名單，並檢視企業的應用是否存在任何威脅，那麼可以說，其所做的一切只是“威脅對映”（threat mapping）而已。他舉例解釋道，

假設您有一個線上銀行應用程式，並且問了一系列問題，諸如‘你在使用Flash嗎？’或‘你在使用Java嗎？’亦或‘你在做認證嗎？’那麼可以肯定地說，您在這裡做的並不是威脅建模，因為您沒有圍繞威脅的上下文/背景。您不知道自己是如何使用Flash的，或者正在哪裡使用Flash。

Agarwal表示，同樣地，僅僅因為您有一個資料庫，並不意味著您必須擔心SQL隱碼攻擊問題。只有當一個從外部源接收輸入的web應用程式時，SQL隱碼攻擊才會成為潛在的問題。當您採用清單方法評估威脅時，這種細微差別很容易被忽略。

要構建適當的威脅模型，架構圖很關鍵。它應該顯示資料庫、Web伺服器、作業系統層以及應用程式將執行並通過其訪問的基礎結構。它還應該顯示所有資料和通訊的流向，入口點的位置以及來自這些入口點的輸入。可以說，架構圖能夠同時為您展示全域性和邊緣視角。

5.不將使用者引入威脅模型

企業通常存在這樣一種情況：由於過於關注對手如何攻擊自己的程式碼，而忽略了他們可以通過其他方式來訪問您的應用程式和資料。Pescatore認為，

模擬惡意行為者攻擊程式碼的方式，對於威脅建模而言是一個非常好的主意。但是，防範網路釣魚攻擊卻並非是企業可以構建的。

企業需要將使用者納入威脅模型，並考慮使用者操作可能影響安全性的不同方式。企業需要檢視特權管理和基於角色的訪問等內容。當使用者訪問超出其許可權或涉及機密資訊的系統時，企業需要考慮其可能造成的潛在威脅。

6.對威脅建模採取“一成不變”的方法

威脅模型不能是靜態的。企業不能只挑一個重要的應用程式，只對其構建一次威脅模型，就認為自己已經完成了整個威脅建模任務。只要您的企業像大多陣列織一樣，存在持續開發的活動，那麼企業的應用程式一定會發生變化，當然，其威脅配置檔案也是如此。這就意味著，企業目前的威脅模型將在三個月內過時。

所以，要將威脅建模看成一個不斷迴圈的過程。您的威脅模型應當是動態模型，應隨著時間的推移不斷更改，以適應發現的新型威脅與攻擊。它還要能夠適應應用程式為適應業務變更的需求而不斷完善與更改的自然發展過程。

7.不考慮系統對他人的影響

當構建一個威脅模型時，最好考慮一下數字可信度。如果說，您已經瞭解了自己所面臨的所有威脅，並找出了控制或減輕它們的方法，那麼接下來請看看貴組織的系統將會如何影響與之接觸的其他人。

Lindstrom表示，企業需要注意自己的產出如何影響他人的安全狀態。舉例來說，企業可能會安置一個黑市網站，或者有人可能會劫持企業的域名，或將DDoS資料包從企業的物聯網系統中彈出。企業可能不會接受廣告攔截器，但是如果其網站上的惡意廣告感染客戶系統會發生什麼情況？當企業將內容或應用放到網上時，其責任是保持它們的安全和乾淨，以便下游使用者不會受到感染。無論是從數字可信度還是責任角度來看，這也需要成為威脅建模的一部分。

作為威脅建模練習的一部分，企業需要確保瞭解與開源軟體和第三方元件相關的風險，而不僅僅是針對自身企業，還需要包括企業服務的下游使用者。例如，如果企業提供混搭服務，則需要考慮您的資料或服務如何影響其他人的輸出。如果別人依賴來自企業的GPS資料，那麼企業則需要考慮資料的完整性和可靠性等問題。

原文釋出時間為：2018-06-8

本文來自雲棲社群合作伙伴“嘶吼網”，瞭解相關資訊可以關注“嘶吼網”。