【安全测试】安全测试威胁建模设计方法STRIDE

news2024/12/26 1:04:51

背景

TM(ThreatModeling)

实践

具体流程

资料获取方法

背景

目前安全测试一般都存在如下问题：

安全测试人员不懂业务，业务测试人员不懂安全，安全测试设计出现遗漏是无法避免的
安全测试点繁多复杂，单点分析会导致风险暴露，不安全

目前的状态：

TR2阶段测试人员根据开发人员提供的story威胁分析设计文档，检查已有的削减措施是否正常实现
检查建议的削减措施是否合理，待版本转测试后对削减措施进行多角度测试，确保削减措施被正确实施并真正削减产品分析出的威胁。

基于以上两点需要一套完整的，连贯的方法指导安全及业务特性的安全测试设计，TM（ThreatModeling，威胁建模）安全测试设计方法应运而生。

TM(ThreatModeling)

威胁建模的本质：尽管通常我们无法证明给定的设计是安全的，但我们可以从自己的错误中汲取教训并避免犯同样的错误。

TM主要的理论、实践来源是微软的STRIDE威胁建模方法论，它从6个维度来考察系统设计时存在的来自外部威胁的风险点。

首先需要知道什么样的设计是“安全的”，安全设计原则：

设计	安全原则
开放设计	假设攻击者具有源代码和规格。
故障安全预设值	出故障时自动关闭，无单点故障。
最低权限	只分配所需的权限。
机制经济性	保持简单、易懂的特性。
分离权限	不允许根据单一条件执行操作。
总体调节	每次检查所有内容。
最低公用机制	注意保护共享资源。
心理可接受性	他们将使用它吗？

更进一步，设计完的系统应具有哪些安全相关的属性？

安全属性	详细
机密性	数据只应限具有权限的人员访问。
完整性	数据和系统资源只限适当的人员以适当的方式进行更改。
可用性	系统在需要时一切就绪，可以正常操作。
身份验证	建立用户身份（或者接受匿名用户）。
授权	明确允许或拒绝用户访问资源。
认可	用户无法在执行某操作后否认执行了此操作。

STRIDE是这6个维度的单词的首字母的缩写；这6个维度分别为：

Spoofing（假冒）
Tampering（篡改）
Repudiation（否认）
Information Disclosure（信息泄漏）
Denial of Service（拒绝服务）
Elevation of Privilege（权限提升）。

下图对这六项信息各自进行了距离：

属性	威胁	定义	例子
认证	Spoofing（假冒）	冒充某人或某物	假冒billg、microsoft.com或ntdll.dll
完整性	Tampering（篡改）	修改数据和代码	修改一个DLL，或一个局域网的封包
不可抵赖性	Repudiation（否认）	宣称未做过某个行为	“我没有发送email” “我没有修改文件” “我肯定没有访问那个网站”
机密性	Information Disclosure（信息泄露）	暴露信息给未经授权的访问者	允许某人阅读Windows源代码；将客户列表发布在网站上
可用性	Denial of Service（拒绝服务）	使对服务对用户拒绝访问或降级	发送数据包使目标系统CPU满负荷或发送恶意代码使目标服务崩溃
授权	Elevation of Privlege（权限提升）	未经授权获取权限	远程用户执行任意代码，普通用户可以执行管理员私有的系统指令

实践

很多安全从业者所接受的安全认知往往是进入一家企业后，拿到一份名为应用开发安全标准的文档，里面描述了访问控制、输入验证、编码过滤、认证鉴权、加密、日志等各种要求，久而久之就变成了一种惯性思维，实际上之所以要这么做是因为在系统设计的某个环节存在STRIDE中的一种或几种风险，所以在那个设计关注点上要加入对应的安全措施，并不是在所有的地方都要套用全部的或千篇一律的安全措施。否则就会变成另外一种结果：“过度的安全设计”。

威胁建模的成果跟工作者自身的知识也有很大的关系，有攻防经验的人比较容易判断威胁的来源和利用场景，如果缺少这方面的认知，可能会发现到处是风险，有些风险的利用场景很少或利用条件非常苛刻，如果一味地强调风险削减措施也会变成有点纸上谈兵的味道，虽然从安全的角度没有错，但从产品交付的整体视角看，安全还是做过头了。