SDL-STRIDE威胁建模

0x00背景介绍

      威胁建模工具是 Microsoft 安全开发生命周期 (SDL) 的核心要素。潜在安全问题处于无需花费过多成本即可相对容易解决的阶段，软件架构师可以使用威胁建模工具提前识别这些问题。因此，它能大幅减少开发总成本。此外，我们设计该工具时考虑到了非安全专家的体验，为他们提供有关创建和分析威胁模型的清晰指导，让所有开发人员都可以更轻松地使用威胁建模。

0x01使用场景

Microsoft 安全开发生命周期 (SDL)的威胁建模的使用场景有2个部分：

1. 业务需求生成后，软件设计前进行，形成软件开发的安全需求文档。这个需要跟业务和开发部门沟通配合，如果从0开始，可以考虑从一些不重要的或者开发时间充裕的需求开始。让参与的业务运营产品等同事和开发人员了解项目开发可能遇到的风险，通过头脑风暴的会议讨论形成威胁建模报告，可能第一次考虑不全，但是只要一直继续下去，效果会越来越好。
2. 业务已经在线上运行，安全人员可以通过梳理业务功能，通过威胁建模的方式发现可能存在的风险点，结合渗透测试，查看是否有控制措施，控制措施是否有效，并能减少渗透测试遗漏的测试点。这个与其他部门沟通的工作较少，主要是能够全面了解组织的业务，安全人员可以自己来做。
3. 外包开发工作，加入一个安全需求的要求就行，要求甲方安全人员参与和监督威胁建模的执行，审核软件开发的安全需求，确定好关系人员和责任。

 

威胁建模不算是风险评估，比实际的风险评估工作的范围和工作量要小，是 SDLC 过程的一部分，实际做起来要比想象中的难度小。同样威胁建模的工作过程也是对开发和业务的安全意识培训，有条件的话越早执行越好。

0x02 STRIDE概念定义

威胁建模的本质：尽管通常我们无法证明给定的设计是安全的，但我们可以从自己的错误中汲取教训并避免犯同样的错误。其中，STRIDE的定义与相应的安全属性如下：

威胁	安全属性	定义	例子
Spoofing（假冒）	认证	冒充某人或某物	诈骗短信、**网站广告短信、游戏外挂
Tampering（篡改）	完整性	修改数据和代码	修改打卡时APP提交给服务器的经纬度数据，无论身处何处都可以打卡成功
Repudiation（否认）	不可抵赖性	宣称未做过某个行为	“我没有发送email” “我没有修改文件” “我肯定没有访问那个网站”
Information Disclosure（信息泄露）	机密性	暴露信息给未经授权的访问者	越权访问；将客户列表发布在网站上
Denial of Service（拒绝服务）	可用性	用户无法访问或访问出现故障	发送数据包使目标系统CPU满负荷或发送恶意代码使目标服务崩溃
Elevation of Privlege（权限提升）	授权	未经授权获取权限	垂直越权漏洞、普通用户可以执行管理员私有的系统指令

 

0x03 STRIDE威胁建模流程

总体流程

威胁分析就是把所有威胁都找出来，建模过程分为6步：

1.标识机密信息

2.建立体系结构

3.分解应用

4.辨别威胁

5.将威胁文档化

6.评定威胁级别

具体步骤

第一步标识机密信息：

1. 哪些是机密信息呢？一般是保密数据（如客户清单，其他人的工资，管理员口令），私有数据（如知识产权保护的数据），重要数据（如卡号，加***等），还有数据库的完整性，页面的完整性，网络与计算机的完整性，应用可用性。
2. 业务场景的分解，比如登录场景、支付场景、灾备场景、热启动场景等

首先对一个具体的场景绘制数据流图（DFD）

微软的STRIDE威胁建模工具

 

第二步，建立体系结构，目的是为了更好的理解系统架构，为辨别威胁做准备。

  具体就是定义应用的目的与实现方法，并绘制应用架构图，包括标识子系统，标识数据流，列出系统中的机密。

第三步，分解应用结构图，包括认证机

制，授权机制，标识所用的技术，描述信任的边界，标识系统的入口。像黑客一样思考。

第四步，辨别威胁。方法有3种，

第一是威胁清单。

第二种是STRIDE。

第三种是威胁树（根节点（表示攻击者的目的），子节点用来描述威胁的子威胁与条件）。

当这个攻击树设计的足够完整，就能很好的防住黑客。当然基于攻击树的威胁建模劣势也非常明显，由于和攻击者的思路完全一致，所以对设计攻击树的安全人员的安全技能和攻防经验要求非常高，由于人才的缺乏，在实际中很难大面积展开。

第五步：文档化

