利用威胁建模防范金融和互联网风险-创新互联

从B站数据遭竞品批量爬取，到华住集团信息泄露；从东海航空遭遇大规模恶意占座，到马蜂窝旅游网站事件；从接码平台日赚百万到双十一电商风险爆发.....顶象2018年第三季度业务风险监测数据显示，恶意爬取是Q3所有业务风险中占比最高，排在第二位的是虚假注册，其次是账号盗用、推广作弊及其他、薅羊毛等。

薅羊毛、盗号冒用、虚假注册、恶意爬取、推广作弊等等各种业务不仅给业务平台带来巨大经济损失，损害了用户合法权益，更破坏了商业秩序。

   其实，这些风险可以通过模型来防控。例如，在日常生活中，我们会关注每天的天气和气温变化，如果气温骤降，就会做出添衣的决策，如果第二天下雨的概率很大，就会做出带把伞出门的决策，从而达到降低患上感冒的可能性。让我们拥有这种潜意识的就是威胁模型。

所谓威胁建模，就是使用抽象的概念来分析可能存在或出现的风险，并减轻或降低风险的对策过程。通过威胁建模，可以防范上面提到的互联网业务风险；通过威胁建模更可以防范信用欺诈、虚假注册、钓鱼诈骗、信用恶化、贷款逾期等金融欺诈。

威胁建模的必要性与核心价值

完善设计

绝大部分的开发团队都使用系统需求分析文档、软件系统设计文档以及功能模块详细设计文档来规范系统的开发和测试过程；整个开发周期中，只在测试阶段引入渗透测试或者安全代码审计来提高交付的系统的安全性。但是，因为设计阶段就缺少安全部分的分析设计工作，往往导致渗透测试和安全代码审计工作事倍功半，收效甚微。测试人员无法根据缺乏安全设计的设计文档来估算安全测试用例的覆盖度；研发人员也无法针对发现的威胁快速并高效的提供解决威胁的开发修复途径和安全产品采购需求。

更好发现风险

安全代码审计和渗透测试是两种最为常见的发现威胁以提高系统安全性的方式。但是这两种方式都具备类似的缺点：很难系统化和量化系统的安全性。威胁模型更关注哪些方面可能出现安全问题，通过建模的方式将威胁抽象化和结构化，以图表帮助确定威胁的范围，并利用表格和列表的方式来追踪和更新威胁，实现在开发过程或者运维过程中识别和管理威胁。

为测试提供指导

我们使用软件测试来对软件产品和阶段性的开发结果来进行质量检验，力求发现其中的各种缺陷，并督促缺陷得到修复，从而控制软件产品的质量。作为软件测试中的一个环节，安全测试的关注点是安全缺陷，保障的是软件产品的安全性质量。

软件测试可以使用软件的需求分析和定义、软件系统设计、模块详细功能设计甚至具体编码实现来指导测试的设计和执行。同样，通过威胁建模，可以在安全测试的设计和执行中获得以下指导：软件系统可能会面临哪些方面的安全威胁；系统正在遭遇哪些方面的威胁；以及系统现状能够抵御哪些方面的威胁。

修复缺陷

威胁建模是为了交付安全性更高的软件、服务或者技术。因此，在找到和定位威胁之后，如何处理和管理威胁也是威胁建模不可或缺的一个部分。威胁建模能够权衡解决威胁的策略，并指导系统的开发者使用哪些技术和系统配置方式来处理发现的各类威胁。与功能测试报告相似，表格和列表也可以应用于整体威胁建模漏洞的跟踪。

如何做威胁建模

威胁建模是由微软首先提出，建设过程主要分为三步。

首先，在预设场景中要考虑具体的业务特征、真实用例以及场景中所用的产品，图表化能够帮助我们理解业务场景和系统，以及定位威胁的攻击面。然后，借助特定的模型和方法来发现威胁并对发现的威胁进行评级，优先处理攻击难度高并且危害程度的威胁。最后，需要测试是否已经对相关威胁进行有效的处理，达到威胁建模的结果收敛，系统的安全性有效提高。

建模的三个角度

威胁建模通常从三个维度来建立：以资产为核心、以攻击者为核心、以业务为核心。在实践中使用哪种建模方式往往根据系统构建者的关注点来决定的。比如，风控或者业务部门关注的可能更多的是资产或者有价值的东西；安全部门关注的更多的是攻击者，通过利用攻击库列表来寻找系统威胁；而研发部门关注的更多的是正在构建的软件或者部署的系统，将威胁模型作为常用的软件开发模型的补充，来提高软件系统的安全性。

图表是理解系统的最为趁手的武器，数据流图（data flow diagram）、统一建模语言UML、状态图来理解正在构建的系统。所以，我们会将图表应用于以下三个步骤来理解系统：确认系统数据流模型、确认信任边界、确认攻击面。

