威脅建模易犯的7個錯誤

Jaikumar Vijayan 楊勇

對于希望通過借鑒實踐案例來加強其網絡和服務安全的企業而言，相對不太成熟的威脅建?？赡軙砗艽髥栴}。

開放Web應用程序安全項目（OWASP，Open Web Application Security Project）把威脅建模描述為一種結構化的方法，用于識別、量化和處理與應用程序相關的安全風險。這實際上涉及在構建或者部署系統時應從戰略角度考慮威脅問題，這樣，在應用程序生命周期的早期階段就實施適當的防御和減輕威脅的控制措施。

威脅建模當然不是什么新概念，但很少有企業能夠以有意義的方式來實現它。ThreatModeler軟件公司的創始人兼首席執行官Archie Agarwal評論說，威脅模型的最佳實踐仍處于初始階段。他說：“最大的問題是缺乏對威脅建模究竟是什么的理解。”進行威脅建模有多種方法，而企業常常遇到的問題是怎樣從過程的角度來弄清楚它，以及怎樣進行擴展?！八幸磺腥匀欢疾磺逦！?/p>

據Agarwal和一些其他人的說法，在進行威脅建模時可能會犯下7個錯誤：

1.過于以應用程序為中心

Agarwal指出，企業構建威脅模型時最常犯的錯誤之一就是只關注應用程序本身。他說，對于威脅建模，應該試著從整體上去理解，而不僅僅是一個個孤立的應用程序。

應考慮基礎設施、數據庫、共享組件、第三方交互和部署環境。威脅會因為不同的場景而有所不同，例如，應用程序是在現場還是在云中運行，還是可以通過移動設備和其他計算端點進行訪問，等等。

如果你要遷移到云中，則需要云的威脅模型。你的應用程序和數據會在專用基礎設施或者共享服務器和數據庫上運行嗎？Agarwal指出，關鍵要記住的是，在威脅建模時，不僅要關注應用程序，還需要關注涉及到它的所有一切。開發人員在開發應用程序時應考慮一些修補程序，部署應用程序時則要考慮應處理哪些操作。

2.重視漏洞而忽略了威脅

IDC分析師Pete Lindstrom指出，企業可能犯的一個錯誤就是過于關注漏洞，而忽視了威脅。查看數據流和控制流并知道應用程序中可能存在哪些漏洞，這當然非常重要。然而，更需要明確有哪些威脅，并確定識別可能存在風險的輸入和輸出。應該考慮攻擊者對企業的控制進行攻擊的所有可能，這會影響數據的機密性、完整性、可用性、工作效率和私有性。

Lindstrom說：“現在我們正在談論Meltdown和Spectre漏洞攻擊導致的機密泄露。但是完整性和可用性呢？攻擊者有辦法操縱這些內存表或者插入數據嗎？”如果你僅僅控制了某個特定的漏洞，并不意味著攻擊者找不到利用漏洞的新方法。

3.過分關注于當天的威脅

SANS研究所新興安全趨勢總監John Pescatore認為，在建立威脅模型時，不要急于應對最新的威脅，或者過于關注某一威脅攻擊者和攻擊者的類型。勒索軟件和加密挖礦軟件可能會對企業的安全造成當前最大的威脅。但是沒必要專門針對這些威脅建模，而應把重點放在控制上，以緩解對系統的機密性、完整性和可用性的任何威脅。

Pescatore說，同樣，如果針對企業的威脅是來自俄羅斯或者塞爾維亞的攻擊者，這真的并不重要。與其把重點放在查找黑客和犯罪團伙在哪里，是否是由國家支持的，不如知道怎樣防范他們所造成的威脅?！凹词贡桓嬷嵌砹_斯攻擊者在攻擊你，也不如知道該怎么辦更重要。”

重點應該是構建可重復的過程，這樣，每次出現變化時，企業都做好了準備。關鍵是要有一個標準的過程或者方法，不管威脅有多新，每次都以同樣的方式進行處理。Pescatore說，企業應該知道想要保護什么，并從那里開始。

