了解威脅模型化
威脅模型化是 Microsoft 安全性開發生命週期 （SDL） 的核心元素，也是建置安全應用程式的基本安全性做法。 這是一種工程技術，可協助您系統地識別可能影響應用程式的威脅、攻擊、漏洞和對策。
什麼是威脅建模
目的： 威脅建模提供結構化方法來了解應用程式中的安全風險。 威脅建模不會希望您已經想到所有可能的安全問題，而是引導您完成識別和解決威脅的系統流程。
好處： 您可以使用威脅模型來：
- 塑造應用程式設計： 根據安全考慮引導架構決策，而非事後才考慮安全性。
- 達成安全目標： 確保您的應用程式符合組織的安全目標和合規性要求。
- 降低風險： 透過在設計過程中識別和解決威脅而不是在生產中發現威脅，系統地降低安全風險。
- 優先處理安全工作： 將安全工作集中在最重大的威脅上，而不是試圖一次解決所有問題。
- 傳達安全問題： 為開發人員、安全性小組和利害關係人提供通用語言來討論安全性。
無障礙： 該方法的設計考慮了非安全專家。 所有開發人員，而不僅僅是安全專家，都可以透過提供明確的指導來建立和分析威脅模型，進行威脅建模。
五個階段的威脅建模過程
威脅建模遵循系統的五個階段過程：
1. 定義安全需求
建立安全目標： 在分析威脅之前，請先釐清安全性對應用程式的意義：
保密要求：
- 哪些資料必須保密？
- 誰應該有權存取敏感資訊？
- 資料必須保密多久？
- 違反保密規定的後果是什麼？
誠信要求：
- 必須保護哪些資料或作業免遭未經授權的修改？
- 如何檢測數據是否被篡改？
- 違反誠信的後果是什麼？
可用性要求：
- 需要哪些正常運行時間保證？
- 不同組件可接受的停機時間是多少？
- 無法使用對業務有何影響？
合規要求：
- 適用哪些監管要求（GDPR、HIPAA、PCI DSS 等）？
- 必須滿足哪些行業標準（ISO 27001、SOC 2 等）？
- 客戶有哪些合約安全義務？
範例需求： “客戶付款信息必須保密。 只有授權的支付處理系統才能存取這些資料。 必須記錄所有存取以供稽核之用。 資料必須在傳輸和儲存時加密。
2. 建立應用圖
視覺化您的架構： 建立代表應用程式架構的圖表，顯示：
系統組件：
- Web 伺服器、應用程式伺服器、資料庫、微服務。
- 您的應用程式所依賴的外部服務和 API。
- 身份驗證和授權系統。
- 負載平衡器、快取層、訊息佇列。
資料流程：
- 資料如何在元件之間移動。
- 每個連線傳輸哪些資料。
- 資料流的方向。
- 資料轉換點。
安全邊界：
- 權限等級變更時的信任邊界。
- 不同安全區域之間的網路邊界。
- 不同執行環境之間的程序邊界。
- 不同位置或雲之間的物理邊界。
範例元素：
- 通過互聯網連接的用戶。
- 網路邊緣的 Web 應用程式防火牆。
- DMZ 中的 Web 伺服器。
- 受保護網路中的應用程式伺服器。
- 高度限制網路中的資料庫伺服器。
- 用於處理交易的外部支付網關。
3. 識別威脅
系統化威脅識別： 使用結構化方法來識別潛在威脅：
STRIDE 方法論： STRIDE 是一個威脅分類框架：
- 詐騙：涉及身分識別模擬的威脅。
- 竄改：涉及未經授權的資料修改威脅。
- 否認性：使用者拒絕執行動作的威脅。
- I資訊揭露：涉及未經授權的資訊存取的威脅。
- 拒絕服務：防止合法使用者存取系統的威脅。
- E權限提升：使用者獲得未經授權的存取權限的威脅。
將 STRIDE 套用至資料流程： 檢查圖表中的每個資料流程，並考慮每個 STRIDE 類別的適用方式：
- 攻擊者可以偽造此數據的來源嗎？
- 這些數據在傳輸或存儲過程中會被篡改嗎？
- 是否可以否認此資料流的合法操作？
- 敏感資訊可以透過此流程揭露嗎？
- 此流程是否可用於導致阻斷服務？
- 是否可以利用此流程來取得高級權限？
常見威脅範例：
- SQL 注入： 攻擊者透過未經清理的使用者輸入（篡改、資訊洩露、權限提升）來操縱資料庫查詢。
- 會話劫持： 攻擊者竊取會話令牌來冒充使用者（欺騙、權限提升）。
- 中間人： 攻擊者攔截元件之間的通訊（資訊洩漏、竄改）。
- DDoS 攻擊： 攻擊者用流量使系統不堪重負（拒絕服務）。
4. 減輕威脅
制定對策： 針對每個已識別的威脅，制定適當的風險降低措施：
緩解策略：
- 除： 如果不是必需的，請完全移除易受攻擊的元件或功能。
- 預防： 實施控制措施使威脅不可能發生（例如，透過輸入驗證防止注入攻擊）。
- 發現： 實施監控和警報以檢測威脅利用嘗試。
- 回答： 制定威脅被利用時的事件回應程序。
緩解措施範例：
- SQL 注入威脅： 使用參數化查詢和輸入驗證來防止注入攻擊。
- 會話劫持威脅： 使用 HTTPS、安全 cookie 和短會話逾時實作安全會話管理。
- 中間人威脅： 對所有通訊強制執行 TLS 並實作憑證釘選。
- DDoS 威脅： 使用基於雲端的DDoS防護服務，並實施速率限制。
文件決策： 記錄緩解決策，包括：
- 哪些威脅受到了解決？
- 選擇了什麼緩解方法。
- 為什麼這種方法合適。
- 誰負責實施。
- 任何剩餘的風險。
5. 驗證風險降低措施
驗證有效性： 實作風險降低之後，請驗證它們是否能有效解決已識別的威脅：
安全測試：
- 滲透測試以驗證威脅無法被利用。
- 安全程式碼檢閱，以確認已正確實作風險降低措施。
- 自動安全掃描以檢測遺漏的漏洞。
- 紅隊演習以測試針對現實攻擊場景的防禦。
持續驗證： 威脅和緩解措施演變：
- 隨著技術的變化，新的威脅也隨之出現。
- 現有的緩解措施可能會變得無效。
- 應用程式變更可能會引入新的漏洞。
開發生命週期中的威脅模型化
正在進行的過程： 威脅建模不應該是一次性活動。 它應該是您典型的開發生命週期的一部分：
初始設計： 在初始應用程式設計期間進行全面的威脅建模，以影響架構決策。
功能開發： 在新增變更安全界限或引入新資料流程的重要新功能時執行威脅建模。
定期更新： 隨著威脅形勢的演變，即使沒有重大變更，也應定期檢閱和更新威脅模型。
事件回應： 在安全事件發生後更新威脅模型，以納入經驗教訓。
漸進式降低風險： 這種迭代方法使您能夠完善威脅模型並隨著時間的推移逐步降低風險，而不是嘗試一次解決所有風險。
Microsoft Threat Modeling Tool
Microsoft 提供免費工具，讓威脅模型更易於存取和結構化：
目的： Microsoft 威脅模型化工具透過視覺化系統元件、數據流程和安全性界限的標準標記法，讓所有開發人員都能更輕鬆地進行威脅模型化。
自動威脅識別： 該工具可幫助威脅建模者根據其軟件設計的結構識別他們應該考慮的威脅類別。 當您建立應用程式圖表時，工具會根據您定義的元件和資料流程自動建議潛在威脅。
主要功能： 威脅建模工具使任何開發人員或軟體架構師能夠：
溝通安全設計：
- 建立系統架構的視覺化表示。
- 使用安全團隊和開發人員理解的一致表示法。
- 記錄與安全性相關的架構決策。
- 與利害關係人共用威脅模型以進行審查和回饋。
分析設計：
- 使用經過驗證的方法 （STRIDE） 識別潛在的安全問題。
- 根據應用程式結構自動產生威脅清單。
- 根據嚴重性和可能性確定威脅的優先順序。
- 從安全性的角度比較不同的設計替代方案。
管理減輕措施：
- 針對已識別的威脅提出緩解措施。
- 追蹤緩解實施狀態。
- 記錄安全性決策和理由。
- 產生安全審查和合規性報告。
開始使用：
- 該工具是免費的，可從 Microsoft 下載。
- 它包括常見應用程式類型的範本。
- 內建指引可協助新使用者學習威脅模型概念。
- 與 Azure DevOps 整合可讓您將威脅連結至工作專案。
其他資源
如需威脅模型化的詳細資訊，請參閱：