关于安全:计算机网络安全威胁建模-IDCF

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

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

随着方法论的成熟，很多帮助开发设计人员做威逼建模的工具也越来越多。因为开发模式的一直演进，这个曾在软件架构师和设计者的技能，越来越向开发者转移。心愿能在帮组大家进步平安设计技能的同时，能更早的将平安流动退出到软件开发周期中。

因为威逼建模波及内容宽泛，为了更高效的分享，在此分享的内容绝对精简。抉择了一些简略易懂的模型和办法。在文章最初会举荐一些材料，如果大家对威逼建模有着浓重的趣味能够进行参考。本章节的内容会依照如下的题目开展介绍：

• 为什么要做威逼建模
• 威逼建模的步骤
• 威逼建模的办法
• 威逼建模的工具
• 威逼建模在麻利中的利用

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

以上举的是一些比拟典型的例子。依据不同的场景可能呈现不同的威逼。而威逼建模是基于开发的软件进行剖析和定位，以达到避免某种特定的威逼起源对公司或集体造成的负面影响。将危险和老本管制在能够承受的范畴之内。通过威逼建模的形式，提前的定位到开发中要解决的破绽或者问题。

威逼建模的步骤

首先威逼建模产生的工夫点比拟重要，如果零碎的设计还没有开始或者零碎间的交互还没有定义，这个时候做威逼建模没有足够的信息来撑持，所以失去的后果也不会现实。如果是一个新的我的项目，那么最好要在 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 打造软件交付质量保证的闭环》