作为风险管理策略的文解威胁一部分，识别系统面临的建模安全威胁是缓解潜在漏洞的重要步骤。但就其本身而言，文解威胁识别威胁并不足以抵御攻击。建模

IT团队和安全工程师必须通过利用威胁建模来更进一步，文解威胁以主动、建模系统地评估和防御组织面临的文解威胁各种威胁 。下文将介绍威胁建模的建模含义、工作原理 、文解威胁主流威胁建模框架、建模工具以及优秀实践。高防服务器文解威胁

威胁是一个或一组恶意行为者认为妥协解决方案是有价值的。不同的文解威胁威胁行为者将有不同程度的动机和技能来利用漏洞 。而漏洞的建模可用性将取决于对现存事物的了解、所需的文解威胁访问级别以及已实施的任何缓解措施 。

出于讨论目的 ，源码下载我们将假设以下主要威胁行为者
：

威胁建模是一种基于工程和风险的方法
，用于识别、评估和管理安全威胁，旨在开发和部署符合企业组织安全和风险目标的更好软件和IT系统 。它可以分为几个不同的阶段：

通过遵循这些步骤  ，团队可以采取系统的 、高度结构化的方法来识别威胁 ，作为其软件开发生命周期的一部分。他们还能获得主动威胁响应能力，而非坐等实际攻击开始再计划响应措施 
。

威胁建模可应用于任何类型的IT资源。您可以在应用程序、服务器 、本地环境、免费模板公共云等上执行威胁建模。

威胁建模还可用于帮助管理任何类型的威胁——从DDoS和勒索软件攻击到内部威胁和意外的数据泄露
，威胁建模技术是在风险引发现实安全事件之前提前进行预防的有效方法
。

也就是说 ，威胁建模技术可能会因您关注的资源和威胁类型而异。例如
，适用于本地环境的威胁管理策略，在某些重要方面与适用于公共云的威胁管理策略不同 ，因为组织与云服务提供商建立了责任共担模型，因此需要不同的缓解策略。

通过对安全威胁进行系统的、结构化的响应，威胁建模有一系列优势：

最有效的威胁建模策略需要植根于以下几个核心优秀实践：

(1) 与其他团队合作

在许多企业中，IT组织分为不同的团队 ，每个团队管理自己的系统和资源。

与其让每个团队创建自己的威胁模型并根据需要缓解威胁，不如努力在整个组织内就威胁建模进行协作
。很可能一个团队面临的一些威胁也会影响其他团队 。在威胁建模方面进行协作可以更有效地利用资源，同时还允许团队分享可能促成更有效的威胁缓解策略的见解
。

(2) 整体地评估威胁

通常情况下，对一种资源的威胁可能会导致对下游资源的间接威胁。例如
，如果攻击者破坏应用程序，对应用程序的威胁也可能危及应用程序访问的数据。

出于这个原因，重要的是要整体地评估威胁，而非孤立地评估 。评估每个威胁的潜在严重性 ，不仅要根据它所威胁的主要资源 ，还要根据它可能对企业造成的整体损害 。

同样地 ，需要采取措施在多个层面减轻威胁。例如，如果针对应用程序安全的威胁对数据安全造成了间接损害 ，那么您可以在应用程序和数据中采取措施来帮助缓解威胁 。您可能需要对应用程序进行双重身份验证以降低违规风险，同时还需要实施数据的异地备份 ，以便在应用程序违规允许攻击者访问数据的情况下 
，您能拥有一份干净的副本并以此拒绝赎金勒索 。

(3) 全面思考威胁

将威胁建模重点放在与最近备受瞩目的攻击相关的威胁上，或者您的企业过去面临的威胁上 ，这可能听起来很合理。但是
，最好的威胁建模策略需要涵盖可能影响业务的每一个威胁——无论它的新闻价值如何 ，或者它过去是否曾转化为现实攻击。在识别威胁时，不仅要查看网络安全博客以了解最近的违规情况，还要查看威胁数据库和威胁情报报告 ，以深入了解您的团队可能不会考虑的威胁类型。

(4) 在开发生命周期的早期执行威胁建模

创建威胁模型的最佳时间是在项目或应用程序开发实践开始时。那时 ，在您的系统中建立威胁防御能力相对更容易
。

如果您等到已经编写了代码 ，或者（更糟）等到它已经部署到生产环境中，您可能会发现实施最佳威胁缓解措施要困难得多 。这样做可能需要更改您的代码，这意味着您必须重新构建、重新测试和重新部署，这无疑是一个耗时且低效的过程。

