STRIDE威胁建模漫谈

声明：本文由expsky@360 A-Team原创，仅用于研究交流，不恰当使用会造成危害，严禁违法使用，否则后果自负。

前言

STRIDE是微软开发的用于威胁建模的工具，或者说是一套方法论。

在介绍STRIDE威胁建模之前，我们需要了解两个重要的安全概念：安全属性和安全设计原则。

安全属性和安全设计原则并没有一个绝对的标准答案，不同资料介绍安全属性是和安全设计原则会有区别，从不同的侧重点或者不同的角度描述答案不一定相同，所以我们不用纠结于此。

安全属性

说到安全属性首先想到的就是CIA，这里的CIA不是美国中央情报局的缩写，而是Confidentiality （机密性）, Integrity （完整性）, 和 Availability （可用性）三个英文单词的首字母。

机密性：保证机密信息不被窃取，窃听者不能了解信息的真实含义。

完整性：保证数据的一致性，防止数据被非法用户窜改。

可用性：保证合法用户对信息资源的使用不会被不正当的拒绝，如DOS攻击。

除了CIA三个最常见的安全属性外，这里再补充三个：

鉴权：身份验证，建立用户身份。

授权：明确允许或拒绝用户是否能访问资源，访问哪些资源。

认可（不可抵赖)：用户无法在执行某操作后否认执行了此操作。

鉴权和授权比较容易混淆，从名字上看很相似，但是它们是不同的两个安全属性。鉴权是指是否需要验证身份，而授权是指验证身份的等级。

打个比方，现在很多公园都是免费对外开放，而以前是收费凭门票进入。这里的是否需要门票就是鉴权问题。

而还有些公园，不仅需要门票进入，进入以后根据门票的不同，可以游玩的区域和设施是不一样的，只有购买了通票才可以游玩所有区域。这个通票就是我们这里说的超级管理员或者root账户。不同的角色分配不同的权限等级，即为授权。

安全设计原则

下面列出了十个安全设计原则：

原则1 最小攻击面

原则2 默认安全

原则3 权限最小化

原则4 纵深防御

原则5 失败安全

原则6 不信任第三方系统

原则7 业务隔离

原则8 公开设计

原则9 简化系统设计

原则10 使用白名单

每个原则在一些SDL相关的书籍中都有定义，这里说下我个人的理解：

最小攻击面

我们在一些web安全防护建议中经常会提到“关闭不必要对外开放的端口”，这就是最小攻击面的一项措施。在网络攻击的生命周期中一个重要环节就是信息收集，这个环节往往也是黑客耗费时间精力最大的一个环节，对最终黑客的攻击成果起了至关重要的影响，越是有经验的黑客，会花更多的时间和精力在信息收集上面，这步做的好，后面就能一击命中。

当我们最小化攻击面这个安全原则做的好，就会大大影响黑客信息收集的成果，最终挫败黑客的攻击。

默认安全

系统的默认配置带来的安全问题，比如早期一些路由器出厂默认的帐号是admin密码也是admin，使用默认帐号密码扫描类似的这些系统，当你扫描的基数逐渐增多时，一定会有意想不到的收获。

权限最小化

这也是很多人常犯的错误，一个root账号搞定所有系统，虽然维护方便了，但是当黑客攻破任意一个系统就直接拿到了最高权限。

纵深防御

不要把所有的精力只用在一点的防御上，一点防御的再强，也可能会出现0day漏洞，无法保证100%的安全。 层层设防，多样化，多层次、纵深的防御措施。攻破一层或一类防护后，无法破坏整个信息基础设施或应用系统。 

比如：SQL注入攻击的直接原因是拼接SQL参数导致的，因此防止SQL注入攻击我们首先想到的就是SQL语句预编译的方法，除此之外部署WAF系统在外围首先进行拦截，数据库的敏感数据加密保存使得即便被黑客攻入，窃取出去的数据也无法还原出原始信息等多重防御方法结合使用，就是纵深防御。

失败安全

当异常发生时，异常处理代码处理不当，可以导致意想不到的问题，比如权限提升、信息泄露等。这也是不懂安全的开发人员经常忽视的，而在黑客攻击kill

chain的信息收集阶段，又是被黑客经常利用的，黑客对攻击目标故意输错url参数或者路径、构造异常post数据，导致服务器出错，如果开发人员对这里的错误处理不当，就会导致敏感甚至重要的信息被泄露，为黑客的下一步攻击提供重要的线索和思路。这些都是在真实案例中见到过的。

