计算机网络安全：威胁建模 | IDCF

上一篇文章详细介绍了在软件开发生命周期中的计算机网络安全活动，(计算机网络安全：软件开发周期中的活动 | IDCF)，并简单列举了每个活动的内容和作用。本文内容会针对上文提及的一些计算机网络安全活动进行详解。由于安全需求评估和履行涉及面较广，而且不同领域的内容也有所不同。为了更加专注于DevSecOps这个话题，我们将从另外一个活动开始介绍。

本文专注于威胁建模 (Threat Modeling) 这个在软件交付的设计阶段的计算机网络安全活动。威胁建模起源于1960年代，一群为了个人利益发掘安全漏洞的人。1977年，基于IT的威胁建模方法论被Christopher发表，当时的建模是基于架构模式的概念进行的。随着IT的发展威胁建模的方法，例如：攻击树(Attack Tree)，STRIDE，OCTAVE等被逐渐建立。

随着方法论的成熟，很多协助开发设计人员做威胁建模的工具也越来越多。由于开发模式的不断演进，这个曾在软件架构师和设计者的技能，越来越向开发者转移。希望能在帮组大家提高安全设计技能的同时，能更早的将安全活动加入到软件开发周期中。

由于威胁建模涉及内容广泛，为了更高效的分享，在此分享的内容相对精简。选择了一些简单易懂的模型和方法。在文章最后会推荐一些资料，如果大家对威胁建模有着浓厚的兴趣可以进行参考。本章节的内容会按照如下的标题展开介绍：

• 为什么要做威胁建模
• 威胁建模的步骤
• 威胁建模的方法
• 威胁建模的工具
• 威胁建模在敏捷中的应用

了解为什么要做威胁建模，读者首先要了解的是软件开发中存在着哪些威胁，这些威胁会造成什么样的影响。首先让我们了解一下从以下几个威胁来源。

威胁来源	详细介绍
脚本小子	这种往往没有任何明确目的，单纯好奇驱使的个体。使用网络上可以公开下载的恶意脚本软件，对某个网站或者资源进行试探性攻击。可能本身没有安全的专业技能，抱着实验性质进行测试，非意向性的造成破坏。
内部威胁	目的可疑的，或由于疏忽，不熟练对内部组织造成机密文件泄露，盗取。对公司利益和声誉造成损害。例如：在论坛上发表或纰漏非批准的信息导致客户抱怨甚至与公司终止合同。利用一些网络安全的手段，窃取公司机密信息并勾结竞争对手进行倒卖以从中获利。
犯罪组织	有组织有纪律，专业的黑客。往往是被某个组织雇佣以达到某种盈利目的。例如：勒索软件，对操作系统或者网络存储的硬盘进行加密，勒索受害者支付电子钞票 (Bitcoin) 以换取解密文件。
高级持续威胁	这种比较针对一些特定的行业，业界间谍，政治操纵，专利盗取等。可能普遍存在与国家之间，在这里就不深入探讨了。在商战中也比较常见，为谋取利益的某种竞争手段。
激进黑客	激进黑客们的目的往往是为了吸引群众对某些问题的关注，恶意的暴露一些信息引起媒体的关注。

以上举的是一些比较典型的例子。根据不同的场景可能出现不同的威胁。而威胁建模是基于开发的软件进行分析和定位，以达到防止某种特定的威胁来源对公司或个人造成的负面影响。将风险和成本控制在可以接受的范围之内。通过威胁建模的方式，提前的定位到开发中要解决的漏洞或者问题。

威胁建模的步骤

首先威胁建模发生的时间点比较重要，如果系统的设计还没有开始或者系统间的交互还没有定义，这个时候做威胁建模没有足够的信息来支撑，所以得到的结果也不会理想。如果是一个新的项目，那么最好要在MVP的范围定义清晰，系统结构设计结束的时候做威胁建模。如果是对一个已存在的系统做升级或者变更，建议在变更需求明确后，比如sprint计划会议之后进行威胁建模。找到正确的时间点后，就可以按照一下的步骤来进行威胁建模了。

