如何进行威胁模型分析

原文 https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/

在这篇文章中，我们将分享如何把威胁模型分析整合到您组织内的应用程序开发生命周期。 关于威胁模型分析的执行流程，我们有许多优秀的指南。我将简要介绍这些指南及其方法。 然而本文的主要目的是通过一些关于如何处理威胁模型分析方法的人员和流程组件的相关提示来增强现有指南。根据我的经验，这对于改善安全结果、安全所有权、上市速度和所有相关人员的总体幸福感大有帮助。 此外，我还将提供一些关于使用亚马逊云科技最佳时机的指导。

让我们以威胁模型分析进阶指导开始吧。

为什么使用威胁模型分析

IT 系统非常复杂，并且随着时间的演进会变得越来越复杂和强大，进而提供更多的商业价值并提高客户满意度和参与度。 这意味着IT设计决策需要考虑越来越多的使用案例，并且以缓解潜在安全威胁的方式来作考量; 尤其需要考虑到可能影响业务结果的安全威胁，包括未经授权的数据访问、服务阻断（DoS）和资源滥用。

这种复杂性和使用案例排列的数量，通常会让使用非结构化方法来寻找和消除威胁变得无效。 相反，你需要一种系统的方法来枚举工作负载的潜在威胁，并设计缓解措施，以及确定这些缓解措施的优先顺序，以确保您的组织能使用有限资源，在改善工作负载的整体安全状况方面产生最大影响。 威胁模型分析旨在提供这种系统方法，目的是在设计过程的早期发现和解决问题，此时缓解措施的相对成本要远低于在工作负载生命周期的后期采取措施。

亚马逊云计算的架构完善框架中明确地将威胁模型分析在安全性支柱中定义为基础安全领域的最佳实践之一。 在亚马逊云计算的架构完善框架审核中安全性的首要题目就涵盖威胁模型分析。

威胁模型分析在工作负载（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）上或纸上设计时即应开始考虑。 威胁模型分析的执行时机，最好发生在工作负载的功能新增或设计变更的阶段，因为这些更改可能会引入新的潜在威胁，使得威胁模型需要更新。

威胁模型分析提示

威胁模型分析需要仔细构思、头脑风暴、协作和沟通。 其目的是弥合应用程序开发、运营、业务和安全之间的差距。 成功没有捷径。 但是，我观察到一些因素对威胁模型分析的采用和成功有着深刻的影响 – 我将在以下部分中介绍这些领域。

1. 组建合适的团队

威胁模型分析是一项「团队运动」，因为它需要多元化团队的知识和技能，其中所有输入可看做具有相同价值。 对于本文中列出的所有角色，建议的心态是从最终客户的期望开始，然后以倒推方式进行工作（Working Backward）。 考虑一下客户对此工作负载与功能的期望，包括安全性以及保持功能和可用性的平衡。

我建议团队应涵盖以下观点，值得注意的是个人参与讨论时可以涵盖以下多个观点：

业务角色 – 首先，为了落实执行，您需要有人能代表工作负载或功能的业务方参与到威胁模型的分析过程。 此人应该对工作负载的功能和非功能要求有深入的了解，他们的工作是确保这些要求不会受任何因缓解威胁而采取的建议和措施的过度影响。 这意味着，如果建议的安全控制（即缓解）造成应用程序需求“不可用”或“过度降级”，则需要进一步的改善才能在安全性和功能之间取得适当的平衡。

开发人员角色 – 这是了解当前为工作负载功能建议的设计，并且对迄今为止所做的设计决策参与度最高的人。 他们参与了到目前为止所有的设计头脑风暴或白板会议，其时他们通常会考虑对设计的威胁以及可能的缓解措施。 如果您不开发自己的内部应用程序（例如 COTS 应用程序），您将包含内部应用程序的所有者。

对手角色 – 接下来，您需要有人扮演对手的角色。 此角色的目的是设身处地将自己置于攻击者的位置，并严格审查工作负载设计，并寻找利用工作负载中的设计缺陷来实现特定企图的方法（例如，未经授权的数据共享）。 他们执行的攻击是一种心理锻炼，而不是实际在键盘上实操。 如果您的组织有所谓的红队，那么他们可能非常适合这个角色; 如果组织中没有红队，您可能希望让安全运营或工程团队的一个或多个成员扮演这个角色。 或者，引入专门从事该领域的第三方。

