威胁建模 -读书笔记

0x00 《威胁建模-设计和交付更安全的软件》(THREAT MODELING-Designing for Security)

《黑衣人》台词: “生活本来就充满痛苦,殿下。 不这么对您说的人一定是在推销什么。”

0x01 潜心开始威胁建模

威胁建模的关键是回答以下四个问题

问题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,泳道图,状态图

数据流图的核心要素

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的替代方法来寻找威胁。

创建新的攻击树

0x05 攻击库

攻击库属性

通过提供各个模式的细节攻击清单,攻击库或许对就攻击者如何工作了解不是很深入的人来说,是有帮助的。
在提供诸多细节攻击清单与枯燥寻找威胁之间找到普遍有用的威胁点是有挑战性的。
同样具有挑战的是,要是提供特别详尽的细节会让读者误以为检测列表就是全面的了,所以要注意平衡。
实施文献检索和在攻击库中获取细节,是很好的提高安全知识的方法

威胁也是有抽象等级的,比如 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 外部安全注解

0x08 防御策略及技术

8.1 减缓威胁的策略及技术

8.1.1 认证,减缓欺骗威胁

认证计算机技术

认证信息技术

认证人的技术

8.1.2 完整性,减缓篡改威胁

保护文件的技术

保护网络流量的技术

8.1.3 不可否认性,减缓否认威胁

可用于解决否认的技术

8.1.4 机密性,减缓信息暴露威胁

保护文件

保护网络数据

保护沟通或沟通的事实

8.1.5 可用性,减缓拒绝服务威胁

保护文件的技术

8.1.6 授权,减缓权限提升威胁

提高授权的技术

8.2 利用模式解决威胁

模式是表达专家如何捕捉解决重复出现的问题的方法。

8.3 减缓隐私威胁

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工具,不要盲目相信工具,换句话说就是不用工具也是可行的,只不过是用工具效率更高一些 重要的还是要有威胁建模者的思考

微软威胁建模工具下载
TM工具使用介绍

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:

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] 《威胁建模:设计和交付更安全的软件》

Table of Contents