如何進行威脅模型分析

IT 系統非常複雜，而且爲了帶來商業價值並提升客戶滿意度和參與度，它需要承載根兒更多功能，複雜性也隨之提升。這意味著 IT 設計決策需要考慮越來越多種類的用例，並將可能造成業務衝擊的安全威脅也納入考量，例如未經授權訪問數據、服務阻斷 (DoS) 和資源濫用。
這種複雜性加上用例的各種排列組合，讓未結構化的手段難以有效發掘並消除威脅。唯有系統性的枚舉潛在威脅，設計緩解措施，並排定其優先順序，才能確保浥注的有限資源能對工作負荷的整體安全產生最大效益。威脅模型分析旨在提供系統性方法，於設計階段發掘並緩解問題，其修復成本也低於等待至開發後期才處理。
AWS Well-Architected Framework 明確將威脅模型分析列爲最佳實務，並透過安全性支柱中，基礎安全領域裡的 SEC1 進行檢驗。

威脅模型分析應針對單一工作負載 (Workload) 或功能 (Feature) 進行，以確保上下文 (Context) 與評估模型相符。

根據過往的經驗，所有威脅模型分析方法皆遵循下列步驟：

1. 確定資產 (assets)、參與者 (actors)、入口點 (entry points)、元件 (component)、用例(use case) 和信任級別 (trust level)，並以設計圖描述。
2. 發掘威脅並製表。
3. 對每一項威脅設計緩解措施，可包含安全控制實現。
4. 透過創建風險矩陣 (risk matrix) 判斷威脅是否已充分緩解。
要更深入地瞭解與這些步驟相關的一般實踐，建議您閱讀 SAFECode 戰術威脅模型分析白皮書和開放 Web 應用程式安全專案 (OWASP) 威脅模型分析備忘單。這些指南是您在選用特定方案時的絕佳材料。他們也參照可加速威脅模型分析過程的工具和方法，包括以 OWASP Threat Dragon 專案創建威脅模型圖，或使用 OWASP Top 10、OWASP 應用程式安全驗證標準 （ASVS） 和 STRIDE 以確定潛在威脅。您可以混用上述方法，也可以創建自己的組合。

威脅模型分析應該在設計階段進行。通常在這個階段，您會繪製架構圖並創建非生產環境，以啓發並設計生產環境。由於威脅模型分析在設計階段執行，它會早於代碼審查、代碼分析（靜態或動態）和滲透測試。這些項目在安全生命週期中，比較晚才進行。
在設計工作負載時，請儘早開始考慮潛在威脅 -- 通常是在白板 (Whiteboarding) 或紙上設計時的階段。每次設計新功能或變動既有功能時，都應該重新分析威脅模型，因為這些變動可能會帶來新的威脅，需更新威脅模型以跟進。

威脅模型分析需要細部構思、腦力激盪、協作和溝通。其目的爲消弭應用程式開發、運營、業務和安全之間的差距。成功沒有捷徑，但我們發現下列項目對威脅模型分析的採用和成功至關重要。

威脅模型分析是一項「團隊運動」，它需要多元化團隊的知識和技能，而每個面向都同等關鍵。對於本文中列出的所有角色，我們建議從從最終客戶的期望開始，然後反向思考建構(Working Backward)。客戶對此工作負載與功能有何期望，包含其安全性，與如何在功能和可用性間取得平衡。

我建議團隊涵蓋以下視角，每個人可以代表其中多於一項角色：

