威胁建模还有多少用武之地

阅读： 48

威胁建模是一个不断循环的动态模型，随着时间的推移不断更改，以适应发现的新型威胁与攻击。还要能够适应应用程序为适应业务变更而不断完善与更改的自然发展过程。从整个企业安全能力视图来看，威胁建模工作可以在业务系统需求管理和安全设计阶段发挥作用。考虑到方法论本身具有较强的复用性，在别的阶段和领域都会有用武之地。威胁建模的动态性体现在安全需求和安全设计的不断迭代过程中。

文章目录

一、威胁建模简史

说起威胁建模，可以追溯到本世纪初，2004年微软公司就已经从流程管理、技术措施、人员组织和考量指标四个方面清晰地定义了威胁建模能力。

威胁：

是一种不希望发生的事件。它是潜在事件，通常将它最佳形容为一种可能损坏资产或目标，或者危及其安全的影响力。从本质上看，它可能是恶意的，也可能不是恶意的。From：Microsoft

威胁建模：

是一项工程技术，可以使用它来帮助确定会对您的应用程序造成影响的威胁、攻击、漏洞和对策。您可以使用威胁建模来形成应用程序的设计、实现公司的安全目标以及降低风险。From：GBT20984

威胁建模是一个不断循环的动态模型，随着时间的推移不断更改，以适应发现的新型威胁与攻击。还要能够适应应用程序为适应业务变更而不断完善与更改的自然发展过程。微软针对威胁建模能力提供了1个流程，2个模型，1个支撑工具，多名角色定义及多个评价指标：

威胁建模能力表

2008年11月，微软宣布安全性开发生命周期(SDL)威胁建模 工具 的通用版本，并提供免费下载。工具的发布是微软威胁建模发展的关键点。将威胁建模能力工具化。通过在软件上绘制流程业务数据流程图（下表中的前三步），工具便会基于STRIDE模型进行威胁识别和威胁评价

威胁建模流程表

从2008年至2016年，历经8年的时间，威胁建模的方法论基本没有更新。在2016年，微软公司对威胁建模工具进行了扩展性更新，主要更新了如下三个方面，其中模板编辑是个突破性的变化，使用者可以通过自定义威胁集合，识别出符合企业业务特性的威胁。

1、全新的威胁列表视图，可以基于列进行筛选和归类操作，便于定位和查看关注的威胁信息；

2、模板编辑功能，使用者可自定义威胁，扩展工具预置的威胁集；

3、可以迁移已经存在的数据流图，向下兼容2014版本文件。

二、威胁建模应用场景

从整个企业安全能力视图来看，威胁建模工作可以在业务系统需求管理和安全设计阶段发挥作用。考虑到方法论本身具有较强的复用性，在别的阶段和领域都会有用武之地。威胁建模的动态性体现在安全需求和安全设计的不断迭代过程中。

企业安全能力视图

场景一：安全需求识别

企业安全需求管理能力中关键活动是“安全需求识别“。下图为某企业安全需求识别流程，前期对业务系统进行场景识别，并对场景对应的安全需求进行识别，形成安全需求知识库。遇到未识别场景时，通过威胁建模方式进行威胁识别。进而导出补充安全需求。最后，整合到整体安全需求中。

安全需求识别流程图

此场景下威胁建模最大的问题是业务需求提供的资料不足以进行细粒度的威胁建模。导致安全威胁识别存在较多不适用项，准确度不高。可以通过后期的安全测试进行校验。

场景二：应用安全设计验证

安全设计阶段开展威胁建模最大的优势是具有充分的资料和相关角色辅助完成威胁建模工作。在概要设计或详细设计文档参考下，通过访谈架构师及开发人员可以准确识别资源，了解应用架构，并快速分解应用程序。进而绘制出详尽的数据流程图，识别出存在的安全威胁。设计阶段开展威胁建模工作可以依照威胁建模结果评价现有安全需求是否全面、现有安全设计在细粒度和有效性方面是否与安全目标相符。下面截取部分微软威胁建模工具生成的威胁报告：

部分数据流图

威胁列表：

1. Spoofing the Browser External Entity [State: Not Started] [Priority: High]

2. Cross Site Scripting [State: Not Started] [Priority: High]

3. Elevation Using Impersonation [State: Not Started] [Priority: High]

三、威胁建模方法分析

1、微软公司威胁建模方法论成熟，具有较强的落地性；

2、2014版以及之前版本威胁建模工具威胁识别结果不具有针对性，例如：web应用威胁方面，建模结果不如研究组织威胁列表具有指导性；

3、2016版本威胁建模工具通过自定义模板可弥补针对性不强缺点。但是，需要将威胁场景化并开发针对性的威胁模板。

四、威胁列表推导法

随着B/S架构应用成为主流，各大安全研究组织都对web应用的威胁进行了归纳总结。只是不同机构描述的视角有所不同。有些机构从“攻击“视角，有些机构从”测试“视角。但是都可以通过描述方式的转变转化为”威胁“视角。即形成威胁列表。威胁列表本身不是一个方法论，而是一些相关工作结果。可以以威胁列表为输入，结合业务场景分析，将业务场景与威胁建立起关联，就是威胁列表推导威胁的过程。

我们先来看看The Web Application Security Consortium (WASC)的威胁列表。

再来看看，根据web应用安全测试经验反推出来的威胁列表。

五、威胁列表推导法分析

1、专项领域威胁识别较为全面，例如：WASC和OWASP对web应用和移动APP应用威胁识别较为全面；

2、缺少业务数据流分析过程，与业务系统功能或场景映射关系不直观。需要根据经验将威胁列表场景化后，在与业务系统场景进行关联；

3、需要自主研发工具进行快速威胁识别和导出。

六、综合威胁分析法

在开始讲述综合威胁分析方法之前先来回顾下威胁建模和威胁列表推导法各自的优劣势。

由于威胁建模与威胁列表推导方式都存在一些劣势，因此，本文建议一种整合的威胁分析方法，即：综合威胁分析法。

综合威胁分析法是基于场景化处理结果，将威胁建模和威胁列表导出的威胁结合，再通过专家或AI判断，最终识别安全威胁的过程。

关键步骤说明：

第一步:主要完成场景化处理，一方面将业务功能进行场景化处理，另一方面将威胁列表按照场景进行分类。

例如：

业务场景包括：用户认证登录场景，账号信息查询场景，跨行转账场景等；

通用场景威胁列表，如下表所示：

场景化威胁表

第二步:业务流程分析是在应用结构分析和应用分解后，完成业务数据流程图绘制过程，如下图所示：

数据流图（微软威胁建模工具绘制）

第三步:利用威胁建模工具完成威胁建模，导出威胁列表；

第四步:将第一步识别的“业务场景”和“通用场景威胁”以场景名称为关联要素进行匹配。便可获得业务场景对应的威胁列表；

第五步:通过专家分析或引入AI分析，综合威胁建模结果和场景威胁列表结果，最终导出合理的威胁列表。专家分析原则：用威胁建模结果保证威胁覆盖度，以威胁列表结果确保威胁深度。

第六步:优化活动，将威胁建模新识别的威胁进行分析、去重后录入威胁库。

七、总结

考虑到敏捷开发模式逐步成为主流，采用综合的威胁分析方法会在一定程度上会影响开发进度。因此，建议在使用综合威胁分析方法时，以场景化威胁列表方式为主体方法。功能场景化后，快速映射场景威胁列表导出威胁。遇到未识别场景时，再采用威胁建模的方式对未识别场景进行建模分析。并将新威胁分析入库。后续迭代出现类似场景即可快速识别。