另外，漏洞挖掘中的fuzz模糊测试，其实也是通过各种非常规数据的输入设法把程序给搞崩溃，进而发现可能存在的漏洞。

不信任第三方系统

现在的系统越来越复杂，很多都是模块化、组件化的，需要引入第三方的模块或者和第三方的业务系统对接并使用其提供的数据，我们无法掌控第三方系统的安全性，如果其存在漏洞被攻击，需要保证我们自己的系统不会因此而受到影响。这个威胁也排进了OWASP

Top 10：“使用含有已知漏洞的组件”。

业务隔离

简单一句话就是不要把所有鸡蛋都放在一个篮子里，不至于一个系统被攻破就让黑客拿到了一把“万能钥匙”，可以操作所有的业务功能。

公开设计

如果是初次接触这个安全原则，可能会很难理解。通常会认为不要让我们的源代码泄露，更不能让加解密相关的重要源码泄露。但依据“公开设计”的安全原则，我们可以开放源代码后、我们的系统依然是安全的。一个典型相悖于“公开设计”原则的例子就是私有加密算法，误以为使用自己设计的加密算法更加安全。正确的做法是使用标准的RSA、AES等对称或非对称加密算法，我们数据的安全性不应该依赖于算法的保密性，而是确保加密密钥的安全，只要我们的密钥位数足够长，密钥不被泄露，那我们加密的数据就是安全的。

而在我接触到的真实黑客渗透中，黑客收集目标系统的信息，首先使用常规手段无法攻破系统后，如果这个系统因为是开源或者通过其他手段能拿到全部或者部分源码，经常黑客就会深入去研究系统的源代码，而常常能找到系统的漏洞或者突破口，进而发起进一步的攻击。这也是违反了“开放原则”。完全做到“开放设计”在实际中还不太多，也比较困难。但我们应该逐渐形成这样的意识，尽可能从保护源代码的思维转化为开放设计的思维

，理想的目标就是做到把所有源代码开放给黑客，黑客也无法攻破系统。

简化系统设计

做安全不久后，以前一直有个疑问困扰着我，就是安全防御技术越来越强，防御手段越来越多，漏洞被不断发现和修补，是不是以后安全问题就越来越少，最终就能几乎消灭所有安全问题？

“简化系统设计”原则从侧面一定程度解答了这个疑问，随着信息技术、互联网技术的高速发展，系统功能变得强大的同时，系统也变得越来越复杂。越复杂的系统就越容易出现漏洞，特别像是逻辑漏洞这种，漏洞没有固定的模式、固定的特征，很难通过安全设备来防御。复杂度的提高通常也会导致攻击面变大。所以我们尽量简化系统设计，当有多种系统设计方案时，应该尽量选择最简单的那种方案。

使用白名单

与白名单相对的就是黑名单，白名单机制可能导致“误杀”，而黑名单机制可能导致“误放”。在平衡“误杀”与“误放”时，通常更倾向于“误杀”，因为一旦“误放”我们系统就被黑客攻破，而“误杀”带来的其他问题可以设计诸如手动添加白名单等机制来解决，同时白名单机制还有可能能够防御各种未发现的安全隐患。

关于安全的思考

如果没有网络攻击，是没有必要搞网络安全的，网络安全的本质是攻防对抗，安全即是攻防双方一个博弈对抗的过程。

防守比攻击更难

这是一个业界普遍认可的观点，当然前提是攻击者水平和防御者水平势均力敌。防御是木桶效应，整个系统的安全性不是取决于防御最强的地方，也不是系统的平均防御能力，而是取决于系统当中最薄弱的环节。

在一些安全攻防技术分析文章中，经常听到一个词语“绕过”，在web安全、终端安全、二进制安全等方向都经常听到，比如通过各种编码机制“绕过”WAF的检测、通过白加黑技术“绕过”杀毒软件的查杀、通过ROP技术“绕过”DEP的保护。花费大量精力精心设计的防御措施，黑客往往并不和你正面冲突的强攻对抗，而是以四两拨千斤的巧妙方式“绕过”了我们精心设计的防御系统。这些都说明了攻防对抗上的不平衡，防守比攻击更难。

攻击者的脑洞比理论、学识更关键

虽然攻击方也有类似kill chain这样的理论方法、但在我实际接触到的一些案例中攻击者是不太讲究理论方法的，特别是在一些关键点攻击的突破上更是这样，更多的是攻击者的一些“奇思妙想”、脑洞大开。