第6步，评定威胁级别

2种方法：

一是简单模型法：风险=资产重要性（1-10级）*威胁等级（1-10级）

二是DREAD 模型法：将级别分为1-15，在微软公司广泛使用。

更接近这样的流程：应用程序建模(Diagram)、枚举威胁(Identify)、缓解威胁(Mitigate)、验证缓解措施(Validate)。

0x04 STRIDE威胁建模工具

STRIDE威胁建模的核心元素：

• 圆形：表示进程

如：Web服务、Win32服务、linux 守护程序等。在很多STRIDE相关资料里都是写的圆形表示的进程，这里其实不太准确、都是从英文中的process直译的，其实根据业务场景的不同，圆形可能不只是进程，如果场景被分解的很大，有可能一个芯片是一个圆形，也可能一台服务器是一个圆形。圆形就是我们要分析的业务场景中的一个运算处理数据的单元，可以叫做处理过程。绝大部分资料都称为进程，所以这里还是延用这个名字，但是我们如果在实际做STRIDE威胁建模的时候要知道，这里的圆形绝不仅仅只能表示狭义的进程，直接用英文的process更准确。

• 双横线：数据存储

能存储数据的任何位置，如数据库，配置文件、日志文件、注册表等等。

• 带箭头的线条：数据流

表示数据在各个组件之间的流动，注意流动是要区分方向的，例如两个组件之间的数据流动如果是双向的，那在数据流图中就应该在这两个组件之间画出两条数据流。

• 方形：外部实体

与系统交互但不在应用程序控制之下的任何要素，例如用户。

数据流图除了这四个核心组件外，其实在图上还会看到虚线的线段，这个是信任边界，如果数据流在不同的信任域之间流动，就应该画上这个表示信任边界的虚线，但由于信任边界在后续的STRIDE威胁分析中不会对其进行分析，所以核心元素只包含：进程、数据存储、数据流、外部实体四种，不包含信任边界。

绘制完数据流图以后，就是对数据流中的每个元素可能面临的威胁逐个进行分析，但不是每个元素的STRIDE六类威胁都要去分析。

上图表示每类元素可能面临的威胁，可以看出，只有进程才可能面临STRIDE 6种所有威胁，需要对6种威胁逐个全部分析，外部实体只有S和R项有√，即是指外部实体只可能面临“仿冒”和“抵赖”两种威胁，数据流对应的TID有√，数据流就只分析“篡改”、“信息泄露”、“拒绝服务”三种威胁。

在数据存储这里有个需要注意的，R项的勾是红色，是指数据存储的R（抵赖）可能有也可能没有，只有当分析的数据存储用作审计时，才要去分析R抵赖的威胁，不作为审计使用就不用分析R抵赖威胁。

输出威胁列表和消减方案

当分析完数据流图中的所有对象的潜在威胁以后，就要输出一个威胁列表，威胁列表中的每个威胁项形如下面这样的表格：

组件（威胁的目标）	Web应用程序用户身份验证进程
威胁描述	攻击者通过监视网络获取身份验证凭据
威胁类别	I
攻击方法	利用网络监视软件
消减方案（对策）	利用SSL提供加密通道
危险评级

其中很重要一项就是，消减方案，做这个威胁建模的目的不仅要发现危险，更重要还要提出解决威胁的办法。这里叫“消减方案”而不是“消除方案”是因为在实际做STRIDE威胁分析时，我们发现的每个威胁，由于各种实际原因不一定能肯定根除。

0x05 威胁评级DREAD

威胁评级

根据威胁造成的危险对其进行评价。这样就能够首先解决危险最大的威胁，然后再解决其他的威胁。实际上，解决所有找出的威胁也许在经济上是不可行的，可以进行决策，忽略掉一些，因为它们发生的机会很小，即使发生，带来的损失也很小。 那依据什么标准对威胁评级呢？

简单评价系统： 危险 = 发生概率 × 潜在的损失

这种评价方式很容易理解，发生概率大，潜在损失也大的威胁肯定危险等级最高；而发生概率低，潜在损失也低的威胁危险等级最低。发生概率大损失小或者发生概率小损失大的，危险等级就居中。 实际做STRIDE威胁分析时就是用的这种简单评价方式，评价简洁实施容易，但由于评价标准单一，对于有争议的威胁就可能出现大家对危险等级的评级意见不统一。

DREAD威胁评级模型

如何更科学的衡量风险呢？DREAD威胁评级模型

DREAD分别是威胁评级的6个指标的英文首字母。

