# SEC01-BP07 使用威脅模型識別威脅並優先考慮緩解措施
<a name="sec_securely_operate_threat_model"></a>

 執行威脅建模，為您的工作負載識別並保有潛在威脅及關聯緩解措施的最新記錄。排定威脅的優先順序並調整安全控制緩解措施，以防止、偵測和回應威脅。就您的工作負載的情況，以及不斷演變的安全態勢，重新檢視和維護此工作。

 **未建立此最佳實務時的曝險等級：**高 

## 實作指引
<a name="implementation-guidance"></a>

 **什麼是威脅建模？** 

 「威脅建模以保護有價值物為目標，識別、溝通和了解威脅及緩解措施。」 – [開放式 Web 應用程式安全專案 (OWASP) 應用卡程式威脅建模](https://owasp.org/www-community/Threat_Modeling) 

 **為何使用威脅模型？** 

 系統本身錯綜複雜，並且隨時間變得更複雜且更具能力，從而實現更大的商業價值及更高的客戶滿意度和參與度。這意味著 IT 設計決策需要考慮不斷增加的使用案例數量。這種複雜性和使用案例數量的排列通常使得非結構化方法無法有效尋找和緩解威脅。反之，您需要一套系統化方法來列舉對系統的潛在威脅，以及制定緩解措施，並以這些緩解措施為優先來確保組織的有限資源能在改善系統整體安全狀態上發揮最大的影響力。

 威脅建模旨在提供這套系統化方法，目的是要在設計過程中及早尋找和解決問題，此時進行緩解的成本和精力與生命週期稍後相比要來得低。此方法與[*往前移*安全性](https://owasp.org/www-project-devsecops-guideline/latest/00a-Overview)的業界原則相一致。威脅建模最終會與組織的風險管理程序整合，透過使用威脅驅動的方法，協助推動要實作哪些控制決策。

 **何時應執行威脅建模？** 

 在工作負載的生命週期中及早開始威脅建模，可給予您更大的彈性來決定要如何處理所識別的威脅。就跟軟體錯誤一樣，越早識別威脅，就能以越具成本效益的方式加以解決。威脅模型是不斷更新的文件，並且應該持續隨著工作負載的變更而演進。隨時間重新檢視您的威脅模型，包括當有重大變更、威脅形勢有變化，或是採用新功能或服務時。

### 實作步驟
<a name="implementation-steps"></a>

 **我們如何執行威脅建模？** 

 有許多不同的方式來執行威脅建模。就跟程式設計語言一樣，各有優缺點，而您應選擇最適合您的方式。其中一個方法是從 [Shostack 針對威脅建模的 4 個問題框架](https://github.com/adamshostack/4QuestionFrame)開始著手，當中提出自由回答的問題會為您的威脅建模練習提供結構：

1.  **我們目前在做什麼？** 

    此問題的目的是協助您了解正在建置的系統並對之取得一致的意見，以及該系統與安全相關的詳細資訊。建立模型或圖表是回答此問題最受歡迎的方法，因為這可協助您將正在建置的項目視覺化，例如使用[資料流程圖](https://en.wikipedia.org/wiki/Data-flow_diagram)。寫下關於您的系統的假設和重要詳細資訊也有助於您定義涵蓋的範圍。這可讓對參與威脅模型的每個人專注於相同的事情，並避免耗時地繞入不在範圍內的主題 (包括系統的過時版本)。舉例來說，如果您正在建置 Web 應用程式，可能不值得花時間為瀏覽器用戶端建立作業系統信任開機順序的模型，因為您無法透過您的設計對此產生影響。

1.  **什麼可能出錯？** 

    這是您識別對系統的威脅之處。威脅是意外或故意的動作或事件，會帶來不必要的影響，並且可能會影響系統安全。如果對可能出錯之處沒有清楚的了解，則無法對症下藥。

    對於什麼可能出錯，您並沒有標準的清單可循。建立此清單需要團隊內的每個人與[涉及的相關角色](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/#tips)在威脅建模練習中集思廣益和共同協作。您可以使用識別威脅的模型來協助集思廣益，例如 [STRIDE](https://en.wikipedia.org/wiki/STRIDE_(security))，這會建議不同的類別以進行評估：詐騙、竄改、否認、資訊洩露、拒絕服務和提升權限。此外，您可能會想要審核現有的清單並研究以獲得靈感來協助集思廣益，包括 [OWASP 前十大](https://owasp.org/www-project-top-ten/)、[HiTrust 威脅型錄](https://hitrustalliance.net/hitrust-threat-catalogue/)，以及您組織本身的威脅型錄。

1.  **我們要做何處理？** 

    就跟上一個問題一樣，對於所有可能的緩解措施並沒有標準的清單可循。此步驟的輸入是上一步識別的威脅、動作和改進之處。

    安全與合規是[您和 AWS 之間的共同責任](https://aws.amazon.com/compliance/shared-responsibility-model/)。了解當您提出「我們要做何處理？」時，也是在問「誰要對其負責？」，這一點很重要。了解您與 AWS 之間的責任制衡有助於您將威脅建模練習的範圍定在您控制之下的緩解措施，這通常是 AWS 服務組態選項與您自身的系統特定緩解措施的組合。

    對於共同責任的 AWS 部分，您將發現 [AWS 服務在許多合規計畫的範圍之內](https://aws.amazon.com/compliance/services-in-scope/)。這些計畫可協助您了解 AWS 在維護雲端安全和合規方面設立的強大控制。來自這些計畫的稽核報告可供 AWS 客戶從 [AWS Artifact](https://aws.amazon.com/artifact/) 下載。

    無論您使用何種 AWS 服務，其始終涉及客戶責任，而您的威脅模型中應包含與這些責任一致的緩解措施。對於 AWS 服務本身的安全控制緩解措施，您要考慮跨領域實作安全控制，包括身分和存取管理 (驗證和授權)、資料保護 (靜態和傳輸中)、基礎設施安全、日誌記錄和監控等領域。每個 AWS 服務的文件都有[專屬的安全章節](https://docs.aws.amazon.com/security/)，提供將安全控制視為緩解措施的指引。重要的是，考慮您正在編寫的程式碼及其程式碼相依性，並思考您可以設立以解決這些威脅的控制。這些控制可以是[輸入驗證](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html)、[工作階段處理](https://owasp.org/www-project-mobile-top-10/2014-risks/m9-improper-session-handling)和[界限處理](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow)等事項。大多數漏洞通常是在自訂程式碼中引入，因此請專注於此區域。

1.  **我們處理得當嗎？** 

    目標是讓您的團隊和組織改進威脅模型的品質以及隨時間執行威脅建模的速度。這些改進出自練習、學習、教導和審查的組合。若要更加深入並實作，建議您與您的團隊完成[建置人員建立威脅模型的正確方式訓練課程](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop)或[研討會](https://catalog.workshops.aws/threatmodel/en-US)。此外，如果您正在尋找有關如何將威脅建模整合至您組織的應用程式開發生命週期，請參閱 AWS 安全部落格上的[如何進行威脅建模](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/)文章。

 **威脅編寫器** 

 為了協助並指導您執行威脅建模，請考慮使用[威脅編寫器](https://github.com/awslabs/threat-composer#threat-composer)工具，該工具旨在縮短威脅建模實現價值的時間。此工具可協助您執行下列操作：
+  撰寫與[威脅文法](https://catalog.workshops.aws/threatmodel/en-US/what-can-go-wrong/threat-grammar)相符、可在自然非線性工作流程中使用的有用威脅陳述式 
+  產生人類可讀的威脅模型 
+  產生機器可讀的威脅模型，以讓您將威脅模型視為程式碼 
+  使用洞察儀表板協助您快速識別品質和涵蓋範圍有所改進的領域 

 如需進一步的參考，請造訪「威脅編寫器」，並切換到系統定義的**範例工作區**。

## 資源
<a name="resources"></a>

 **相關的最佳實務：**
+  [SEC01-BP03 識別和驗證控制目標](sec_securely_operate_control_objectives.md) 
+  [SEC01-BP04 隨時掌握安全威脅和建議的最新資訊](sec_securely_operate_updated_threats.md) 
+  [SEC01-BP05 縮小安全管理範圍](sec_securely_operate_reduce_management_scope.md) 
+  [SEC01-BP08 定期評估和實作新的安全服務和功能](sec_securely_operate_implement_services_features.md) 

 **相關文件：**
+  [如何進行威脅建模](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/) (AWS 安全部落格) 
+ [NIST：以資料為中心的系統威脅建模指南](https://csrc.nist.gov/publications/detail/sp/800-154/draft)

 **相關影片：**
+ [AWS Summit ANZ 2021 - 如何進行威脅建模](https://www.youtube.com/watch?v=GuhIefIGeuA)
+ [AWS Summit ANZ 2022 - 擴展安全性 – 針對快速和安全交付進行最佳化](https://www.youtube.com/watch?v=DjNPihdWHeA)

 **相關訓練：**
+ [建置人員建立威脅模型的正確方式 – AWS Skill Builder 虛擬自定進度培訓](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop)
+ [建置人員建立威脅模型的正確方式 – AWS 研討會](https://catalog.workshops.aws/threatmodel)

 **相關工具：**
+  [威脅編寫器](https://github.com/awslabs/threat-composer#threat-composer)