这里举几个我以前接触过真实的例子，杀毒软件对自身进程的保护是相当严密的，杀软自身进程如果都被病毒木马给杀掉了，那对系统的保护就无从谈起。以前就发现过某知名杀软某个dll提供了一个强制结束进程的接口，木马通过调用这个接口可以关闭杀软自己的进程，攻击者想到的这种“杀软自杀”的方式真是非常的巧妙。这个案例已经是很多年前的事情了，现在想直接通过技术手段关闭杀软的可能性微乎其微，但去年我做过一个实验，通过“非技术”手段成功关闭杀软，所谓非技术手段就是通过模拟点击的方式，完全模拟人正常关闭杀软的流程和步骤，攻击方式真的是防不胜防。

又比如在钓鱼攻击中，攻击者是通过相似英文字母的混淆，或者是子域名的错位方式来构造虚假的钓鱼网址。但是这样的钓鱼网址仔细看肯定是能够发现其中的差异的。但是同形异义字钓鱼攻击，真的是肉眼无法识别，不信我们看下面这个网址： http://www.јԁ.com 

这个是京东的网址，没有错吧？但是这次眼睛被欺骗了，这个不是京东的网址，不信可以将这个网址复制到浏览器试一下。

这就是所谓的同形异义字钓鱼攻击，这样的钓鱼攻击即使是有经验的人也很难发现（关于同形异义字钓鱼攻击这里就不详细介绍了，可以见我以前写的这篇文章：http://www.freebuf.com/articles/web/136729.html）。

上面介绍的几个案例是想说明攻击者的攻击方式真的是奇思妙想、五花八门，相比理论、学识，黑客的脑洞、天赋、兴趣显得更加关键，这也是为什么会出现少年黑客。周鸿祎最近的一次访谈里也说过黑客很难批量培养。 那安全防御能像攻击这样，也靠奇思妙想而不讲究理论方法吗？

需要安全理论、方法论的支撑，才能做好防御

如果防御不讲究方法、没有方法论的指导，也像攻击者一样只靠脑洞，必然百密一疏，总有疏漏。攻击者往往攻击目标都是多个，这个攻不破还可以换下一个，主站无法攻破还可以从周边副站突破，而防守必须防住来自各个方位，不同时间的攻击，所以必须要有行之有效的方法论来指导我们能够按部就班的做好防御。威胁建模就是这样一种理论。

什么是威胁建模

威胁建模是一种结构化方法，用来识别、量化并应对威胁，利用抽象的方法来帮助思考风险。威胁建模允许系统安全人员传达安全漏洞的破坏力，然后定义防范或减轻系统威胁的对策，并按轻重缓急实施补救措施。

威胁建模的通用原则步骤：

第 1 步：标识资源

第 2 步：创建总体体系结构

第 3 步：分解应用程序

第 4 步：识别威胁

第 5 步：记录威胁

第 6 步：评价威胁

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

何时做威胁建模

不像诸如渗透测试等是在已经完成的系统上进行，威胁建模是在设计阶段就开展。

只有在设计阶段，才有最大的弹性空间可进行威胁消除更改。最理想的结果就是通过设计来消除潜在威胁。这样做比添加安全防护功能、进行测试更加容易。

因为消除不是随时想做就能做到。当产品日益成熟，消除威胁将更加困难，相比于开发早期采用的威胁建模，这需要更多投入与更高难度的取舍。

威胁建模的方法

基于攻击树模型的威胁建模

STRIDE威胁建模

什么是攻击树模型？

如上图，小偷想进入房内盗窃，就会构思出一个类似如下的一个攻击树。 

树根就是小偷的终极目标“入室盗窃”，从树根开始向下蔓延（这里省略，只写了两层），每个节点都是一个子目标，每个子目标又可以通过不同的方式来达成。整个分解构建攻击树的过程就是一个头脑风暴的过程，攻击者从攻击树的任何一条路径走到底部的树根，就是成功。所以攻击树构建的越大，通向树根的路径就越多，那么攻击者成功入侵的可能性也就越大。

 而基于攻击树的威胁建模就是和黑客构建这个攻击树的过程完全一样，攻击树构建完成后就对攻击树的每个节点设计相应的防御措施或者消减方案。 基于攻击树的威胁建模的优势就是和黑客攻击的思路完全一样，防御黑客攻击直接了当，很容易理解。

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

STRIDE威胁建模

STRIDE是微软开发的用于威胁建模的工具，或者说是一套方法论，它把威胁分成如下6个维度来考察：

Spoofing（伪装）

Tampering（篡改）

Repudiation（抵赖）

Information Disclosure（信息泄露）

Denial of Service（拒绝服务）

Elevation of Privilege（提升权限）

STRIDE威胁模型几乎可以涵盖目前绝大部分安全问题。并且有着详细的流程和方法。

