![威胁建模浅谈 威胁建模浅谈]()
本文章属于bilisrc新开辟的技术文章栏目,输出b站安全小伙伴们的一点思考。欢迎感兴趣的小伙伴与我们多多交流(可通过公众号后台留言)。
引言:威胁建模是一种用于识别、量化和降低应用程序安全风险的结构性方法,作为SDL的核心模块被用于实践中。作为威胁建模系列的第一篇文章,本文将介绍关于威胁建模的基本概念、在何时做威胁建模、以及如何做威胁建模几个问题。
信息安全三要素CIA:Confidentiality (机密性), Integrity (完整性), 和 Availability (可用性)。
l 机密性:确保在数据处理的每一个交叉点上都实施了必要级别的安全保护并阻止未经授权的信息披露。
l 完整性:保证信息和系统的准确性和可靠性,并禁止对数据的非授权更改。
l 可用性:确保授权的用户能够对数据和资源进行及时和可靠的访问。
资产(Assets)、风险(Risk),威胁(Threats),脆弱性(Vulnerabilities),暴露(Exposure)。
要确定信息三要素面临哪些威胁,就需要先知道风险由什么构成。它们之间的关系,可以用下面的例子解释:
公司的资产(Assets)会受到各种威胁(Threats)影响,这些威胁可能是黑客等人为因素,也可能是火灾地震等自然因素。威胁通过利用系统的脆弱性(Vulnerabilities)可导致暴露(Exposure),这就是风险(Risk)。对策是使用防护措施(Safeguards),缓解风险使资产得到安全保障。
威胁建模是一种分析应用程序安全性的结构化方法,可以用来识别、量化和降低应用程序安全风险。威胁建模由微软2000年左右提出,作为SDL的核心模块且可实践的应用安全设计分析方法,主要管理流程包含如下:
![威胁建模浅谈 威胁建模浅谈]()
威胁建模管理流程
在软件开发生命周期(SDLC)中,设计阶段是对需求分析结果进行软件系统整体设计的重要阶段。相比在系统完成开发后再考虑安全需求,提前在设计阶段就完成整体安全方案设计,不管对开发人员还是安全人员,都有更大的弹性空间提前消除安全威胁,避免类似事后打补丁式地被动防御,同时也有助于降低开发和后期维护的成本。通过安全设计消除潜在的威胁,并在测试环节进行安全测试验证,形成一个设计-实现-验证闭环。绝大部分安全威胁,可以通过威胁建模来发现。
当前使用较多的是微软的STRIDE威胁建模方法。为了便于安全人员快速便捷的进行威胁建模,微软开发了基于STRIDE威胁建模方法的SDL Threat Modeling Tool[2]威胁建模工具,该工具可以帮助安全人员画数据流图、分析威胁、生成并导出威胁建模报告。
STRIDE威胁建模将威胁类型分为Spoofing(仿冒)、Tampering(篡改)、Repudiation(抵赖)、Information Disclosure(信息泄漏)、Denial of Service(拒绝服务)和 Elevation of Privilege(权限提升),共6个维度,几乎可以涵盖目前绝大部分安全问题。
STRIDE 与CIA的关系
STRIDE威胁建模流程
STRIDE建模的第一步就是分解业务场景,绘制数据流图(DFD)。威胁建模针对的是一个个具体场景,所以首先需要对我们的系统根据实际情况进行业务场景的分解,比如登录场景、交易场景、审批场景、灾备场景等等,具体是什么场景以及有多少个场景,是和实际的系统和业务息息相关的。分解完业务场景以后,就对一个一个的场景分别进行STRIDE威胁建模,每个场景的STRIDE威胁建模是相对独立的。
首先对一个具体的场景绘制数据流图(DFD),一个简单Web应用的数据流图如下所示:
![威胁建模浅谈 威胁建模浅谈]()
数据流图包括四个核心元素:外部实体、数据流、处理过程及数据存储。
l 外部实体,可以是浏览器、移动设备、人、进程等实体。
l 数据存储,除了数据库也可以是文件、注册表、共享存储、缓存等。
另外还会添加可信边界,即与数据流相交的信任边界。常用的信任边界有哪些?
I.网络边界:常用的有Internet、办公网、开发测试网、生产网,或安全生产网(Security Zone)。
II.应用、服务边界:不论是微服务还是单体架构,服务往往会形成自己的集群,服务内部相当于一个可信区,内部组件可以自由访问。
III.主机边界:主机通常是服务的载体,也是服务实现的原子单位。
V.租户、项目逻辑边界:对于SaaS层服务,用户资源是共享在一个公用的集群,并没有明显的物理边界,实际的边界是通过基于认证和权限的访问控制隔离的。
STRIDE威胁建模方法已经明确了每个数据流图元素具有不同的威胁,其中外部实体只有仿冒(S)、抵赖(R)威胁,数据流只有篡改(T)、信息泄露(I)、拒绝服务(D)威胁,处理过程有所有六种(STRIDE)威胁,存储过程有篡改(T)、信息泄露(I)、拒绝服务(D)威胁,但如果是日志类型存储则还有抵赖(R)威胁。具体可以对照如下表格进行威胁识别:
根据不同的数据流图元素及威胁,相应的缓解措施也不相同。下表就威胁类别给出一些通用性缓解方案:
![威胁建模浅谈 威胁建模浅谈]()
分析完数据流图中的所有对象的潜在威胁以后,就要输出一个威胁列表,威胁列表中的每个威胁项形如下面这样的表格:
![威胁建模浅谈 威胁建模浅谈]()
威胁列表
其中威胁评级可以采用DREAD威胁评级模型进行评估。
DREAD威胁评级模型
在威胁建模完成后,需要对整个过程进行回顾,不仅要确认缓解措施是否能够真正缓解潜在威胁,同时验证数据流图是否符合设计,代码实现是否符合预期设计,所有的威胁是否都有相应的缓解措施。最后将威胁建模报告留存档案,作为后续迭代开发、增量开发时威胁建模的参考依据。
bower,bilibili高级安全工程师,现负责b站DevSecOps流程实施、SRC响应及安全测试。
![威胁建模浅谈 威胁建模浅谈]()
本文始发于微信公众号(哔哩哔哩安全应急响应中心):威胁建模浅谈
免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉。
点赞
https://cn-sec.com/archives/198514.html
复制链接
复制链接
-
左青龙
- 微信扫一扫
-
-
右白虎
- 微信扫一扫
-
评论