0x00 前言

1、什么是威胁建模：
以结构化的方式思考、记录并讨论系统存在的安全威胁，并针对这些威胁制定相应的消减措施。

2、为什么要威胁建模：
（1）在设计阶段开展威胁建模，一方面可以更全面的发现系统存在的威胁，根据发现的威胁提出相应的安全需求，来最大限度保证系统的安全；另一方面也可以降低安全设计缺陷导致的修复成本。
（2）通过威胁建模生成的记录文档，为后期开展的代码审计、渗透测试等安全活动提供支持，可极大提升漏洞挖掘的效率。

3、如何实施威胁建模：
（1）绘制数据流图（基于业务现有文档中的系统架构图等，来绘制数据流图）
（2）发现威胁（通过结合STRIDE、攻击树、攻击库等方法来分析发现威胁）
（3）处理和管理威胁（可使用风险管理的经典策略：解决、缓解、转移、接受）
（4）验证威胁是否解决。

4、数据流模型是威胁建模最理想的模型，因为安全问题经常出现在数据流中，而不是在控制流中。数据流图的应用非常广泛，有时会被称为“ 威胁建模图” 。1967 年由Larry Const ant ine 设计，数据流图(DFD)包括数据存储和处理过程2个关键要素，通过数据流连接起来，并与外部实体相互作用。没有完全准确的数据流图，我们只是要让他尽量有用而已。本篇文章我将重点分享一下如何绘制一个对我们有用的数据流图。如果大家有更好的意见，希望不吝赐教。

0x01 数据流图5个元素

元素	图形表示	含义
外部实体	矩形	驱动系统业务，但不受系统控制的人和物。如用户、第三方系统等
处理进程	圆形或圆角矩形	表示一个任务、一个执行过程。如微服务、可执行文件、Web Server 、ftp server等
数据存储	两条平行线	存储数据的内部实体。如对象存储、数据库、消息队列、文件、注册表等
数据流	带箭头的直/曲线	数据在系统中的流动方向。如http请求、gRPC请求、服务调用、网络通信等。
信任边界	虚线	可信元素和不可信元素之前的边界

在这里插入图片描述

0x02 常见架构图设计模型

一般我们实施威胁建模时，是在应用系统的设计阶段，这个时候安全工程师已经有了系统的设计文档作为参考，但是由于一般情况下，公司不会对架构师绘制系统架构图的模型进行统一要求，因此我们拿到的设计文档中会出现各式各样的图形，为了能够读懂这些图，我们就需要掌握一些常见的架构图设计的模型，掌握这些模型以后，我们就可以游刃有余的应对大部分的架构设计图了。所以本节介绍2种常见的架构图设计模型，分别是软件架构4+1视图和C4模型。

注：本节出现的所有图形都是从网络上粘贴过来的，主要是方便大家理解。

2.1 软件架构4+1视图

使用5种架构视图，从不同角度表示一个软件系统的不同特征，组合到一起作为架构蓝图描述系统架构。
1、逻辑视图（也叫结构视图、功能视图）：从结构化视角，描述系统提供的功能服务是如何构建的，明确每个模块的功能是什么。所以在逻辑视图中，系统会被分解成一系列的功能抽象。
springcloud微服务的逻辑视图
2、运行视图（也叫处理视图、进程视图），用于描述系统软件组件之间的通信时序，数据的输入输出。在UML中通常由时序图和流程图表示。
微服务架构安全认证处理视图
3、开发视图（也叫实现视图）：描述实现系统功能的各个组件和模块是如何实现的。
设备调试系统架构的开发视图
4、物理视图（也叫部署视图）：描述系统可以部署在那些物理环境上（服务器、PC端、移动端等）和软件环境（虚拟机、容器、进程等），在UML中通常由部署图表示。
在这里插入图片描述
5、用例视图（也叫场景视图），即4+1中的1。从前面的图可以看到，4+1中的4个视图都是围绕着场景视图为核心的。它用于描述系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计。在UML中通常由用例图表示：
在这里插入图片描述

2.2 C4模型

通过四个模型，从不同的层次（抽象到具体），来描述系统的架构设计。
四个模型分别是COTEXT、CONTAINER、COMPONENT、CODE，因此叫C4模型。
1、COTEXT上下文：高度抽象的系统层面，所表达的是系统和用户以及它所依赖的其他系统之间的关系。
在这里插入图片描述
2、CONTAINER：系统是由容器组成的，这个容器是一个抽象的概念，代指有自己独立进程空间，可独立部署的一种存在。

3、COMPONENT: 容器是由组件组成的，组件在这里把接口和它的实现类打包成一个概念，组件是映射到代码库中的真实抽象
在这里插入图片描述
4、CODE: 代码层面的设计，也就是类图等UML制图。一般是不画的，都是代码生成出来。