• 業務角色 – 爲了確保討論中的工作負載或功能保有業務價值，需要有人替業務成果發聲。此人應該對工作負載的功能與非功能需求有充分了解，並確保討論中的緩解措施不致過度影響需求。如果提議的安全控制（緩解措施）使應用程式需求”不再可用”或”功能不足”，團隊應持續尋求安全性和功能間的平衡點。
• 開發人員角色 – 他們理解工作負載功能的設計，且深入參與迄今的設計決策。他們參與了設計腦力激盪與白板討論，且對設計中的威脅與配套緩解措施有所認知。倘若該應用程式不由內部團隊開發（例如 COTS 應用程式），則以「內部應用程式管理者」取代此類角色。
• 攻擊者角色 – 攻擊者會嚴格審視工作負載設計，尋找其中設計缺陷以達成特定目標，像是未經授權的數據共用。這邊的「攻擊」係透過想象，而不是真實入侵。如果您的組織裡有紅隊編制，他們會非常適合這個角色；如果沒有，可以從安全運營或工程團隊裡挑選，或委由專精該領域的第三方廠商擔任。
• 防禦者角色 – 防禦者會將攻擊者準備的「攻擊」視為潛在威脅，並設計安全控制將其緩解。此角色還評估這些緩解措施在持續運營支援、監控與事件回應等面向，是否方面是否容易操作。
• AppSec SME 角色 – 應用程式安全 （AppSec） 主題專家 （SME） 角色應最熟悉威脅模型分析過程和討論審核方法，且具有深厚的IT安全知識和經驗。透過主持討論，該角色確保分析進程順利，並確保安全性和交付成果間妥善取得平衡，是以對威脅模型分析至關重要。這個角色負責批准產出的威脅模型，並提議後續驗證項目，例如滲透測試與其範圍。
  

我們在前面的段落中，探討了常見的威脅模型分析方法。比起選擇哪一種方法，在團隊內部或團隊間，一致的使用同一種方法更加重要。

通過使用一致的方法和格式，團隊可以更快地行動並更準確地估計工作量。同仁可以將自身或其他團隊開發的威脅模型作爲示例，從中學習，從而避免從頭開始摸索。

團隊可以參照過去執行威脅模型分析的耗時，並以過去經驗作爲基礎，來估計執行分析所需時間與工作量，其結果也更爲準確。

除了使用一致的方法和格式之外，建模威脅的粒度與相關性的一致性也是關鍵。我們會在後面段落探討如何創建威脅目錄，並在組織內部重複利用。

最重要的是，一致的方法容易規模化：如果正在進行分析的工作負載引入的某項元件已有威脅模型，該威脅模型或安全控制便可以被重用。藉由創建元件與威脅模型的相依性，後續分析可奠基於既有威脅模型，從而消除重複的工作。

您的應用程式開發團隊已經具有特定的工作流和交付風格。如今，敏捷風格的交付最受歡迎。確保用於威脅模型分析的流程與交付方法及工具能妥善整合。
就像任何其他可交付結果一樣，爲威脅模型分析創建使用者故事 (User Story)，並在衝刺 (Sprint)、長篇故事 (Epic) 或待解工作 (Backlogs) 中，與工作負載功能一同排程。

您的應用程式開發團隊已經在使用一些工具來支持軟體交付。這通常包含文檔協作（例如，團隊 Wiki），與問題跟蹤工具，用於記錄軟體開發生命週期中的所有工作成果。安全審查和威脅模型分析工作流應使用相同的工具。

既有工作流工具可用於提供和查看反饋、分配任務、並查看工作負載功能對應的威脅模型分析，與其交付狀態。將威脅模型分析整併入既有工作流，可以減少推廣該類分析的摩擦力，最終變得和單元測試、QA 測試或工作流的其他典型步驟一樣普遍。

通過使用常見的工作流工具，負責創建和審閱威脅模型的成員可以異步工作。例如，當威脅模型審閱者添加反饋時，作者會收到通知，並在有時間時處理，無需安排時間設立會議。這也讓 AppSec SME 能更有效地同時處理多個威脅模型審查案。

如前所述，擁有一致的方法和語言是推行異步過程的重要先決條件；每位參與者都可以無礙的閱讀並理解威脅模型，毋須重複探索資訊的解讀方式。