(5) 超越应用程序进行思考

在执行威胁建模时，很容易只关注应用程序 ，而非应用程序所在的更广泛的环境
。毕竟
，应用程序通常是您用户体验的核心。其他一切都只是陪衬。

但在安全性方面，环境任何层和开发生命周期任何阶段的威胁都可能变成漏洞
。这就是为什么您不仅应该考虑您的应用程序，还应该考虑针对托管它们的服务器或云基础设施的威胁。如果您在容器中部署应用程序，那么还必须考虑对容器注册表、容器映像和容器编排工具的威胁 。并且不要忘记可能影响数据的威胁，例如配置不当的IAM角色可能会将您的云存储桶暴露给公众 。

有多种方法可用于帮助团队构建其威胁建模流程：

(1) 攻击树（Attack tree）：使用这种方法
，可以将威胁建模为一组路径（或树） ，以确定哪些资源会受到与每个威胁相关的攻击的影响。当拥有大量高度相互依赖的资源 ，并且想知道哪些直接和间接威胁会影响每个资源时 ，攻击树非常有用。

(2) 安全卡（Security card）：安全卡技术采用开放式方法进行威胁建模 。它基于一组42张卡片，询问有关组织面临的威胁问题。通过处理这些卡片，团队可以思考他们面临的威胁以及缓解这些威胁的策略。

(3) PASTA（攻击模拟和威胁分析流程）：PASTA技术专注于帮助团队根据业务优先级评估威胁  。它首先确定业务目标和支持它们所需的技术资源。然后 ，团队确定哪些威胁可能会影响这些资源——进而 ，他们会发现可能危及业务优先级的威胁。它由七个步骤组成，且每个步骤都非常复杂 ，由多个子步骤组成 ，但是总体顺序如下：

(4) STRIDE：是威胁建模之父，最早于90年代末由微软提出。STRIDE代表六种威胁，每种威胁都违反了 CIA的变体的特定属性：

STRIDE方法背后的核心概念是按类型划分威胁
，然后根据威胁所属的类别对每个威胁做出响应。

威胁建模工具集成了一组核心功能
，用于在单个平台内发现、分析和缓解威胁 。威胁建模工具的主要功能包括 ：

许多软件供应商提供的工具都具有旨在帮助团队执行威胁建模的功能。 例如 ，Microsoft威胁建模工具是一种可下载的Windows桌面应用程序，是一种流行的选择；ThreatModeler是一个类似的基于Web的威胁建模平台；OWASP的Threat Dragon和pytm工具是广泛使用的开源威胁建模工具
。

想要了解如何将威胁建模付诸实践 ，了解一些常见的用例或实际威胁建模示例可能会很有帮助。

(1) 云威胁建模

当工作负载从本地迁移到云端时 ，面临的威胁可能会发生巨大变化 。缺乏物理安全性的问题基本上消失了，但出现了诸如不安全的IAM配置之类的新威胁
。

团队可以使用云威胁建模 ，来帮助识别和管理在云迁移期间和之后影响工作负载的风险。通过这种方式，云威胁建模使他们能够预测如果坚持使用与本地相同的安全策略将无法解决的风险
 。

(2) 网络威胁建模

网络传播的威胁在范围和形式上可能会有很大差异，具体取决于网络的配置方式以及它们对公共互联网的暴露程度。使用虚拟网络等云服务无疑又为网络威胁增加了另一层复杂性
。

专注于网络的威胁建模提供了一种评估和管理这些威胁的方法 。它还可以帮助团队了解其网络架构固有的安全优势和劣势，并采取措施进行改进。

(3) 容器的威胁建模

将工作负载从虚拟机转移到容器也会带来新的威胁 ，例如恶意软件可能潜入容器映像或不安全的容器注册表访问控制。对这些威胁进行建模使团队能够识别、理解并采取措施缓解可能影响容器化环境的特殊威胁。

简而言之，威胁建模使企业能够领先于安全威胁 ，无论威胁采取何种形式或针对哪种类型的资源 。虽然威胁建模需要一些前期的时间投资 ，但当它允许团队主动响应威胁时 ，将产生巨大的好处。相较于不加以控制可能带来的高昂攻击代价，还是值得投入的！

原文链接 ：https://cloudsecurityalliance.org/blog/2022/04/21/threat-modelling-what-it-is-and-why-it-matters/