以下几个步骤可以分开进行也可以在同一个工作坊里进行，这取决于可分配给威胁建模的时间，或者要定位系统的复杂度等。在做威胁建模之前，最好做一些准备工作，充足的准备会让工作坊更有效的进行。比如，定义该软件的威胁来源，威胁建模的范围，信任边界的定义等。另外安全风险的范围有时候也取决部署和运行的环境，国家的隐私法律条款和数据的机密性等因素。必要的话可以在工作坊中邀请相关的专家参与进来，避免信息不清晰导致的困惑。

威胁建模的方法

每个建模的方法都有着独特的优势，取决于我们在建造什么，使用什么样的粒度。选择最适合的方式，会让建模更加顺利。充分的准备，了解使用场景，建模的范围，连接方式，网络和信任边界，针对软件特点的威胁来源。这些必要的准备工作，可以让威胁建模事半功倍。在信息不清晰的情况下进行建模可能会是竹篮打水一场空(Garbage-in, Garbage-out)。所以我们在这里特别强调准备工作的重要性，希望大家能更高效的进行威胁建模。接下来我们将威胁建模的方法分成几段来阐述。

• STRIDE 是一种威胁模型，由微软的两位安全专家建立的。其中包含以下6种分类。STRIDE是这些分类的首字母的缩写，有助于记忆这个模型。在这种模式下，将系统架构通过数据流程图表示出来，然后对每一次数据交互，数据存储和流程进行STRIDE建模分析。可以很有效的将设计中没有考虑的安全控制找出来。

• 攻击树（Attack Tree）这种方式可以针对特定要保护的资产进行攻击模式的分析，模拟黑客的思维方式，为了达到某种目的或者造成某种影响，可以通过什么样的途径来进行。这样可以更好的检测安全控制的深度和广度。这种方式进行威胁建模往往需要对攻击的方式方法有深刻的认识。而且需要注意的是，清晰的定位根部节点非常重要
• 攻击库（Libraries）亦或攻击模式，利用好这种方式可以非常有效的定位系统中的威胁，前提是攻击库中描述的场景和软件开发的目的一致。

个别组织可以针对场景定位攻击模式，但往往需要比较长时间的验证和检查。在这种模式下，取决于开发团队对场景熟悉程度，这种威胁建模更细化和明确。比较常见的是利用现有的攻击库，CAPEC整理了500多种攻击模式，MITRE ATT&CK也有非常成熟的库可以应用。

• 检查清单（Checklist）这是最简单的一种建模方式，开发人员根据安全专家制定的威胁清单上的内容逐一进行检查，确认在其软件场景中的适用性。这种方式比较适合从来没有做过威胁建模的团队，在没有安全专家参与的情况下独立完成建模。不同于之前威胁建模的方法，这种方式会局限于清单上的内容。

以上介绍都是针对甄别威胁的方法进行介绍的，那么我们通过建模活动生成的威胁列表之后，还需要对威胁的风险进行排序或者增加安全控制的功能来减轻风险。微软的威胁建模文档里面有对减轻风险这一块儿做介绍，因为这种方式比较典型，也容易上手，首先就是针对威胁发生的可能性进行分析，这里的可能性就是攻击者利用这个威胁的难度，花费的时间和支配的资金等等。

另外就是对威胁造成的影响进行分析，也就是说威胁发生后对公司或者客户造成什么样的影响和损失。最终通过这两个维度判断风险的等级来排序。当然还有其他的风险分析的模型和工具，例如DREAD等，这些模型的选择往往与公司的安全人员的技能，安全成熟度和重要度挂钩。

威胁建模的工具