2.3 总结

上面简单介绍了2种架构图设计模型，如果大家感兴趣可以再去深入研究，这里就不多说了。可以看到上面2个模型都有一个共同点，都是分别从不同的视角或者细粒度来绘制系统架构图，那么我们在绘制数据流图时，需要使用哪个视角呢？需要细化到什么粒度呢？理想情况下当然是系统描述的越具体越好，粒度越细越好，这样有助于我们发现更多的威胁，但实际情况是，如果我们一直纠结于系统的运行细节，我们将会耗费大量时间在绘制数据流图上，且对于初学者而言，容易局限在绘制数据流图的步骤，这个显然得不偿失。

因此从初学者角度看，选择合适的抽象层级来绘制数据流图还是挺重要的，从笔者目前总结的经验来看，当使用4+1视图绘制数据流图时，选择逻辑视图，当使用C4模型时，选择CONTAINER层级，也就是具体到进程级别，这样绘制出的数据流图会相对合理些，当遇到一些重要或者复杂的进程时，只需要单独再放大一下该进程就可以了。

0x03 工具调研

3.1 Microsoft Threat Modeling Tool

微软的威胁建模工具：https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool
1、优点：
（1）画图体验很好，毕竟是微软的产品
（2）可根据已有的威胁模型模版和绘制的数据流图，自动生成威胁列表
在这里插入图片描述
2、缺点：
（1）默认只有2个威胁模型模版，需要我们自己制作适合自己应用场景的威胁模型模版。
https://github.com/microsoft/threat-modeling-templates
（2）只能在win系统使用，很难在mac系统使用。

3.2 OWASP Threat Dragon

OWASP提供的威胁建模工具：https://github.com/OWASP/threat-dragon/releases
1、优点：
（1）支持win、mac、linux等操作系统
在这里插入图片描述
2、缺点：
（1）相较Microsoft Threat Modeling Tool，画图体验较差
（2）只能导出pdf版的威胁建模结果
（3）威胁描述和消减措施每次都需要手动编写

3.3 drawio

这就是一个类似visio的开源的画图工具，支持win、mac、linux等操作系统，没有记录威胁的能力。
https://github.com/jgraph/drawio-desktop
我们可以使用drawio或者visio等画图工具绘制数据流图，然后在表格中记录威胁。

3.4 总结

经过前面的描述，可以看到每个工具都有自己的不足，我们在实施时可以选择如下2个方案：
1、自动化程度更高的方案：
（1）使用Microsoft Threat Modeling Tool工具，前期需要花费时间制作威胁模型模版。
（2）根据实际情况，人工核验自动生成的威胁列表，并对其进行增删改操作。
2、全部手动操作的方案：
（1）使用drawio、visio等画图软件来绘制数据流图，然后基于数据流图在表格中记录威胁。

0x04 案例分析

本节我找了一些安全团队开源出来的威胁建模的模型，来帮助初学者更好的理解如何绘制数据流图。

4.1 k8s威胁建模

CNCF对k8s的威胁建模：
https://github.com/cncf/financial-user-group/tree/main/projects/k8s-threat-model
1、k8s架构图
首先我们看下k8s官网给出的k8s的架构图：
在这里插入图片描述
从C4模型来看，该架构图具体到了CONTAINER层级，但是对于k8s集群的核心服务api server，其进行了放大，体现出了服务内的部分关键组件。
2、下面我们看下CNCF绘制的k8s集群的数据流图：

可以看到，该图同样是具体到了CONTAINER层级。另外，我们可以看到k8s的每一个组件都有一个自己的信任边界，这是因为虽然k8s的每个组件之间的通信默认都使用了X509证书认证的方式，但是由于每个组件还拥有其他的认证方式，甚至可以未授权访问，因此在定义信任边界时，一定是以最坏的情况为主，这样才有利于我们后续发现更多的威胁，提出更多有效的消减措施。由于本篇文章主要讲的是如何绘制数据流图，如果对k8s威胁建模的分析结果感兴趣的同学，可以自行去github上查看。

0x05 总结

1、从个人角度而言，绘制数据流图的前提条件是要熟悉各种架构设计模型，在此基础上，通过不断练习，不断熟悉，从而逐渐提升个人画图的效率。
2、从威胁建模的小组而言，理想情况下，数据流图需要安全人员和产线人员共同来绘制，如果受限于环境无法共同绘制时，一定要保证最终的数据流图得到双方一致认可，双方需要对整个系统的运行情况的认知达成一致，在此基础上，才能开展后续的识别威胁的工作。