威胁定义对应的安全属性

Spoofing冒充他人身份认证

Tampering修改数据或代码完整性

Repudiation否认做过的事不可抵赖性

Information   Disclosure机密信息泄露机密性

Denial   of Service拒绝服务可用性

Elevation   of Privilege未经授权获得许可授权

STRIDE 六种威胁刚好与前面介绍的6个安全属性对应：

Spoofing（仿冒）

我们都或多或少收到过伪基站发送的诈骗短信或是赌博网站广告短信，伪基站在全国各地存在了多年，给社会带来了很大危害。

伪基站的工作原理就是对应的“仿冒”威胁，手机终端都是连接到就近的移动基站上面，而伪基站相对于手机来说就是仿冒了真正的移动基站，这实际上是利用了2G

GSM移动通信中的一个鉴权漏洞，基站会鉴定手机的合法性，但手机不会去鉴定基站的合法性。这样就使假冒的运营商基站也可以和手机之间通信，从而实现了‘伪基站’的技术。这个GSM的鉴权漏洞导致的“仿冒”威胁在3G、4G通信中已经修复，但为什么我们的3G/4G手机同样也收到过伪基站发来的诈骗短信呢，是因为伪基站同时又引入了信号干扰技术，利用手机的主动降频机制，当3G/4G信号不好时，手机会自动降低自己的工作制式到2G，这样就又可以利用GSM的鉴权漏洞，实施“仿冒”攻击。

游戏外挂也是存在多年的一个黑色产业，游戏外挂有三种大类，第一类是通过按键精灵之类的工具制作的模拟操作的外挂，这样的游戏外挂相对技术含量低，功能有限；第二类是篡改或注入游戏进程，修改内存数据的，这类游戏外挂数量最多；而最后第三种就是技术水平最高级的脱机外挂，完全破解游戏的通讯协议，不再需要打开真正的游戏客户端和游戏操作界面，自动完成所有操作，自动进行游戏，这种脱机外挂也是典型的客户端“仿冒”攻击，对于游戏服务器端来说，不能识别客户端这边是真正玩家操作的游戏客户端，还是全自动的外挂机器人在与服务器通信。

上面就是针对当年风靡一时的偷菜游戏的脱机外挂，不用再打开浏览器登录QQ空间，自动就完成了偷菜等操作，偷菜是网页游戏、PC端游的脱机外挂会复制更多。

还记得被全国网友诟病的12306订票网站的奇葩验证码吧，其目的就是想防止抢票软件，验证是否是真实旅客的正常手动操作，而抢票软件本质上也是一种仿冒攻击。

Tampering（篡改）

举一个身边真实例子，我一个在某世界500强公司做逆向分析的前同事，他们公司移动OA的APP上可以进行上下班的打卡，当在公司附近一定的范围内，通过这个功能就可以打卡成功，超过公司一定范围，打卡就会失败，他发现一个漏洞，通过修改打卡时APP提交给服务器的经纬度数据，无论身处何处都可以打卡成功，这个例子对应的就是“数据篡改”威胁。后来将这个漏洞提交给了IT部门进行修复。

Repudiation（抵赖）

主要指的就是需要保留必要的审计日志、在发生了攻击事件后才可能进行追踪溯源。 Information Disclosure信息泄露和DOS拒绝服务按照字面意思理解，就不再赘述。

Elevation of Privilege（权限提升）

经常我们在windows发布的漏洞补丁的说明里，可以看到权限提升相关的漏洞，另外在web攻击里面一个常见的垂直越权漏洞对应的也是“权限提升”威胁。

STRIDE建模的第一步就是分解业务场景，绘制数据流图(DFD)

威胁建模针对的是一个个具体场景，所以首先需要对我们的系统根据实际情况进行业务场景的分解，比如登录场景、支付场景、灾备场景、热启动场景等等，具体是什么场景以及有多少个场景，是和实际的系统和业务息息相关的，比如京东的电商系统、阿里的公有云系统、华为的移动通信系统，它们的STRIDE威胁建模分解出来的业务场景肯定是完全不一样的。

分解完业务场景以后，就对一个一个的场景分别进行STRIDE威胁建模，每个场景的STRIDE威胁建模是相对独立的。 

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

上面就是一个数据流图的范例， 微软提供了专门的STRIDE威胁建模工具，其中就包含了绘制数据流图的功能。

上图就是微软的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威胁分析时，我们发现的每个威胁，由于各种实际原因不一定能肯定根除。

需要投入多大成本去解决威胁，依据的就是上表中的威胁评级。