比起針對整個工作負載，我們建議將其拆解爲一個個的功能，逐步執行威脅模型分析。此方法具有許多主要優點：
1. 較小的工作單元可以更精細地跟蹤進度，這與敏捷式交付的開發模式一致，且方便領導層持續追蹤進展。
2. 這種方法能使威脅模型更加詳盡，識別出更多的潛在威脅。
3. 如果該功能使用了在其他工作負載分析過的組件，其威脅模型便可以被重複利用。
4. 由於同一項威脅可能影響多個工作負載功能，逐步執行代表在工作負載層級，針對同一項威脅，可以有多項緩解措施，從而提升對這類威脅的復原能力。
5. 威脅模型中的單一缺失（例如尚未緩解的關鍵威脅）不至於使整個工作負載無法上線，僅有其所在功能需要推遲。

那麼問題來了，你應該把工作負載分解到什麼程度？一般來說，威脅模型至少要涵蓋以下的範圍：
• 一項資產。例如，憑據、客戶記錄等。
• 一個入口點。例如，Amazon API Gateway REST API 部署。
• 兩個元件。例如，Web 瀏覽器和 API Gateway REST API ; 或 API Gateway 和 AWS Lambda 函數。

只包含一種 AWS 服務 (例如 Amazon API Gateway) 的威脅模型分析範圍，並不滿足上述需求。由於該服務需視爲單一元件，分析則會錯失任何數據在元件間的傳輸。此外，由於缺少調用該服務的上下文關係，難以充分對威脅與緩解措施進行分析。對每一項服務，AWS皆就其工作負載功能建立威脅模型。因此在使用 AWS 服務實現工作負載功能時，您毋須針對該服務建立威脅模型，但要考慮您的工作負載會如何配置該項服務，並緩解辨識出的威脅。我們在 “9.識別和評估緩解措施” 對此會有更深入的介紹，並提出基準線安全控制 (Baseline Security Controls) 的概念。

從長遠來看，指派一個人或部門負責創建所有威脅模型是行不通的。集中管理的權責機關將成為瓶頸，只能通過增加員工人數來拓展頻寬。此外，這也與賦能授權設計與開發團隊背道而馳。

相反地，將創建威脅模型的責任分散給工作負載功能的設計與開發團隊，能帶來更高的擴展性。分散式的權責能適應組織的規模，並帶來不同的做事方式。應用開發團隊在掌握主導權後，會主導威脅模型分析，從過程中吸取經驗，應用於未來的功能開發，從而不斷提升其工作負載和功能的安全性。

這也讓 AppSec SME（或團隊）能在組織內的不同應用程式團隊中，高效地主持分析並提供安全建議。AppSec SME 將促成一致性、導入和溝通，並在團隊之間設置並提高安全標準。

在分析威脅模型的入口點時，請記得 AWS 服務能創建的入口點，會因 AWS 服務類型與工作負載的架構而異。

例如，使用 Amazon Simple Storage Service (S3) 時， 儲存貯體桶僅接受在 Amazon S3 API 揭示的入口點，且該服務不允許您，作為客戶，創建不同類型的入口點。然而您可以配置這些入口點可以如何被使用，包括允許或封鎖儲存貯體的公有儲存權。

另一方面， Amazon Elastic Compute Cloud (EC2) 在 Amazon EC2 API 與 EC2 實例作業系統提供的基本網路服務 (例如 SSH 或 RDP)之外，也允許客戶創建往EC2 實例的其他入口點(例如，您的應用程式 API)。

因此在建立威脅模型時，請確保將AWS服務原生，以及工作負載功能特有的入口點一併納入考量。

下一個目標是試圖回答「什麼會出錯」。目前不存在囊括所有威脅的規範列表，因爲其中的威脅會受到工作負載功能及上下文、行業、地理區域等因素所影響。

提出威脅需要集思廣益。通過使用 STRIDE（欺騙、篡改、否認、資訊洩露、拒絕服務和特權提升）等助記符，或查看 OWASP Top 10 或 HiTrust 威脅目錄等威脅清單來協助腦力激盪，並逐漸充實列表。