数据流模型是进行威胁建模的最佳模型，这是因为安全问题往往是在数据流中出现，而不是在控制流中。进程、数据流、数据存储和外部实体是数据流图的四个基本要素。下图显示的是一个典型的数据流图模型。

进程：运行中的代码，如服务、组件；使用圆角矩阵或圆形图形表示。

数据流：外部实体与进程、进程与进程或者进程与数据存储之间的交互；使用箭头表示。

数据存储：存储数据的内部实体，如数据库、消息队列、文件等；使用中间带标签的两条平行线表示。

外部实体：系统控制范围之外的用户、软件系统或者设备；使用直角矩阵表示。

在数据流图确认后，需要引入信任边界对数据流图进行改进。信任边界是不同主体汇聚的位置，即实体与其他不同权限实体之间交互的位置。信任边界是识别威胁的最佳位置，因为大部分的威胁往往具备跨越边界的行为，划分信任边界的数据流是需要进行威胁分析的元素实例。

在确认数据流图的信任边界后，就可以很容易就得到当前场景暴露的攻击面。攻击面往往就是一个信任边界，使攻击者可以发动攻击的地方。

找到可能出现的威胁

借助业务场景数据流图和信任边界的划分，我们已经对威胁最容易发生在那些地方有了一定的概念，接下去我们需要做的是找出这些威胁点可能会出现哪些具体的威胁。

STRIDE方法是由微软开发和推广的用于威胁建模的工具，该方法将威胁分为6个维度来进行评估，几乎能够覆盖目前的绝大部分安全问题。STRIDE是六个单词的缩写，分别为：

Spoofing：假冒，伪装，冒充他人身份；

Tampering：篡改，非法修改数据或者代码内容；

Repudiation：否认，否认自己的行为，宣称自己没有做过某事；

Information Disclosure：信息泄露，获取到自身权限本不能获取的信息；

Denial of Service：拒绝服务攻击，消耗系统资源，影响系统的可用性；

Elevation of Privilege：提权，获取到更高的系统权限；

结合数据流图的基本元素，使用STRIDE方法作为威胁维度来对各基本元素进行威胁分析，可以得出以下表格：

表格所描述的是作为基本元素会面临哪些维度的威胁。比如外部实体可以被伪造，并否认自己发起的行为。数据存储几乎不会被伪造，但是往往面临数据被篡改，机密数据泄露以及被拒绝服务攻击使不能服务的威胁；同时，数据存储是否会面临否认的威胁需要根据数据存储的用途，当数据存储用于审计的场景下，可能会面临伪造的威胁。

接下来，我们可以使用该表格对具体业务场景进行业务风险分析，如对本文上述航旅某业务场景中的各个要素进行潜在威胁定位，可以得出以下表格：

在使用STRIDE方法分析完特定业务场景下数据流图中的所有元素示例的潜在威胁以后，我们已经得到一个抽象的威胁定位图表。接下去我们需要根据攻击库来进行威胁枚举，对各个潜在威胁构建威胁描述和攻击方法，并输出一个威胁列表，对每一个威胁项进行描述。

顶象技术在金融、互联网、航旅等积累了丰富的业务风险经验，以威胁编号T1和T4举例输出威胁项描述如下所示：

对可能会出现的威胁评级并处理

使用STRIDE方法对业务场景的数据流图分析完毕后，我们已经获取到当前系统在该业务场景下所面临的潜在威胁。接下去我们就需要一个个处理这些威胁。

在我们确认威胁处理方法之前，我们不得不以 “妥协”的想法认清一些现实：首先，有一些威胁是无法根除的，我们只能降低这些威胁发生的机会，或者提高威胁发生的门槛；其次，有一些威胁虽然存在，但是发生的概率很低，而且一旦发生，带来的危害也很小。我们需要找到一些机制来判断是否真的需要投入成本去修复这些漏洞。

正因为如此，我们需要采用威胁评级的方式，对我们定位出的威胁项进行评分，然后根据系统的实际情况和评分结果来权衡处理威胁的方式，是解决威胁还是缓解威胁或者接受威胁。

威胁评级有很多种方式，如DREAD与CVSS（Common Vulnerability Scoring System）方法。不同评级方法对威胁进行评级的维度和风险等级的计算方法会略有不同，但是总体来说，威胁的级别等于威胁发生的概率乘以威胁带来的潜在损失。在实际事件中可以根据系统或者业务场景特征选择合适的评级方法甚至对其进行调整使其适应实际情况。

DREAD风险模型的计算方式：