防御者角色 – 之后您需要有人扮演防御者的角色。 此角色的目的是将对手角色设计的可能「攻击」视为潜在威胁，并设计安全控制来缓解威胁。 此角色还评估可能的缓解措施在持续运营支持、监控和事件响应方面是否具有可管理性。

AppSec SME 角色 – 应用程序安全 （AppSec） 主题专家 （SME） 角色应最熟悉威胁模型分析过程和讨论审核方法，并且应具有深厚的IT安全知识和经验。 讨论审核对于整个实践过程至关重要，以确保过程的总体目标保持在正轨上，并保持安全性和客户结果交付之间的适当平衡。 最终，正是这个角色认可威胁模型，并建议威胁模型分析实践之外的操作范围，例如渗透测试范围。

2. 采取一致的方法

在前面的部分中，我列出了一些流行的威胁模型分析方法，而选择哪一种方法不如在团队内部和团队之间一致地使用它那般重要。

通过使用一致的方法和格式，您的团队可以更快地行动并更准确地估计工作量。 个人可以通过观察其他团队成员或其他团队开发的威胁模型，从示例中学习，从而避免从头开始。

当您的团队评估创建威胁模型所需的工作量和时间时，可以使用以前威胁模型的经验和时间来对交付时间作更准确的估计。

除了使用一致的方法和格式之外，所建模威胁的粒度和相关性的一致性也是关键。 在本文的后续部分，我将介绍创建威胁目录以供整个组织重用的建议。

最后，重要的是这种方法实现了可拓展性：如果正在进行威胁模型分析的工作负载功能使用了现有威胁模型的组件，则可以重复使用这些组件的威胁模型（或单个安全控制）。 使用此方法，您可以有效地利用组件的现有威胁模型，并基于该模型进行构建，从而避免重复工作。

3. 与软件交付方法保持一致

您的应用程序开发团队已经具有特定的工作流和业务交付风格。 如今，敏捷风格的业务交付最受欢迎。请确保用于威胁模型分析的方法与业务交付方法和工具的完好整合。

就像任何其他可交付结果一样，捕获与威胁模型分析相关的用户情景，作为工作负载功能的冲刺(sprint)、长篇故事(epic)或待解工作（backlogs）的一部分。

4. 使用现有的工作流工具

您的应用程序开发团队已经在使用一套工具来支持他们的业务交付方法。 这通常包括用于文档的协作工具（例如，团队Wiki），以及用于在整个软件开发生命周期中跟踪工作产品的问题跟踪工具。 旨在将这些工具用作安全审查和威胁模型分析工作流的一部分。

现有工作流工具可以提供单个场所来提供和查看反馈、分配操作以及查看工作负载功能的威胁模型分析可交付结果的总体状态。 作为工作流的一部分可以减少完成项目的阻力，并允许威胁模型分析变得像单元测试、QA测试或工作流的其他典型步骤一样普遍。

通过使用典型的工作流工具，负责创建和查看威胁模型的团队成员可以异步工作。 例如，当威胁模型审阅者添加反馈时，作者会收到通知，然后作者可以在有时间时处理反馈，而无需留出专用时间来开会。 此外，这使AppSec SME能够更有效地处理他们可能参与的多个威胁模型审查。

如前所述，拥有一致的方法和语言是使得异步过程变得可行的重要先决条件，以便每个参与者都可以阅读和理解威胁模型，而无需每次都重新学习正确的解释。

5. 将工作负载拆解为更小的部分

建议将工作负载拆解为小功能单位，并在功能级别执行威胁模型分析，而不是为整个工作负载创建单个威胁模型。 此方法具有许多关键优点：