您可以透過這個流程，創建並擴展適用於貴公司的威脅目錄，以加速未來的腦力激盪，並使威脅模型分析的粒度更一致。

您將識別工作負載設計中的緩解措施（安全控制），並評估威脅是否皆已妥善解決。大多情況下，這涵蓋多層控制項和組織部門。

對於內部開發的應用程式和代碼，您需要查看設計中包含的緩解措施，包括但不限於輸入驗證、身份驗證、會話處理和邊界處理。

工作負載的的其他元件(例如，軟體即服務 SaaS、支撐 COTS 應用程式的基礎設施、或運行於自有數據中心的元件) 皆應納入分析，並檢視與工作負載設計相關的安全控制措施。

當使用 AWS 服務時，安全和合規是 AWS 和客戶的共同責任。AWS 共同責任模型頁面對此進行了描述。

對於您所使用的 AWS 服務， AWS 負責服務之安全控制措施、威脅識別與緩解（雲端本身的安全）。AWS（雲端本身的安全）和您（雲端內部的安全）的責任分配，則取決於所使用的 AWS 服務。我們將分別以基礎設施、封裝與抽象服務 爲例，說明識別和緩解威脅的責任邊界如何變化：

• Amazon EC2∶ 是基礎設施服務的典型範例，您可以在雲端創建虛擬伺服器，選擇作業系統，並控制運行的一切；您因此要負責識別和緩解其中威脅。

• Amazon Relational Database Service （Amazon RDS）是封裝服務的代表案例，客戶無法觸及作業系統，僅能操作選定的資料庫引擎（例如 MySQL）。AWS 會負責作業系統的安全性，客戶無需設計緩解措施。然而資料庫引擎與其中一切都在客戶的控制之下，因此需由客戶設置緩解措施。與基礎設施服務相比，AWS在封裝服務會承擔更大的責任。

• Amazon S3、 AWS Key Management Service(KMS) 和 Amazon DynamoDB 則屬於抽象服務，客戶透過 API 管理上述服務的控制與數據平面。同樣的，客戶無法觸及操作系統、資料庫引擎或平臺，這些因而歸 AWS 管理。然而客戶可以透過API 操作服務或配置權限政策，因此 API 級別以上和權限政策之緩解措施，均應由客戶負責。與前兩類服務相比，AWS 在抽象服務承擔了更大的責任。

雖然上述範例未涵蓋所有類型的 AWS 服務，它們展示了在 AWS 共同責任模型下，該如何界定您對工作負載中的應擔負哪些安全及合規性責任。瞭解工作工作負載中使用的 AWS 服務類型與雙方責任的平衡點，有助於您進行威脅模型分析，並在您的控制範圍內擬定緩解措施，包含工作負載內的措施與 AWS 服務配置選項。在雲端本身的安全方面，AWS 服務通過多項合規性計劃，並且AWS Artifact 提供審計報告供客戶下載。
無論選用哪種 AWS 服務，客戶始終需負擔部分責任，且應納入您的工作負載威脅模型中考量。

具體而言，對 AWS 服務的安全控制緩解措施多半涵蓋下列領域：身份和訪問管理(身份驗證/授權)、資料保護(靜態、傳輸中)、基礎設施安全性、以及日誌記錄和監控。每個 AWS 服務文檔皆有專門的安全章節，其中包含將安全控制措施作為威脅緩解的指引。在威脅模型中引入這些安全控制與緩解措施時，儘可能在您基礎設施即代碼 (Infrastructure-as-code) 存儲庫或類似的工具中，加註該代碼、IAM 政策和 AWS CloudFormation 範本等的引用。這有助於威脅模型的審閱者或審批者對提議的緩解措施，能採取更清晰明確的觀點。