4.將威脅映射誤認為威脅建模

Agarwal指出，如果建立威脅模型的想法是處理一系列威脅，看看自己的應用程序是否有這些威脅，那么你所做的就只是威脅映射。Agarwal說，“假如你有一個網上銀行應用程序，你會問一系列的問題，比如‘你使用Flash嗎？，或者‘你使用java？，‘你進行身份驗證嗎？”。在這里，你所做的不是威脅建模，因為你沒有去真正了解威脅的環境。你不知道怎樣使用Flash，不知道在哪里使用它。

同樣，僅僅因為有數據庫并不等于就可以不用擔心SQL注入會成為攻擊途徑。只有在Web應用程序接受來自外部源的輸入時，SQL注入才成為潛在的問題。Agarwal說，當采用檢查表的方法來評估威脅時，會很容易忽略這種細微的差別。

構建適當的威脅模型，關鍵在于體系結構圖。它能顯示數據庫、Web服務器、操作系統層，以及將運行應用程序的基礎設施，通過這些基礎設施來訪問應用程序。它應該顯示所有數據的位置和通信流，入口點在哪里，以及這些入口點有什么類型的輸入。Agarwal說，體系結構圖為可顯示出全局和邊緣的情形。

5.沒有把用戶引入到威脅模型中

實際情況是，過于專注于對手怎樣攻擊代碼，而不太關注他們獲取應用程序和數據所采取的其他方法。Pescatore說：“建立犯罪分子怎樣攻擊代碼這樣的威脅模型是個不錯的主意。但對網絡釣魚攻擊的防范是無法構建到應用程序中的?！?/p>

Pescatore指出，應該把用戶引入到威脅模型中，并考慮用戶行為可能影響安全性的不同方式。你需要查看權限管理和基于角色的訪問等內容。當用戶訪問云中的應用程序，或者通過作為更大的電子商務解決方案組成部分的移動設備訪問應用程序時，還需要考慮潛在的威脅。

6.采取一次性的方法進行威脅建模

威脅模型不可能是靜態的。Agarwal提醒說，對于一個關鍵的應用，不可能一次性地為其做一個威脅模型，然后想當然地認為一切就都做好了。如果你的企業和大多數企業一樣，一般都會進行持續的研發活動。那么當應用程序發生變化時，其威脅情形也會發生變化。這意味著當前的威脅模型一般只能適用三個月。Agarwal說：“威脅模型應該是一個實時的文檔。你不能只是建立一個威脅模型，然后就把它忘了。要記住，企業的應用程序一直在工作?！?/p>

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

在構建威脅模型時，最好考慮一下數字可信度。一旦你了解了所面臨的所有威脅，弄清楚了控制或者緩解的方法，應該看看你的系統會怎樣影響與其接觸的其他人。

IDC的Lindstrom說，應該注意到企業的輸出可能會影響他人的安全態勢?！袄纾憧赡軙谝粋€黑市網站上駐留，有人就可能會非法占用你的域，或者讓你的物聯網系統發出DDoS數據包。”你可能不接受廣告攔截器，但是如果你的網站上的惡意廣告影響到客戶系統，那該怎么辦？當你把東西放在網上時，你的責任是保持它們干凈，這樣下游用戶使用你的系統時才不會受到影響。Lindstrom說，無論從數字誠信還是責任的角度來看，你在威脅建模時都應該努力去這樣做。

作為威脅建模練習的一部分，應確保自己熟悉并了解與開源軟件和第三方組件相關的風險，不僅對你的部門，而且對你服務的下游用戶也是如此。例如，如果你要提供插件，就應該考慮你的數據或者服務可能會影響其他人的輸出。Lindstrom指出：“如果其他人依賴于你提供的GPS數據，那么就需要考慮這些數據的完整性和可靠性?！?/p>