# 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 Top 10](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 安全博客上的《[How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/)》一文。

 **Threat Composer** 

 为了协助并指导执行威胁建模，您可以考虑使用 [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer) 工具，缩短进行威胁建模时实现价值的时间。该工具有助于您执行以下操作：
+  撰写符合[威胁语法](https://catalog.workshops.aws/threatmodel/en-US/what-can-go-wrong/threat-grammar)、能够在自然非线性工作流程中发挥作用的有用威胁语句 
+  生成人类可读的威胁模型 
+  生成机器可读的威胁模型，允许您将威胁模型视为代码 
+  使用 Insights 控制面板协助您快速确定质量和覆盖范围有待改进的方面 

 如需更多参考，请访问 Threat Composer 并切换到系统定义的**示例工作区**。

## 资源
<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) 

 **相关文档：**
+  [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/)（AWS 安全博客） 
+ [NIST: Guide to Data-Centric System Threat modeling](https://csrc.nist.gov/publications/detail/sp/800-154/draft)

 **相关视频：**
+ [AWS Summit ANZ 2021 - How to approach threat modeling](https://www.youtube.com/watch?v=GuhIefIGeuA)
+ [AWS Summit ANZ 2022 - Scaling security – Optimise for fast and secure delivery ](https://www.youtube.com/watch?v=DjNPihdWHeA)

 **相关培训：**
+ [Threat modeling the right way for builders – AWS Skill Builder virtual self-paced training](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop)
+ [Threat modeling the right way for builders – AWS 讲习会](https://catalog.workshops.aws/threatmodel)

 **相关工具：**
+  [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer)