威胁建模用来分析系统可能存在的风险，通常可以从三个维度来建立模型：以资产为核心、以攻击者为核心、以软件系统为核心。
一、什么是威胁建模
所谓威胁，通常是指系统的安全漏洞，可能存在于系统的具体实现上，也可能存在于系统的安全策略配置上。安全漏洞往往给攻击者提供了非授权的访问和攻击系统的入口点，达成控制或者破坏系统的目的。
业务风险也是一种典型的威胁，如航旅业务往往面临机票爬取、恶意占座等业务风险，如不能对业务风险进行有效控制，会影响业务正常开展，增加经营成本。
威胁建模是使用抽象的概念来分析系统可能存在的风险。如在业务安全这个维度，通过定位攻击目标和可利用的业务安全漏洞来提高系统安全性，然后定义防范或减轻系统业务风险的对策的过程。
从某种意义上来说，在日常生活中，我们潜意识中也在不停的实践着威胁建模。我们会关注每天的天气和气温变化，如果气温骤降，就会做出添衣的决策，如果第二天下雨的概率很大，就会做出带把伞出门的决策，从而达到降低患上感冒的可能性。
二、为什么要做威胁建模
1. 完善软件系统功能设计中的安全设计部分
绝大部分的开发团队都使用系统需求分析文档、软件系统设计文档以及功能模块详细设计文档来规范系统的开发和测试过程；整个开发周期中，只在测试阶段引入渗透测试或者安全代码审计来提高交付的系统的安全性。但是，因为设计阶段就缺少安全部分的分析设计工作，往往导致渗透测试和安全代码审计工作事倍功半，收效甚微。测试人员无法根据缺乏安全设计的设计文档来估算安全测试用例的覆盖度；研发人员也无法针对发现的威胁快速并高效的提供解决威胁的开发修复途径和安全产品采购需求。
安全代码审计和渗透测试是两种最为常见的发现威胁以提高系统安全性的方式。但是这两种方式都具备类似的缺点：很难系统化和量化系统的安全性。威胁模型更关注哪些方面可能出现安全问题，通过建模的方式将威胁抽象化和结构化，以图表帮助确定威胁的范围，并利用表格和列表的方式来追踪和更新威胁，实现在开发过程或者运维过程中识别和管理威胁。
3. 提供安全测试的设计和执行的指导
我们使用软件测试来对软件产品和阶段性的开发结果来进行质量检验，力求发现其中的各种缺陷，并督促缺陷得到修复，从而控制软件产品的质量。作为软件测试中的一个环节，安全测试的关注点是安全缺陷，保障的是软件产品的安全性质量。
软件测试可以使用软件的需求分析和定义、软件系统设计、模块详细功能设计甚至具体编码实现来指导测试的设计和执行。同样，通过威胁建模，可以在安全测试的设计和执行中获得以下指导：软件系统可能会面临哪些方面的安全威胁；系统正在遭遇哪些方面的威胁；以及系统现状能够抵御哪些方面的威胁。
4. 提供安全缺陷修复验证的指导
威胁建模是为了交付安全性更高的软件、服务或者技术。因此，在找到和定位威胁之后，如何处理和管理威胁也是威胁建模不可或缺的一个部分。威胁建模能够权衡解决威胁的策略，并指导系统的开发者使用哪些技术和系统配置方式来处理发现的各类威胁。与功能测试报告相似，表格和列表也可以应用于整体威胁建模漏洞的跟踪。
三、如何做威胁建模
下图是微软通过实践过程提出的威胁建模的过程。首先需要预设场景，在场景中，我们需要考虑具体的业务特征、真实用例以及场景中所用的产品；图表化能够帮助我们理解业务场景和系统，以及定位威胁的攻击面；然后我们需要借助特定的模型和方法来发现威胁并对发现的威胁进行评级；在处理威胁阶段，我们优先处理攻击难度低并且危害程度的威胁；最后，验证阶段，需要测试是否已经对相关威胁进行有效的处理，达到威胁建模的结果收敛，系统的安全性有效提高。
从安全角度理解正在构建的系统
威胁建模通常从三个维度来建立模型：以资产为核心、以攻击者为核心、以软件系统为核心。在实践中使用哪种建模方式往往根据系统构建者的关注点来决定的。
风控或者业务部门关注的可能更多的是资产或者有价值的东西；安全部门关注的更多的是攻击者，通过利用攻击库列表来寻找系统威胁；研发部门关注的更多的是正在构建的软件或者部署的系统，将威胁模型作为常用的软件开发模型的补充，来提高软件系统的安全性。
图表是帮助我们理解系统的最为趁手的武器。我们通常使用数据流图（data flow diagram）、统一建模语言UML、状态图来理解正在构建的系统。
而当我们在进行威胁建模的时候，我们会将图表应用于以下三个步骤来理解系统：
确认系统数据流模型；
确认信任边界；
确认攻击面。
数据流模型是进行威胁建模的最佳模型，这是因为安全问题往往是在数据流中出现，而不是在控制流中。进程、数据流、数据存储和外部实体是数据流图的四个基本要素。下图显示的是一个典型的数据流图模型。
进程：运行中的代码，如服务、组件；用圆角矩阵或圆形图形表示。
数据流：外部实体与进程、进程与进程或者进程与数据存储之间的交互；用箭头表示。
数据存储：存储数据的内部实体，如数据库、消息队列、文件等；用中间带标签的两条平行线表示。
外部实体：系统控制范围之外的用户、软件系统或者设备；用直角矩阵表示。
航旅系统某应用场景数据流图
在数据流图确认后，我们需要引入信任边界对数据流图进行改进。信任边界是不同主体汇聚的位置，即实体与其他不同权限实体之间交互的位置。信任边界是识别威胁的最佳位置，因为大部分的威胁往往具备跨越边界的行为，划分信任边界的数据流是需要进行威胁分析的元素实例。
对某应用场景的数据流图引入信任边界
在确认数据流图的信任边界后，我们可以很容易就得到当前场景暴露的攻击面。攻击面往往就是一个信任边界，使攻击者可以发动攻击的地方。
借助业务场景数据流图和信任边界的划分，我们已经对威胁最容易发生在那些地方有了一定的概念，接下去我们需要做的是找出这些威胁点可能会出现哪些具体的威胁。
STRIDE方法是由微软开发和推广的用于威胁建模的工具，该方法将威胁分为6个维度来进行评估，几乎能够覆盖目前的绝大部分安全问题。STRIDE是六个单词的缩写，分别为：
Spoofing：假冒，伪装，冒充他人身份；
Tampering：篡改，非法修改数据或者代码内容；
Repudiation：否认，否认自己的行为，宣称自己没有做过某事；
Information Disclosure：信息泄露，获取到自身权限本不能获取的信息；
Denial of Service：拒绝服务攻击，消耗系统资源，影响系统的可用性；
Elevation of Privilege：提权，获取到更高的系统权限；
结合数据流图的基本元素，使用STRIDE方法作为威胁维度来对各基本元素进行威胁分析，可以得出以下表格：
表格所描述的是作为基本元素会面临哪些维度的威胁。比如外部实体可以被伪造，并否认自己发起的行为。数据存储几乎不会被伪造，但是往往面临数据被篡改，机密数据泄露以及被拒绝服务攻击使不能服务的威胁，同时，数据存储是否会面临否认的威胁需要根据数据存储的用途，当数据存储用于审计的场景下，可能会面临伪造的威胁。
接下去我们可以使用该表格对具体业务场景进行业务风险分析，如对本文上述航旅某业务场景中的各个要素进行潜在威胁定位，可以得出以下表格：
在使用STRIDE方法分析完特定业务场景下数据流图中的所有元素示例的潜在威胁以后，我们已经得到一个抽象的威胁定位图表。接下去我们需要根据攻击库来进行威胁枚举，对各个潜在威胁构建威胁描述和攻击方法，并输出一个威胁列表，对每一个威胁项进行描述。
顶象技术在航旅、电商等现实业务攻防中积累下来的数据和经验，累积了丰富的业务风险攻击库和相应的防护方法，以威胁编号T1和T4举例输出威胁项描述如下所示：
2. 对可能会出现的威胁评级并处理
使用STRIDE方法对业务场景的数据流图分析完毕后，我们已经获取到当前系统在该业务场景下所面临的潜在威胁。接下去我们就需要一个个处理这些威胁。
在我们确认威胁处理方法之前，我们不得不以 “妥协”的想法认清一些现实：首先，有一些威胁是无法根除的，我们只能降低这些威胁发生的机会，或者提高威胁发生的门槛；其次，有一些威胁虽然存在，但是发生的概率很低，而且一旦发生，带来的危害也很小。我们需要找到一些机制来判断是否真的需要投入成本去修复这些漏洞。
正因为如此，我们需要采用威胁评级的方式，对我们定位出的威胁项进行评分，然后根据系统的实际情况和评分结果来权衡处理威胁的方式，是解决威胁还是缓解威胁或者接受威胁。
威胁评级有很多种方式，如DREAD与CVSS（Common Vulnerability Scoring System）方法。不同评级方法对威胁进行评级的维度和风险等级的计算方法会略有不同，但是总体来说，威胁的级别等于威胁发生的概率乘以威胁带来的潜在损失。在实际事件中可以根据系统或者业务场景特征选择合适的评级方法甚至对其进行调整使其适应实际情况。
DREAD风险模型的计算方式：
威胁等级：[忽略(0),严重(10)]=（危害性[0,4]+复现难度[0,4]+利用难度[0,4]+受影响用户[0,4]+发现难度[0,4]）/2
危害性（Damage）：3分：泄露机密数据，或资金损失较大；
复现难度（Reproducibility)：1分：很难复现，复现成功率较低，需要多种因素限制并对技术有较高要求；
利用难度（Exploitability）：2分：熟练攻击者可攻击，需自定制脚本或高级攻击工具；
受影响用户（Affected Users）：1分：一般边缘业务的少量用户；
发现难度（Discoverability）：1分：发现漏洞很困难，可以通过猜测或者监测网络活动来发现；
因此威胁编号T4的威胁等级 = （3+1+2+1+1）/ 2 = 4，中危级别，威胁的处理方法为使用HTTPS协议代替HTTP协议进行数据传输，或使用顶象技术设备指纹和风控引擎产品，对用户登陆事件获取实时安全防护。
类似过程可输出威胁编号T1的威胁级别和威胁处理方法如下所示：
在对所有的潜在威胁实例进行威胁评级和威胁处理方法举例之后，我们可以根据系统的业务特征，选择合适的方式来处理潜在威胁。
结语
威胁建模是一种方法论，也是一种分析模型，它并不是针对风险的解决方案。但是通过对软件或系统的威胁建模，可以帮助系统的构建者找出最适合系统和业务场景的风险解决方案。
威胁建模提供了一组规范的工具和方法用来帮助我们处理系统中潜在的安全风险，交付更安全的系统。最理想的情况是，我们在开始构建系统的时候，将安全需求分析引入系统需求分析步骤，在系统概要设计和详细涉及阶段引入威胁建模分析部分，并将其作为测试阶段安全测试工作的指导，输出测试报告的同时输出安全报告。
在现实中，很多已经上线的系统依然面临着各种的潜在威胁和业务风险，顶象技术在航旅、电商等现实业务攻防中依靠积累下来的数据和经验，累积了丰富的业务风险攻击库和相应的防护措施，通过对现有业务系统的威胁建模，输出全链路、多环节纵深风控体系，能有效保障业务的健康运营。