威胁等级[ 忽略(0), 严重(10) ] = (危害性[ 0, 4] + 复现难度[ 0, 4] + 利用难度[ 0, 4] + 受影响用户[ 0, 4] + 发现难度[ 0, 4] ) / 2

以威胁编号T4举例，其威胁等级计算过程如下：

危害性（Damage）：3分：泄露机密数据，或资金损失较大；

复现难度（Reproducibility)：1分：很难复现，复现成功率较低，需要多种因素限制并对技术有较高要求；

利用难度（Exploitability）：2分：熟练攻击者可攻击，需自定制脚本或高级攻击工具；

受影响用户（Affected Users）：1分：一般边缘业务的少量用户；

发现难度（Discoverability）：1分：发现漏洞很困难，可以通过猜测或者监测网络活动来发现；

因此威胁编号T4的威胁等级 = （3+1+2+1+1）/ 2 = 4，中危级别，威胁的处理方法为使用HTTPS协议代替HTTP协议进行数据传输，或使用顶象技术设备指纹和风控引擎产品，对用户登陆事件获取实时安全防护。输出威胁项中威胁级别和威胁处理方法如下所示：

类似过程可输出威胁编号T1的威胁级别和威胁处理方法如下所示：

在对所有的潜在威胁实例进行威胁评级和威胁处理方法举例之后，可以根据系统的业务特征，选择合适的方式来处理潜在威胁。

针对电商、航旅等2C业务风险的威胁处理方法，我们需要谨慎评估和实施，尤其是当威胁实例（被攻击的目标）属于外部实体或者与外部实体相连的数据流/信任边界类别时。这是因为2C的业务在考虑到业务安全性的同时，更需要考虑到用户体验的友好性和易用性。如威胁编号T1的处理方案中，虽然强制要求用户登陆状态才能进行查询航班信息能够在短期内快速有效的降低爬票的风险，但是提高了正常用户使用系统的门槛，带来了明显的“副作用”，不利于长期的发展。

   顶象技术基于业务风控实战经验的积累，以威胁建模的方法论对业务风险抽象化分析，帮助业务更好的识别风险，针对各行业不同的业务风险，预设了大量的风险指标、策略和模型，并通过实时分析模型，让风控系统可以以机器学习的方式，更好的适应业务风险的变化。

对于上述案例中威胁编号T1，借助顶象Dinsight风控引擎和端安全，建立全面的数据反爬体系。

同时采用可分级的反爬策略配置，实现对同一业务的不同场景、同一场景的不同区域、时段采用不同的策略。以下是通过顶象Xintell智能平台构建的威胁模型。

对于上述案例中威胁编号T4，借助顶象技术的Dinsight风控引擎和端安全，对用户请求采集多维度行为数据，将设备维度信息、用户行为维度信息以及环境维度信息提交至实时风控引擎，调用账号安全策略进行综合计算评估，识别账号盗用的风险。

结语

威胁建模是一种方法论，也是一种分析模型，可以帮助系统的构建者找出最适合系统和业务场景的风险解决方案。

威胁建模提供了一组规范的工具和方法用来帮助我们处理系统中潜在的安全风险，交付更安全的系统。最理想的情况是，我们在开始构建业务系统时，将安全需求分析引入系统需求分析步骤，在系统概要设计和详细涉及阶段引入威胁建模分析部分，并将其作为测试阶段安全测试工作的指导，输出测试报告的同时输出安全报告。

本文对威胁建模基本原理、建模过程和主流的建模方法进行了介绍。同时也提出，当使用威胁建模对业务体系进行抽象分析，需要考虑到（2C）业务安全区别于传统信息安全的不同处，在处理威胁的阶段，需要权衡修复成本的同时，更需要考虑到威胁修复方案对用户体验友好性和易用性的影响。

顶象技术在金融、互联网等现实业务攻防中依靠积累下来的数据和经验，在保障业务安全的方面，具备以下优势：

1.丰富的垂直业务领域威胁建模经验，覆盖信贷、支付、交易、交互等场景。

2.丰富的业务风险攻击库和相应的防护措施，围绕威胁建模过程，输出全链路、多环节纵深风控体系，能有效保障业务的健康运营。

3.多年的实战对抗经验积累，预设数百个风险指标、风险策略和风险模型，实现业务安全的瞬间赋能。

4.强大的Dinsight风控引擎，能够在毫秒级作出响应，利用策略和实时计算，同步识别风险，直接阻断恶意风险，或通过二次验证确认疑似风险。

5.Xintell智能平台集成了丰富的风险防控等模型，以帮助企业利用数据建设一个更安全的生态环境为目标，提供了一站式数据处理、AI建模、运维管理等服务。

6.基于关联网络构建的图神经网络算法的深度画像技术，可应用半监督学习和无监督学习表征等，能够直观的体现目标网络的结果和预测。