在这里的工具是可以对威胁建模起到辅助作用的图形工具或者可以根据绘制的数据流程图生成相应的威胁。但工具往往不能清晰的定位到软件特定的场景，导致生成的威胁列表过多，有很多假阳性的威胁，需要花时间进行进一步的筛选。在这里推荐微软开源的威胁建模工具，但这个工具只能在Windows操纵系统下安装使用。

另外OWASP社区开发的threat Dragon可以在多个操纵系统下使用。推荐的这两种工具都是辅助建模人员勾画数据流程图，信任边界来设定威胁场景。还有一些非开源的工具不在这里一一介绍了。大家可以在网上找到适合自己组织的工具，在工具的选择上要注意兼容性，灵活性和假阳性的概率等问题，找到一个得心应手的工具可以让威胁建模变得更有效。

最后威胁建模在敏捷中的应用，是大家比较关注的问题。总结起来主要有两类担忧：

• 敏捷宣言讲的是沟通胜于文档，威胁建模的是文档化的一个过程。
• 威胁建模更适用于瀑布模式，在有特定的设计阶段的情况下进行。

那么接下来我来帮助大家分析一下这两类担忧，并给出一些在敏捷中应用的场景。

• 第一类担忧是指的文档化这个问题，其实通过介绍大家应该了解威胁建模是个多人活动，在建模过程中生成的文档是由一组人员讨论而来的。这正是敏捷中所强调的通过沟通和讨论，在敏捷的团队里面的威胁建模应该有更多的团队成员加入到讨论里面。最终的文档应该是通过讨论后的一个结论性文档，在后续的开发测试中起着引导的作用。
• 第二类担忧是指在高速，频繁的迭代里面如何将威胁建模这种活动加进去，这与迭代中的设计活动类似，取决于安全设计在此迭代中的重要性和敏捷的运行模式。例如在第0个迭代，项目初期的准备过程中要做的是定义项目的范围的MVP（最小可行产品）和该产品的设计，这是一个非常适合做威胁建模的阶段。但其实在迭代运行的过程中也可能遇到产品设计的变化，这个时候就需要准确定位到设计中的变化，对于变化的部分进行威胁建模。常见的做法是通过检查清单来确定是否需要在该迭代做威胁建模，如果需要就要在迭代中的待办事项中记录，并且衔接在迭代计划的活动之后进行。JIRA有插件可以实现通过检查清单方式建立待办事项的功能，将这个功能很好的利用可以协助团队制定一些规则，避免漏掉迭代中应该做的活动。

希望大家能通过这篇文章对威胁建模有初步的认识，也欢迎大家与公众号互动，多多探讨敏捷和DevOps中安全活动的应用。给出一些反馈，共同成长。谢谢。

参考文献：

• The STRIDE Threat Model
  https://docs.microsoft.com/en...
• Book
  Threat Modeling: Design for Security by Adam Shostack
• CAPEC
  https://capec.mitre.org/data/...
• MITRE ATT&CK
  https://attack.mitre.org/
• 微软威胁建模
  https://www.microsoft.com/en-...
• OWASP Threat Dragon
  https://owasp.org/www-project...

来源：DevSecOps SIG
作者：Nick Yu
声明：文章获得作者授权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术同伴，如原作者有其他考虑请联系小编删除，致谢。

7月每周四晚8点，【冬哥有话说】研发效能工具专场，公众号留言“效能”可获取地址

• 7月8日，LEANSOFT-周文洋《微软DevOps工具链的 "爱恨情仇"（Azure DevOps）》
• 7月15日，阿里云智能高级产品专家-陈逊《复杂型研发协作模式下的效能提升实践》
• 7月22日，极狐(GitLab)解决⽅案架构师-张扬分享《基础设施即代码的⾃动化测试探索》
• 7月29日，字节跳动产品经理-胡贤彬分享《自动化测试，如何做到「攻防兼备」？》
• 8月5日，声网 AgoraCICD System负责人-王志分享《从0到1打造软件交付质量保证的闭环》