威胁评级

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

那依据什么标准对威胁评级呢？

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

这种评价方式很容易理解，发生概率大，潜在损失也大的威胁肯定危险等级最高；而发生概率低，潜在损失也低的威胁危险等级最低。发生概率大损失小或者发生概率小损失大的，危险等级就居中。

实际做STRIDE威胁分析时就是用的这种简单评价方式，评价简洁实施容易，但由于评价标准单一，对于有争议的威胁就可能出现大家对危险等级的评级意见不统一。

DREAD威胁评级模型

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

潜在损失(Damage Potential) 如果缺陷被利用，损失有多大？

重现性(Reproducibility) 重复产生攻击的难度有多大？

可利用性(Exploitability) 发起攻击的难度有多大？

受影响的用户(Affected users) 用粗略的百分数表示，有多少用户受到影响？

可发现性(Discoverability) 缺陷容易发现吗？

等级高中低

潜在的损失

D

获取完全验证权限，执行管理员操作，非法上传文件泄露敏感信息泄露其他信息

重现性

R

攻击者可以随意再次攻击攻击者可以重复攻击，但有时间限制攻击者很难重复攻击过程

可利用性

E

初学者短期能掌握攻击方法熟练的攻击者才能完成这次攻击漏洞利用条件非常苛刻

受影响用户

A

所有用户，默认配置，关键用户部分用户，非默认配置极少数用户，匿名用户

可发现性

D

漏洞很显眼，攻击条件很容易获得在私有区域，部分人能看到，需要深入挖掘漏洞发现漏洞极其困难

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

所以这个漏洞在“潜在的损失”（Damage

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

威胁建模中的一些实际问题

通过上面的介绍我们已经能感受到威胁建模的作用和好处，但在开展威胁建模时，也会面临一些实实在在的问题。

威胁建模的开展不易

进行威胁建模会增加很大的成本，为了消减某项潜在的威胁，开发人员需要在原有功能的代码上增加更多的业务功能以外的代码来提高安全性，增加的这个开放量有时甚至会接近某项功能本身的代码量。增大了成本投入，而另一方面对于现在绝大部分产品来说，安全性的增强对于用户来说是不敏感的，用户需要的是功能，不出安全问题是理所应当的，安全性很难作为卖点。不仅如此，往往安全性的提升还会带来用户体验的下降，比如前面提到的12306订票网站的奇葩验证码就是一个典型例子，又比如对密码复杂度的要求、连续密码输错锁定帐号一段时间等等这些安全措施都会降低用户体验。

所以威胁建模的开展不易，小公司、创业公司很难投入这个成本去做这件事情，通常都是一些大型公司或是对安全性特别敏感的企业才有条件去做这个事情，因为对于这些公司一旦发生安全事件会对其带来非常大的损失和负面影响，例如2014年携程网爆出漏洞，可导致用户的信用卡信息泄露，受此事件影响，携程股价一度暴跌近10%。

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

做威胁建模的人员都是安全专业的人，而不是对应业务的开发人员，对业务系统并不了解，所以在每次做威胁建模的时候，安全人员首先都要和对应业务的开发人员进行深入的沟通，而且这个沟通在威胁建模进行过程中还会反复进行，因为安全人员只有充分了解了具体的业务场景，才可能发现其中的潜在威胁。

但实际情况是沟通常常不充分，一方面因为开发人员对他正在开发的这个系统已经非常熟悉，一些他认为不重要或者很简单的东西直接就省略不提，但这个系统对于安全人员来说可能是第一次接触，这样导致一些细节安全人员就没有了解清楚，一些潜在威胁有可能就藏在这些细节里面。

另一方面，安全人员和开发人员从某种程度来说是对立的，因为最终发现的威胁都会提交给开发者去修复，开发者对安全的认识不一定深刻，对一些威胁他可能认为并不重要，但为了消减这个威胁，比如本来100行代码就能完成的功能，需要增加到几百行代码或者是破坏了他代码原本的结构，开放人员往往是不乐意的。所以在业务沟通时，甚至可能故意隐瞒一些细节。

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

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

结语

本文以STRIDE威胁建模为基础，介绍了一些相关的理论概念，其主要来源于以前做过的STRIDE威胁建模工作的经验，整理了其中我认为最重要的部分，分享给大家。除这些理论以外，本文更多的篇幅是结合自己以往从事过攻击和防御的工作经验，分享了一些真实的案例以及个人对攻防的理解和思考。如果想更深入的了解和学习威胁建模，可以阅读SDL相关的书籍。

声明：本文来自360安全监测与响应中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。