與威脅識別相同，目前不存在囊括所有安全控制的規範列表。通過本篇描述的流程，您應能針對組織的目標設計基準線安全控制，並儘可能透過AWS 服務級別配置（例如，靜態加密）與護欄（例如，通過服務控制策略），在平臺層級落實控制措施。這樣的方式可以確保基線安全控制的一致性與可規模化，在您所設計、部署的其他工作負載，也能自動繼承或套用同樣的基準線安全控制。

設置基準線安全控制 (Baseline Security Control) 時，應特別注意工作負載功能的前後關係可能有所變動。倘若在分析威脅模型時，發現基準線安全控制指稱的威脅不適用於該工作負載，又或存在其他緩解或補償控制措施可充分緩解該威脅，應容許對該控制措施做出一定調整。常見的補償控制措施和緩解因素包括：精簡的數據資產分類、非人工訪問或臨時數據/工作負載。

若想瞭解如何將基準線安全控制納入整體雲端安全治理，請查看如何考慮雲端安全治理博客文章。

這個問題沒有完美的答案。但應基於風險進行威脅模型分析，以便於在可能性與實質影響間取得平衡。過分強調「讓我們構建並交付產品」可能在日後導致大量開銷和重大延誤。相反的，若過分強調「讓我們緩解所有可能的威脅」可能會拖遲工作負載功能的發佈（或無法發佈），而無法滿足您的客戶的期待。是以我們在「組建合適的團隊」一節挑選了這些角色，並在發佈功能與緩解威脅之間，自然的塑造出緊張關係。擁抱這種健康的緊張感。

在 “將工作負載分解為更小的部分” 裡，我們建議將威脅模型的範圍縮小到特定工作負載功能。您可能會想，「我們已經發佈了 <X數量> 的功能，該如何對這些功能進行威脅模型分析？」這個問題完全合理。

我們會建議，與其回過頭對已上線功能創建威脅模型，倒不如專注於正在開發的新功能，分析其威脅，並讓交付的代碼更加安全，包含未來的每樣功能，每次發佈。在此過程中，您、您的團隊與您的組織不止能熟悉威脅模型分析，也能學習如何有效溝通。不斷調整，反覆迭代，持續改進。有朝一日，當你能持續爲新功能產出提供高品質、一致、且可重用的威脅模型時，你也可以開始將已上線功能的威脅模型分析放入待解工作中。

威脅模型分析是一項投資 - 在筆者看來，這是項不錯的投資，因為在設計階段發現並緩解威脅的成本，要低於在後期執行。隨著時間的推移，持續實施威脅模型分析也可能改善您的安全狀況。

上述爲組織導入威脅模型的實務手段，基於過往的觀察與建議。這些方法圍繞着溝通、協作、和人爲主導的專業知識，以找出並解決威脅，滿足最終客戶的期待。掌握這些建議後，您可以檢視正在處理 (或在待解工作) 的工作負載功能，並開始建立威脅模型。

作為此文章的配套和擴展，您可以觀看 2021 AWS 澳大利亞和紐西蘭雲端高峰會的錄影 “如何進行威脅模型分析”。

為了親身實踐，推薦您與您的團隊參加免費的 AWS “給構建者的威脅模型指南” 工作坊。此入門級工作坊會簡介威脅模型分析的背景和目的，以及用於系統建模、識別威脅和選擇緩解措施的工具和技巧。工作坊將逐步帶領您創建系統模型和對應的威脅模型。您很快能體驗這些模型的用途。每個練習都有分步說明，適合搭配隨附的學員手冊進行。透過這個工作坊，我們將展示 AWS 如何看待威脅模型分析、安全文化、以及將團隊安全能力都能有效拓展的方法。

想要瞭解更多 AWS 安全操作指南內容、新聞和功能公告？在推特上關注我們(@AWSSecurityInfo)。如果您想對於您的工作負載安全有更進一步的討論，請聯繫您指定的 AWS 客戶經理與解決方案架構師。一如既往，我們邀請您繼續構建，與 Amazon Web Services 攜手共進。