威胁建模 -读书笔记
0x00 《威胁建模-设计和交付更安全的软件》(THREAT MODELING-Designing for Security)
《黑衣人》台词: “生活本来就充满痛苦,殿下。 不这么对您说的人一定是在推销什么。”
0x01 潜心开始威胁建模
威胁建模的关键是回答以下四个问题
- 问题1:你正在构建什么?
- 问题2:哪些地方可能出错?
- 问题3:发现错误时应该这么解决?
- 问题4:是否做了完整的分析?
问题1:你正在构建什么?
先把要做威胁建模的示意图,结构图,数据流图画出来
注意 信任边界 <—-> 攻击面
问题2: 哪些地方可能出错?
要回答这个问题,引用”0x05 攻击库” “细节 VS 抽象”章节
在一个DFD图中,我们可以通过STRIDE –> OWASP TOP10 –> CAPEC –> Checklist –> Test Case 来识别可能出错的地方,威胁也好,漏洞也好,关键是找到可能出错的地方
这些方法比如STRIDE、OWASP TOP10、CAPEC抽象等级是不一样的,选取什么方法取决于受众,当然你可以同时使用所有方法.而每个方法覆盖的范围是不一样的,最理想的情况是使用人根据不同场景使用适当的方法,以达到最佳效果
通过系统化,结构化方式分析
STRIDE模型可供参考,Spoofing,Tampering,Repudiation,Information Disclosure, Denial of Service, Elevation of Privilege
(仿冒/假冒, 篡改, 否认/抵赖, 信息泄露, 拒绝服务, 权限提升)
识别威胁窍门
1、从外部实体开始
2、不要因为不是你目前要找的威胁而忽略任何一个威胁。威胁可能有冗余,但是为了避免遗漏,都应该记录下来。STRIDE是引导你发现威胁的工具,不是让你给你所发现的威胁进行分类。
3、关注可能的威胁。 不要在风险不大的威胁上投入太多时间
问题3: 发现错误时应该这么解决?
解决威胁的方法有如下几种
1、减缓威胁
2、清楚威胁
3、转移威胁
4、接受威胁
Spoofing <—-> Authentication
Tampering <—-> Integrity
Repudiation <—-> Audit
Information Disclosure <—-> Confidentiality
Denial of Service <—-> Availability
Elevation of Privilege <—-> Authorization
问题4: 是否做了完整的分析?
检测威胁建模模型
检测示意图
检测每个威胁
检测针对威胁的测试
针对某个产品做威胁建模,本质上是完成两个模型的交叉
一个是产品本身的数据流模型
一个是STRIDE威胁建模模型
0x02 威胁建模策略
以资产为核心
以攻击者为核心
以软件为核心
很多情况下,集中讨论资产 和 以攻击者为中心的 威胁建模 都也不是最佳的
建议使用以软件为核心的威胁建模
图表是软件建模的最佳方法
包括数据流图(DFD),UML,泳道图,状态图
数据流图的核心要素
- 1、进程(用圆角矩形表示)
- 2、数据流(用箭头表示)
- 3、数据存储(用两条平行线和中间的标签表示)
- 4、外部实体(用直角矩形表示)
- 5、信任边界(用虚线框表示)
0x03 STRIDE方法
STRIDE-PER-ELEMENT方法在规范性方面很有优势,它帮助你确定该寻找什么威胁,而不是检查表的形式:xss, xsrf, sql injection …
// 每个元素都是受害主体,不是攻击主体。 e.g. 如果你篡改了一个数据存储,威胁是针对数据存储及其本身数据的
for modules in DFD: #DFD = [[Ext Entity], [Process], [Data Flow], [Data Storage]
for module in modules:
for threat in STRIDE:
if module.threat == True:
record to threat list
STRIDE-PER-INTERACTION是识别威胁的最简化方法。威胁不会凭空出现,它们是在与系统交互的过程中出现的。
该方法可以通过考虑数据元组(源,目的,交互)来枚举威胁。
S | T | R | I | D | E | |
---|---|---|---|---|---|---|
外部实体 | x | x | ||||
进程 | x | x | x | x | x | x |
数据流 | x | x | x | |||
数据存储 | x | ? | x | x |
0x04 攻击树
将对系统的攻击放置到树的结构中进行展现,要达到的目标表示成根结点,要达成这一目标采用的各种方法表示成叶结点。 攻击树可以作为STRIDE的替代方法来寻找威胁。
创建新的攻击树
- 1、确定表示方法 (与树 / 或树; 建议用或树)
- 2、创建根结点
(根结点为:组件, 子结点为:根结点可能出错的地方)
(根结点为:攻击者的目标, 子结点为:达成根结点目标的方法; 建议用此方法创建根结点) - 3、创建子结点
攻击一个系统
- 物理访问
- 破坏软件
- 颠覆一个人
攻击一个系统可以通过
- 人员
- 工程
- 技术
攻击一个产品,可以在
- 设计阶段
- 生产阶段
- 发布阶段
- 使用阶段
- 遗弃阶段
- 物理访问
- 4、考虑完整性 (可以通过攻击模式库方法 以及 STRIDE方法来辅助检查攻击树质量)
- 5、修剪树 (检查攻击树的每个结点,并考虑每个子结点的行动是被阻止的还是重复的. 如果一个结点是被阻止的,那么可以把对应的结点标注为阻止,表示它们无须被分析)
- 6、检查攻击树表示 (建议使用图形化表示攻击树 每个攻击树都应该控制在一页纸内,如果攻击树内容太多,可以分割成多个子树,在不同页面展示。)
0x05 攻击库
攻击库属性
- 受众
- 受众不同,攻击库的内容和结构都会不同
- 细节 VS 抽象
- 从抽象到具体依次是:STRIDE –> OWASP TOP10 –> CAPEC –> Checklist –> Test Case
- 方法越具体,操作人员的主观能动性就越差,对操作人的能力要求也越低
- CAPEC是对常见威胁的分类整理,而STRIDE是一组安全属性(说CIA AAA是安全属性是不是更合适)
- 对于很多威胁建模者来说,CAPEC可能比STRIDE更受欢迎
- 对于每一种方法,都可以适用“0x03 STRIDE方法”
- 范围
- 攻击库越抽象,覆盖的范围就越广,但是就越依赖使用该攻击库的人的经验和能力
通过提供各个模式的细节攻击清单,攻击库或许对就攻击者如何工作了解不是很深入的人来说,是有帮助的。
在提供诸多细节攻击清单与枯燥寻找威胁之间找到普遍有用的威胁点是有挑战性的。
同样具有挑战的是,要是提供特别详尽的细节会让读者误以为检测列表就是全面的了,所以要注意平衡。
实施文献检索和在攻击库中获取细节,是很好的提高安全知识的方法
威胁也是有抽象等级的,比如 CEO的电脑存在信息泄露威胁,这是很抽象的描述,也可以具体到,一名警卫可能会在CEO的电脑上插入键盘记录工具
0x06 隐私工具
如同安全威胁侵犯了必要的安全属性,隐私威胁是侵犯必要的隐私属性。
隐私威胁建模的方法有很多,比如 Solove, IETF的“互联网协议的隐私考虑”,隐私影响评估(PIA),Nymity slider,语境完整性,LINDDUN方法等
0x07 处理和管理威胁
7.1 开始威胁建模项目
何时开始威胁建模
- 从项目启动开始
- 检查软件功能
- 临近交付
从哪里开始和在哪结束
- 绘制图表
- 自顶向下发现威胁(广度优先)(从整个系统的最高层开始进行建模)
- 从横跨信任边界开始
- 针对横跨迭代图表元素
- 针对横跨迭代威胁
7.2 深入分析减缓方法
序列 | 威胁 | 减缓 |
---|---|---|
第一序列 | 打破玻璃 | 强化玻璃 |
第二序列 | 打破玻璃 | 警报 |
第三序列 | 剪断警报线 | 心跳线 |
第四序列 | 假的心跳线 | 加密信号完整性 |
攻防是一个迭代,递进的过程,所以不能希望一次就完成所有威胁的减缓
应该是阶梯性的减缓
7.3 利用表格和列表跟踪
7.3.1 追踪威胁
- 按图表元素组织
- 按威胁组织
- 按发现顺序记录威胁
7.3.2 建立假设
假设 | 如果错误它的影响 | 和谁协商 | 谁会跟踪 | 跟踪日期 | 漏洞ID |
---|---|---|---|---|---|
在数据中心内部可以忽略拒绝服务威胁 | 未处理缺陷 | Alice | Bob | 04.15 | 1234 |
一旦建立假设,你需要持续跟踪,你要跟踪以下
- 假设
- 如果假设是错的,跟踪其影响
- 谁能告诉你它是错误的
- 谁会跟踪
- 他们需要何时这么做
- 跟踪的漏洞
7.3.3 外部安全注解
- 给顾客的注解
- 给API调用者的注解
0x08 防御策略及技术
8.1 减缓威胁的策略及技术
8.1.1 认证,减缓欺骗威胁
认证计算机技术
- IPSec
- DNSSEC
- SSH主机密钥
- KPI系统
认证信息技术
- 数字签名
- 散列
认证人的技术
- 你所知道的,如密码
- 你拥有的,如通行卡
- 你所具备的特性,如生物识别
- 你所认识的可以认证你的人
8.1.2 完整性,减缓篡改威胁
保护文件的技术
- ACL或访问权限
- 数字签名
- 散列
- Windows强制访问控制MIC功能
- Unix的不可变信息(immutable bit)
保护网络流量的技术
- SSL
- SSH
- IPSec
- 数字签名
8.1.3 不可否认性,减缓否认威胁
可用于解决否认的技术
- 记录
- 记录分析工具
- 安全记录存储
- 数字签名
- 安全时间戳
- 可信任第三方
- 散列树
- 防范欺诈的工具
8.1.4 机密性,减缓信息暴露威胁
保护文件
- ACL/权限
- 加密
- 适当的密钥管理
保护网络数据
- 加密
- 适当的密钥管理
保护沟通或沟通的事实
- 混合网络
- 洋葱路由技术
- 隐写术
8.1.5 可用性,减缓拒绝服务威胁
保护文件的技术
- ACL
- 过滤
- 配额
- 高可用设计
- 额外带宽
- 云服务
8.1.6 授权,减缓权限提升威胁
提高授权的技术
- ACL
- 群组或角色会员关系
- 基于角色的访问控制
- 基于声明的访问控制
- Windows特权(runas)
- Unix sudo
- chroot,AppArmor或其他Unix沙盒
- MOICE Windows的沙盒模式
- 为明确目的的输入验证
8.2 利用模式解决威胁
模式是表达专家如何捕捉解决重复出现的问题的方法。
8.3 减缓隐私威胁
- 避免收集信息(最小化)
- 多种巧妙方式利用加密
- 分裂密钥系统
- 私人信息恢复
- 差别隐私
- 混合系统及类似混合系统
- 盲态(Blinding)
- 控制数据是如何使用的(遵从性和策略)
0x09 解决威胁时的权衡
9.1 风险管理的经典策略
1 风险等级为何?
2 你想做什么来解决风险?
- 回避风险
- 解决风险
- 接受风险
- 转移风险
- 忽略风险
3 如何实现?
9.2 为风险管理选择减缓措施
9.2.1 改变设计
- 采用减少功能来实现减小攻击面
- 增加安全功能来减小威胁
针对特定威胁的优先级方法
DREAD 威胁等级评估
Damage, Repreducibility, Exploitability, Affected Users, Discoverability
每个方向有1-3三个分数等级,分数越高,威胁越大
一般而言DREAD的评分太主观,可以同时参考CVSS评分,做个权衡
0x10 验证威胁是否已解决
对威胁的测试,跟踪和管理
威胁建模主导的测试和安全测试有交集,这两个测试都是产品测试的子集
一些机构选择使用渗透测试来验证他们的威胁建模或为他们的软件添加一定程度的信心。渗透测试可补充威胁建模,但是有个说法就是‘你不能测试质量’。意思是,你所做的测试从来不会让一个产品变得更伟大完美,只是帮助修复你发现的缺点。要想制造优质产品,你需要从完美的设计开始,拥有好的原材料,良好的生产过程,然后检测输出让其符合你的期待。同样,你无法通过检测让产品变得安全。因此渗透测试无法取代威胁建模。
应该至少做到威胁的跟踪测试,及威胁的管理
表1 跟踪漏洞以修复
漏洞ID | 威胁 | 风险管理技术 | 优先方法 | 策略 | 测试者 | 是否完成 |
---|---|---|---|---|---|---|
4556 | 订单未在服务器进行检查 | 改变设计 | 修复以解决,避免依赖性 | 改变代码 | Alice | 是 |
表2 威胁管理总表
漏洞ID | 威胁 | 风险管理方法 | 技术/构建模块 | 是否完成 |
---|---|---|---|---|
1234 | 罪犯发送邮政汇票 | 回避/解决/接受/转移 | 不接受支票/邮政汇票 | 是/否 |
表3 接受的风险分表
漏洞ID | 威胁 | 成本/影响估算 | 接受原因 | 业务签字来自 |
---|---|---|---|---|
1237 | 一名警卫可能会在CEO的电脑上插入键盘记录 | 高/10000美元 | CEO还有一台电脑 | Charlene |
威胁建模的要注意“闭环”处理,他不仅仅只是一个环节,而是贯穿整个安全工程建设,应该实时进行迭代,反馈,调整
0x11 威胁建模工具
本书介绍较多的是微软的threatmodeling工具,不要盲目相信工具,换句话说就是不用工具也是可行的,只不过是用工具效率更高一些 重要的还是要有威胁建模者的思考
0x12 微软关于威胁建模的现状
Threat modeling is a core element of the Microsoft Security Development Lifecycle (SDL). It’s an engineering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application. You can use threat modeling to shape your application’s design, meet your company’s security objectives, and reduce risk.
There are five major threat modeling steps:
- Defining security requirements.
- Creating an application diagram.
- Identifying threats.
- Mitigating threats.
- Validating that threats have been mitigated.
Threat modeling should be part of your routine development lifecycle, enabling you to progressively refine your threat model and further reduce risk.
参考文献
[1] Microsoft threatmodeling
[2] Microsoft SDL
[3] 《威胁建模:设计和交付更安全的软件》