威脅分析的建議

適用于此 Azure Well-Architected Framework 安全性檢查清單建議:

SE:02 建立符合合規性需求、業界標準和平臺建議的安全性基準。 定期根據基準測量工作負載架構和作業,以持續或改善一段時間的安全性狀態。

相關指南保護開發生命週期的建議

識別威脅、攻擊、弱點和計數器量值的完整分析,在工作負載的設計階段非常重要。 威脅模型 化是一種工程練習,包括定義安全性需求、識別和緩和威脅,以及驗證這些風險降低措施。 您可以在應用程式開發或生產的任何階段使用這項技術,但在新功能的設計階段最有效。

本指南說明執行威脅模型化的建議,讓您可以快速識別安全性缺口,並設計您的安全性防禦。

定義 

詞彙 定義
SDLC) (軟體發展生命週期 用於開發軟體系統的多階段系統化程式。
大步 Microsoft 定義的分類法,用於分類威脅類型。
威脅模型化 識別應用程式和系統中潛在安全性弱點、降低風險及驗證安全性控制措施的程式。

主要設計策略

威脅模型化是組織應該整合到其 SDLC 的重要程式。 威脅模型化不只是開發人員的工作。 這是在:

  • 工作負載小組,負責系統的技術層面。
  • 業務利害關係人,他們瞭解業務成果,並對安全性有不良興趣。

組織領導階層和技術小組之間通常會中斷與重要工作負載商務需求之間的連線。 此中斷連線可能會導致不必要的結果,特別是針對安全性投資。

當工作負載小組執行威脅模型化練習時,應該同時考慮商務和技術需求。 工作負載小組和商務專案關係人必須同意工作負載的安全性特定需求,才能對因應措施做出適當的投資。

安全性需求可作為整個威脅模型化程式的指南。 若要讓它成為有效的練習,工作負載小組應該具備安全性思維,並在威脅模型化工具中定型。

瞭解練習的範圍

清楚瞭解範圍對於有效威脅模型而言非常重要。 它有助於將心力和資源放在最重要的領域。 此策略涉及定義系統的界限、清查需要保護的資產,以及瞭解安全性控制所需的投資層級。

收集每個元件的相關資訊

工作負載架構圖表是收集資訊的起點,因為它提供系統的視覺標記法。 此圖表醒目提示系統的技術維度。 例如,它會顯示使用者流程、資料如何透過網路移動、資料敏感度層級和資訊類型,以及身分識別存取路徑。

此詳細分析通常可提供設計中潛在弱點的深入解析。 請務必瞭解每個元件及其相依性的功能。

評估潛在威脅

從外部觀點分析每個元件。 例如,攻擊者如何輕鬆取得敏感性資料的存取權? 如果攻擊者取得環境的存取權,他們是否可以橫向移動,甚至可能存取或甚至操作其他資源? 這些問題可協助您瞭解攻擊者如何利用工作負載資產。

使用產業方法分類威脅

分類威脅的其中一種方法是 STRIDE,Microsoft安全性開發生命週期會使用此方法。 分類威脅可協助您瞭解每個威脅的本質,並使用適當的安全性控制。

減輕威脅

記錄所有已識別的威脅。 針對每個威脅,定義安全性控制措施,並在這些控制項失敗時回應攻擊。 定義流程和時程表,將工作負載中任何已識別弱點的暴露程度降到最低,讓這些弱點無法保持未新增。

使用 假設缺口 方法。 這有助於識別設計中所需的控制項,以在主要安全性控制失敗時降低風險。 評估主要控制項失敗的可能性。 如果失敗,潛在組織風險的範圍為何? 此外,補償控制項的有效性為何? 根據評估,套用深度防禦措施來解決安全性控制的潛在失敗。

以下為範例:

詢問此問題 若要判斷控制項...
透過Microsoft Entra識別碼、傳輸層安全性 (TLS) 與相互驗證的連線,或安全性小組核准的另一個新式安全性通訊協定進行驗證:

- 在使用者與應用程式之間?

- 在應用程式元件和服務之間?
防止未經授權的應用程式元件和資料存取。
您是否限制只有需要寫入或修改應用程式中資料的帳戶存取權? 防止未經授權的資料篡改或改變。
應用程式活動是否已透過 Azure 監視器或類似的解決方案記錄並饋送至安全性資訊和事件管理 (SIEM) 系統? 快速偵測並調查攻擊。
重要資料是否受到安全性小組核准的加密保護? 防止未經授權複製待用資料。
輸入和輸出網路流量是否透過 TLS 加密? 防止未經授權複製傳輸中的資料。
應用程式是否透過 Azure DDoS 保護等服務,防止分散式阻斷服務 (DDoS) 攻擊? 偵測設計來多載應用程式的攻擊,使其無法使用。
應用程式存放區登入認證或金鑰是否可存取其他應用程式、資料庫或服務? 識別攻擊是否可以使用您的應用程式來攻擊其他系統。
應用程式控制是否可讓您滿足法規需求? 保護使用者的私人資料,並避免合規性問題。

追蹤威脅模型化結果

強烈建議您使用 威脅模型化工具。 工具可將識別威脅的程式自動化,並產生所有已識別威脅的完整報告。 請務必將結果傳達給所有感興趣的小組。

在工作負載小組待辦專案中追蹤結果,以及時允許責任。 將工作指派給負責降低威脅模型所識別之特定風險的個人。

當您將新功能新增至解決方案時,請更新威脅模型,並將其整合到程式碼管理程式中。 如果您發現安全性問題,請確定有一個程式可根據嚴重性將問題分級。 此程式應該可協助您判斷何時以及如何補救問題 (例如,在下一個發行週期或更快速的發行) 。

定期檢閱業務關鍵工作負載需求

定期與主管贊助者開會,以定義需求。 這些檢閱提供機會來配合預期並確保作業資源配置給方案。

Azure 指導

Microsoft 安全性開發生命週期提供威脅模型化工具,以協助進行威脅模型化程式。 這項工具可供免費使用。 如需詳細資訊,請參閱 威脅模型化頁面

範例

此範例是以資訊安全 基準 (SE:01 ) 中建立的資訊技術 (IT) 環境為基礎。 這種方法可讓您廣泛瞭解不同 IT 案例的威脅環境。

此圖顯示具有威脅環境之組織安全性基準的範例。

  1. 開發生命週期角色。 開發生命週期涉及許多角色,包括開發人員、測試人員、最終使用者和系統管理員。 所有專案都可能會遭到入侵,並透過刻意建立的弱點或威脅,讓您的環境面臨風險。

  2. 潛在的攻擊者。 攻擊者會考慮隨時輕鬆使用的各種工具,以探索您的弱點並啟動攻擊。

  3. 安全性控制。 在威脅分析中,找出要用來保護您的解決方案的 Azure 安全性服務,以及這些解決方案的有效性。

  4. 記錄檔收集。 來自 Azure 資源和某些內部部署元件的記錄可能會傳送至 Azure Log Analytics,因此您可能會瞭解所開發解決方案的行為,並嘗試擷取初始弱點。

  5. SIEM) 解決方案 (安全性資訊事件管理。 Microsoft Sentinel 甚至可能會在解決方案的早期階段新增,因此您可以建置一些分析查詢來減輕威脅和弱點,並預期您在生產環境中的安全性環境。

  6. Microsoft Defender for Cloud可能會提出一些安全性建議,以改善安全性狀態。

Open Web Application Security Project (OWASP) 已記錄應用程式的威脅模型化方法。

安全性檢查清單

請參閱一組完整的建議。