• 潜在损失(Damage Potential) 如果缺陷被利用，损失有多大？
• 重现性(Reproducibility) 重复产生攻击的难度有多大？
• 可利用性(Exploitability) 发起攻击的难度有多大？
• 受影响的用户(Affected users) 用粗略的百分数表示，多少用户受到影响？
• 可发现性(Discoverability) 缺陷容易发现吗？

等级	高（3）	中（2）	低（1）
潜在的损失 Damage Potential	获取完全验证权限，执行管理员操作，非法上传文件	泄露敏感信息	泄露其他信息
重现性 Reproducibility	攻击者可以随意再次攻击	攻击者可以重复攻击，但有时间限制	攻击者很难重复攻击过程
可利用性 Exploitability	初学者短期能掌握攻击方法	熟练的攻击者才能完成这次攻击	漏洞利用条件非常苛刻
受影响用户 Affected users	所有用户，默认配置，关键用户	部分用户，非默认配置	极少数用户，匿名用户
可发现性 Discoverability	漏洞很显眼，攻击条件很容易获得	在私有区域，部分人能看到，需要深入挖掘漏洞	发现漏洞极其困难

这6个指标每个指标的评级分为高中低三等，最终威胁的危险评级由这6个指标的加权平均算出。比如前不久刚爆出的CPU芯片的Meltdown和Spectre漏洞，这个威胁因为是涉及硬件底层的漏洞，所以在其上面运行的任何软件或者系统都可能受到影响，而不像通常的某个软件的漏洞，只针对对应的软件。

所以这个漏洞在“潜在的损失”（Damage Potential）这项评分一定是高，但在“可发现性”（Discoverability）这项评分上就是低，因为这个底层的漏洞非常难发现，需要有非常丰富经验和技术的研究者花很多时间和精力才可能发现的，事实上这个漏洞的确也是存在了很多年一直没有被发现。类似如此对每项指标逐一评级后就能算出最终的危险评分。每项评级的评定标准参考上表。

0x06 威胁实践

• 威胁建模的开展不易

进行威胁建模会增加很大的成本，为了消减某项潜在的威胁，开发人员需要在原有功能的代码上增加更多的业务功能以外的代码来提高安全性，增加的这个开放量有时甚至会接近某项功能本身的代码量。增大了成本投入，而另一方面对于现在绝大部分产品来说，安全性的增强对于用户来说是不敏感的，用户需要的是功能，不出安全问题是理所应当的，安全性很难作为卖点。不仅如此，往往安全性的提升还会带来用户体验的下降，比如前面提到的12306订票网站的奇葩验证码就是一个典型例子，又比如对密码复杂度的要求、连续密码输错锁定帐号一段时间等等这些安全措施都会降低用户体验。 所以威胁建模的开展不易，小公司、创业公司很难投入这个成本去做这件事情，通常都是一些大型公司或是对安全性特别敏感的企业才有条件去做这个事情，因为对于这些公司一旦发生安全事件会对其带来非常大的损失和负面影响，例如2014年携程网爆出漏洞，可导致用户的信用卡信息泄露，受此事件影响，携程股价一度暴跌近10%。

• 安全人员与设计开发人员的充分沟通

做威胁建模的人员都是安全专业的人，而不是对应业务的开发人员，对业务系统并不了解，所以在每次做威胁建模的时候，安全人员首先都要和对应业务的开发人员进行深入的沟通，而且这个沟通在威胁建模进行过程中还会反复进行， 因为安全人员只有充分了解了具体的业务场景，才可能发现其中的潜在威胁。 但实际情况是沟通常常不充分，一方面因为开发人员对他正在开发的这个系统已经非常熟悉，一些他认为不重要或者很简单的东西直接就省略不提，但这个系统对于安全人员来说可能是第一次接触，这样导致一些细节安全人员就没有了解清楚，一些潜在威胁有可能就藏在这些细节里面。 另一方面，安全人员和开发人员从某种程度来说是对立的，因为最终发现的威胁都会提交给开发者去修复，开发者对安全的认识不一定深刻，对一些威胁他可能认为并不重要，但为了消减这个威胁，比如本来100行代码就能完成的功能，需要增加到几百行代码或者是破坏了他代码原本的结构，开放人员往往是不乐意的。所以在业务沟通时，甚至可能故意隐瞒一些细节。

• 不是所有威胁都能得到及时修复

威胁建模发现的问题不是每项都一定会解决，因为有些威胁可能会导致大量代码的改动，甚至很难修复，但潜在危险并不大，就可能考虑暂时不修复。另外也可能由于发版本的时间节点压力，已经没有足够的时间修复，就会推迟到下一个版本再修复。

0x07 参考文档

微软官方原文：https://docs.microsoft.com/zh-cn/azure/security/azure-security-threat-modeling-tool

先知社区：https://xz.aliyun.com/t/2061