1. 拥有较小的工作模块可以更精细地跟踪进度，这与遵循敏捷式交付的开发团队非常一致，并为领导层提供了持续的进展视图。
2. 这种方法倾向于创建更详细的威胁模型，从而识别出更多的发现。
3. 分解威胁模型更提供了重复利用的机会，以作为其他使用相同组件的工作负载功能的参考。
4. 通过考虑每个组件的威胁缓解措施，在整体工作负载级别，这意味着单个威胁可能具有多个缓解措施，从而提高了对这些威胁的恢复能力。
5. 单个威胁模型的问题（例如尚未缓解的关键威胁）不会成为整个工作负载的启动障碍，而只是阻碍单个功能的启动。

那么问题来了，你应该把工作负载分解到什么程度？ 作为一般规则，为了创建威胁模型，至少需要涵盖以下的范围：

• 一项资产。 例如，凭据、客户记录等。
• 一个入口点。 例如，Amazon API Gateway REST API 部署。
• 两个组件。 例如，Web浏览器和API网关REST API; 或API网关和 AWS Lambda 函数。

如果只为亚马逊云计算上的原生单一服务创建威胁模型（例如 Amazon API Gateway）是无法满足安全标准的要求。 假设该服务是单个组件，则数据不会从一个组件移动到另一个组件。 此外，工作负载中服务可能工作场景的前后关系不明确，因此无法全面推导出威胁和缓解措施。对于利用亚马逊云计算服务的工作负载功能，您无需对原生服务进行威胁模型分析，而是在寻求缓解已识别的威胁时考虑各种原生服务的“配置选项”和您自己的特定于工作负载的缓解措施。 我在“9. 识别和评估缓解措施“部分中对此进行了更深入的介绍。在该部分中，我将介绍安全控制基准线（Security Baseline）的概念。

6. 分散权责（Ownership）

从长远来看，让一个中心人员或部门负责创建威胁模型是行不通的。 这些集中化管理单位将成为瓶颈，只能通过增加员工人数来扩大规模。 此外，集中权责无法对实际设计和部署构建工作的人员进行有效授权。

相反，扩展性很好的方案是负责设计和实现每个工作负载功能的团队对威胁模型创建采用分布式所有权。 分布式所有权可以扩展并推动行为改变，因为现在应用程序团队享有控制权。同时重要的是他们正在从威胁模型分析过程中吸取安全经验，并将这些经验植入到下一个功能版本中，从而不断提高其工作负载和功能的安全性。

这为 AppSec SME（或团队）创造了机会，使他们可以有效地扮演组织中所有不同应用程序团队的审阅人和安全顾问角色。 AppSec SME 将能够推动一致性、采用和沟通，并在团队之间设置和提高安全标准。

7. 确定入口点

当您希望确定作为整体威胁模型中组件的亚马逊云计算服务的入口点时，请务必认识到基于其服务类型，入口点可能会因威胁模型范围中包含的工作负载功能的架构而异。

例如，使用Amazon Simple Storage Service （S3），S3 储存桶的可能入口点类型仅限于通过 Amazon S3 API 公开的内容 ，并且该服务不提供您（作为客户）创建其他类型的入口点的功能。 在此 Amazon S3 示例中，您作为客户可以选择如何公开这些现有类型的终端节点，包括存储桶是私有存储桶还是可公开访问。

另一方面， Amazon Elastic Compute Cloud （EC2） 允许客户创建其他类型的 EC2 实例入口点（例如，您的应用程序 API）。此外 ，Amazon EC2 API 提供的入口点类型以及EC2实例上运行的操作系统的本地入口点类型（例如 SSH 或 RDP）。

因此，请确保您的威胁分析模型将入口点应用到AWS服务的本级终端节点，以及特定于工作负载的功能上。

8. 提出威胁

你在这里的目的是尝试提出什么会出错这个问题的答案。  并不存在列出所有可能威胁的规范清单，因为确定威胁取决于正在评估的工作负载功能的上下文，以及所在行业、地理区域等特有的威胁类型。

提出威胁需要集思广益。 通过使用 STRIDE（欺骗、篡改、否认、信息泄露、拒绝服务和特权提升）等助记符，或者通过查看 OWASP Top 10 或 HiTrust 威胁目录等威胁清单来促进头脑风暴练习，以推动和收集想法。

