威胁建模是一个帮助识别列举潜在威胁，并确定缓解措施的优先级，让安全实践左移的过程方法（例如架构缺陷漏洞或缺乏适当的保护措施）。
威胁建模的目的是为防御者提供系统分析，分析需要包含哪些控制或防御措施，考虑到系统的性质、可能的攻击者的概况、最可能的攻击向量以及攻击者最需要的资产。威胁建模可以回答诸如“我在哪里最容易受到攻击？”、“什么是最相关的威胁？”以及“我需要做什么来防范这些威胁？”等问题。
简而言之，威胁建模是一个围绕假想敌开展的领域建模活动。
能力要求 —— 资深架构师的小众发展路径
“这个岗位好难招啊，我们招了一年都没招到特别匹配的”
——某客户安全实验室威胁建模负责人
威胁建模并不是一个特别新的概念，但是在中国的信息安全行业，如果10个候选人里面能遇到1个简历里写着威胁建模经验，运气就已经很不错了，并且，实际上可以胜任这个岗位的角色更为稀缺。大部分的威胁建模能力都留在了各大高校机构实验室从事研究员的角色，没有广泛的技术经验在企业中铺开，并且这个岗位也还很少在产品和IT部门出现。
为什么这么难？主要的原因是，威胁建模并不是一个传统安全测试岗位可以很容易发展出的能力。
一个优秀的安全测试人员，需要了解各种类型的漏洞和攻击原理，需要思考每个攻击路径之间的联系，需要能阅读源码或二进制反汇编的代码寻找漏洞的蛛丝马迹，需要操作自动化工具进行暴力搜索，甚至需要熟练地逆向分析软件的原理，但是却往往缺乏正向开发和架构师的背景，尤其是在安全领域浸淫多年的大牛，很多都缺乏对最新技术架构的跟进和实践经验。
一个仅仅在安全测试方面有所建树的专家，却很难与大部分软件开发人员建立对话，而威胁建模，本质上是一个与架构师对话的过程，对话需要足够的共同语言和互相理解，因此也就对安全测试提出了新的要求，“与架构师统一语言”的要求。
整个过程中，威胁建模专家应当扮演假想敌的角色，与架构师进行思维上的碰撞，从而阐明和解释威胁的来源与可能存在的影响。
因此，对威胁建模人员的要求，既需要他能积累大量安全漏洞风险相关的知识，也需要了解大量软件架构设计和技术原理，甚至需要对开发非常熟悉，这也导致一个很有意思的现象，威胁建模人员大部分是由开发者发展而来，而非业务分析师或安全测试人员。
方法论 —— 加入安全视角的架构建模过程
在人员稀缺的情况下，为了让更多的企业能更容易开展威胁建模活动，于是出现了非常多的威胁建模“方法论”，其中以DFD模型最为突出，它尝试将软件架构抽象为一系列的组件数据交互，并指出系统中的安全要素（角色、组件、资产数据、交互关系、边界）。
通常一场威胁建模工作坊中，主持人会从以下几个步骤展开话题：
-
我们有哪些系统，这些系统有哪些用户？
-
我们从每一个业务事件流的角度出发，这个用户和系统的交互有哪些？
-
我们在交互中，产生了哪些数据实体？有哪些属于我们关心的核心资产？
-
我们有哪些外部的系统或者依赖（我们难以控制的威胁引入）？
-
我们有哪些系统安全边界设计，如网络隔离、认证和鉴权等（我们已经考虑并实施的安全控制）？
可以看到，这个建模过程的前三步，非常类似“事件风暴”方法中的业务事件、用户事件流转、交互命令识别、领域聚合。而其他的几个步骤则体现出安全方面的考虑：需要保护的核心资产、威胁攻击面、供应链风险、安全边界等等。
因为需要产品架构师与安全专家等多方的输入，建议在工作坊中使用交互式绘图工具（如beeart）绘制DFD模型架构图。
最后产出的一个DFD图可能如下：
![]()
（DFD-数据流图）
然而，单纯地使用威胁建模表达系统的组成结构，并没有办法得到足够的信息以产出对于假想敌的分析，这时候就需要用到“安全专业性”来对系统的每个环节进行打击了。
威胁助记词和情报知识库 —— 划分子域，并进行威胁头脑风暴
有了基本的框架，如何识别漏洞？如果我们用DDD的思维方式类比，首先需要开始划分子域的过程，然后再进行威胁的头脑风暴。
我们都知道划分子域是一个非常挑战划分者经验的过程，所幸的是，早已有存在大量的实践归纳出了多种解决方法，其中最为广泛采纳的就是STRIDE模型：
很多威胁建模初学者会使用STRIDE模型来进行系统架构的威胁建模，试图对局部信息进行一次威胁分析，这其实是一种误区。STRIDE实际上是对大量威胁种类的一种归纳，这种归纳汇总成助记词，不应该建立某个框架或者局部领域可能存在特定风险的假设，而应该实际地对每个已知的信息资产尽可能地进行遍历，即“我们应该针对每个点和连线都进行STRIDE分析，而非针对某个点进行某个方面的分析”。
例如针对系统中的”认证服务“，我们常常下意识地认为”伪装“和”提权“是它的主要威胁，但是实际上“拒绝服务”、“信息泄露”、“抵赖”乃至”篡改“都会严重影响到认证服务的安全性，例如当认证服务遭遇DDoS攻击时，我们是否有预留足够的缓存或重定向流量防止系统性风险，是否可能因为不恰当的请求返回泄露用户的在该站点的注册状态。
在思考解决方向时，则可以考虑不同诉求源语背后的威胁消解方式。它有助于我们用问题驱动的方式来解决这些具体威胁，而非仅仅依赖工具或技术手段的引入。
![]()
（威胁和与之对应的安全特性）
此外，为了扩充安全方面的经验，社区维护的CAPEC、CWE、CVE等威胁分类和情报来源，都可以帮助我们去理解一个系统的威胁来自于哪里。一些常见的威胁（攻击向量）就像领域建模里最细粒度的组件一样，共同组成了假想敌的攻击树。
![]()
（一棵由Monitoring service注入漏洞威胁出发的假想敌攻击树）
此外“业务威胁”也常常是威胁建模过程中最有优势价值的环节之一，因为威胁建模工作坊的抽象粒度较高，可以引入“业务领域专家”的参与，因此从业务视角构建“假想敌”在威胁建模工作坊中，是一个非常适合的实践。
通过威胁建模，我们可以获得一个相对全面且完善的产品威胁列表，并以此作为基石进行架构设计上的迭代，减少未来架构设计变化时，引入未知风险的盲区。
因此，相应地，威胁建模也是一个长期且需要坚持的过程，威胁建模本身所需时间并不长（通常来说，一个产品的威胁建模活动大概需要2个小时），但是其产出的威胁需求列表，常常需要上月甚至多个迭代的补足。因此，它不应该成为产品上市前夕或投产前一刻的紧急行动，而更需要成为安全左移和产品常规需求分析、架构设计、测试用例设计过程中的一部分，融合在产品研发团队的日常工作内容当中。
理想安全模型挑战 —— 经验or方法？
过去数十年，安全领域一直存在两个派系，经验主义和方法主义，经验主义通常讲究实践，因此对技术细节更为关注，容易发现常人难以意识的问题，而另一个方法派系的专家则擅长用更全面的视角去分解安全问题。而近年来，随着安全问题的升维，我们逐渐看到这两种方法的专家正在相向而行。
-
一方面，围绕漏洞利用经验，尤其是大量攻防活动中的威胁，被逐渐归纳为威胁/防御的模式库，如ATT&CK、CAPEC、CVSS的逐年完善，已经成为可以支撑威胁模型的数据集，在威胁建模活动中作为参考输入。
-
而另一个方向上，安全方法论也开始不只局限于停留在纸面文章，我们看到越来越多的安全方法论讲究与实践结合，如DevSecOps、CARTA（自适应安全）等安全方法论，都紧贴工具输出甚至业务上下文，而非局限于安全活动的执行情况审计。
这些思维的碰撞与相向而行，让我们看到更结构化、且更可预测和衡量的整体安全规划正逐渐显现。这无疑让需求设计阶段的安全活动逐渐成为了一个更科学辩证的活动，而我们有理由相信，从假想敌视角出发的“威胁建模”正是这场运动中的号角。