通过此过程，建议开发与组织相关的威胁目录并参与该目录，这将加快未来的头脑风暴过程，并推动建模的威胁粒度的一致性。

识别和评估缓解措施

在此，您的目标是确定工作负载设计中的缓解措施（安全控制），并评估是否已充分解决威胁。 请记住，通常有多层控制和多方责任在起作用。

对于您自己的内部应用程序和代码，您需要查看设计中包含的缓解措施，包括但不限于输入验证、身份验证、会话处理和边界处理。

考虑工作负载的所有其他组件（例如，SaaS服务，支持 COTS 应用程序的基础设施，或本地数据中心内托管的组件），并确定作为工作负载设计一部分的安全控制。

当您使用亚马逊云计算的原生服务时，安全性和合规性是由亚马逊云计算和您作为我们的客户的共同责任。 亚马逊云计算上的责任共担模型页面上对此进行了描述。

这意味着，对于您正在使用的由 亚马逊云计算（云本身的安全）负责的服务部分，安全控制以及威胁识别和缓解由亚马逊云计算管理。 亚马逊云计算（云本身的安全）和您（云内部的安全）之间的责任分配取决于您使用的服务。 下面，我将提供基础设施、封裝和抽象服务的示例，以说明您识别和缓解威胁的责任如何变化：

• Amazon EC2∶ 是基础设施服务的一个很好的例子。您可以在其中访问云中的虚拟服务器，选择操作系统，并且可以控制服务及其上运行的所有方面，因此您将负责缓解已识别的威胁。
• Amazon 关系型数据库服务 （Amazon RDS）是封裝服务的代表案例。服务本身并 没有向您开放操作系统，而是 AWS 向您开放选定的数据库引擎（例如 MySQL）。 对此AWS 负责操作系统的安全性，您无需设计缓解措施。 但是，数据库引擎及其上运行的所有方面都在您的控制之下，因此您需要考虑这些方面的缓解措施。 在此与基础设施服务相比，AWS承担了更大的责任。
• Amazon S3、  AWS Key Management Service（KMS） 和 Amazon DynamoDB 是抽象服务的示例， 其中 AWS 通过服务 API 向您开放整个服务的控制平面和数据平面。 同样，这些服务没有向您开放操作系统、数据库引擎或平台 ——这些都是 AWS 的责任。 但是，API操作和关联的策略在您的控制之下，同时也包括 API 级别以上的所有方面。因此您应该考虑针对这些操作和策略的缓解措施。 对于此类服务，与容器和基础设施类型的服务相比，AWS承担了更大的责任。

虽然这些范例并不涵盖您工作负载中可能存在的所有类型的AWS服务，但它们展示了在这种情况中，责任共担模型下的安全性和合规性的责任范围将如何变化。 了解 AWS 和您自己之间对于这类在您工作负载中用到的AWS 服务的责任范围，有助于您确定威胁模型分析实践的范围，并把潜在危险限定在您的掌控范围内。这些安全控制通常是AWS 服务 配置选项与您自己的特定于工作负载的缓解措施的结合。 对于亚马逊云计算的责任部分详述在服务在许多合规性项目的范围内，而相關审计报告可供客户从Amazon Web Services Artifact 页面免费下载。

无论您使用哪种亚马逊云计算服务，都会有客户负责的因素，而这应包含在您的工作负载威胁模型中。具体而言，服务本身的安全控制缓解措施，您需要考虑跨领域的安全控制，包括以下领域：身份和访问管理（身份验证/授頁面权）、数据保护（静态、传输中）、 基础设施安全性以及日志记录和监控。 亚马逊云计算各项服务在文档中都有一个专门的安全章节，其中提供了有关要考虑作为缓解措施的安全控制的指导。 在威胁模型中捕获这些安全控制和缓解措施时，您应该旨在包括对工作负载的基础设施即代码存储库中的实际代码、IAM策略和CloudFormation 模板等的引用。 这有助于您威胁模型的审阅者或审批者明确查看预期的缓解措施。

与威胁识别的情况一样，并不存在列出所有可能的安全控制的规范清单。 通过此处描述的过程，您应该有意识地开发符合您组织控制目标的基准安全控制，并在可能的情况下将这些基准安全控制作为平台级控制实施，包括 AWS 服务级别配置（例如，静态加密）或安全防护（例如，通过服务控制策略）。 通过执行此操作，可以提高一致性和规模，以便自动继承这些已实现的基准安全控制，并对您设计和部署的其他工作负载功能落实到位。

当您提出基准线安全控制（Baseline Security Control）时，必须注意的是：给定工作负载功能的前后关系是未知的。 因此，建议将这些控制措施视为可以偏离的可协商基准线，前提是在执行工作负载威胁模型分析实践时，您发现基准线控制旨在缓解的威胁不适用，或者存在其他缓解措施或补偿控制措施可以充分缓解威胁。 补偿控制和缓解因素可能包括：减少数据资产分类、非人工访问或临时数据/工作负载。

若要详细了解如何开始将基准线安全控制作为整体云安全治理的一部分，请查看如何考虑云安全治理博客文章。

10.决定什么时候足够了

这个问题没有完美的答案。 但是，必须对威胁模型分析过程具有基于风险的视角来创建一种平衡的方法，以便适当考虑风险的可能性和影响。 过分强调「让我们构建和交付它」可能会在后续导致高昂的成本和项目延误。 相反，过分强调「让我们缓解所有可能的威胁」可能会导致工作负载功能延迟发布（或无法发布），而您的客户可能会终止合作。 在我之前在「组建合适的团队」部分中的建议到：角色的选择是经过深思熟虑的，以确保在发布功能和缓解威胁之间存在自然的紧张关系。 请拥抱这种健康的紧张感。

11.在开始之前不要让瘫痪阻止你

在前面“将工作负载分解为更小的部分”章节中，我建议应将威胁模型的范围缩小到工作负载功能。 您可能会想，「我们已经发布了若干数量的功能，我们如何对这些功能进行威胁模型分析？ 这是一个完全合理的问题。

与其回到已经上线的威胁模型功能，不如针对现今正在开发的任何新功能进行威胁模型分析; 并改进你接下来发布的代码安全属性，以及你之后发布的每个功能。 在此过程中，您、您的团队与您的组织将不仅学习威胁模型分析，还学习如何有效地相互沟通。 进行调整，迭代，改进。 将来的某个时候，当你定期为新功能提供高质量、一致且可重用的威胁模型时，你可以开始将针对现有功能执行威胁模型分析的活动放入积压工作中。

结论

威胁模型分析是一项投资 – 在我看来，这是一项不错的投资，因为与事后查找威胁相比，在设计阶段查找和缓解威胁可以大大降低缓解的相对成本。 随着时间的推移，持续实施威胁模型分析也可能改善您的安全状况。

我分享了我的观察结果和提示，介绍了将威胁模型分析纳入组织的实用方法。这些方法以沟通、协作和人为主导的专业知识为中心，以查找和解决最终客户预期的威胁。 有了这些提示，我鼓励您查看您现在正在负责的工作负载功能（或积压工作 （backlog）中的工作负载功能），并确定哪些将成为您第一个威胁模型。

作为此博客文章的配套和扩展，您可能希望观看2021年澳大利亚和新西兰亚马逊云计算在线峰会上录制的“如何进行威胁模型分析”会议。

为了亲身实践，在此也推荐“构建者面临的正确威胁模型分析”免费研讨会培训。 此入门级研讨会介绍了威胁模型分析的一些背景与为何需要威胁模型分析，以及用于对系统进行建模、威胁识别和缓解措施选择的一些工具和技术。 研讨会将指导您完成创建系统模型和相应威胁模型的过程。 然后您将评估这些模型的有用性。 每个练习都有分步说明，您可以在研讨会过程中使用相关的参与者手册。 在整个研讨会中，我们将深入了解亚马逊云计算如何看待威胁模型分析、我们的安全文化以及我们如何扩展我们的安全人员涵盖能力。

想要了解更多亚马逊云计算安全操作指南内容、新闻和功能公告？ 在推特上关注我们。

本篇作者

本篇译者

本篇译者