我的威胁建模交流和心得

简单记录对安全设计、威胁建模的实践和心得，部分资料来自于大神 @code01x：
类似 coding 只占开发中的一个步骤，现在的安全测试不应使用 burpsuite 就去测试。此处为了实现在渗透测试、修复方案做出资源权衡，交付应用程序满足安全目标。举一个测试 src 新上线例子的金币兑换业务，步骤应为 1、确定安全目标为，新上线功能不发生资金、隐私、内网网络突破风险等，并进行排序；2、同设计、需求、研发人员沟通输入各项文档、部署图，用例、场景，创建和分解应用程序结构，确定资产，画出金币、用户数据的流向，积分、订单、发货各系统间信任边界；3、详细识别应用场景遇到的威胁，认证攻击、逻辑攻击、枚举威胁。依优先级发现各接口的弱点，识别风险确定漏洞，使用威胁列表分类避免遗漏。最终采用对策来改进开发和需求过程中的薄弱点，归类新业务场景的威胁至知识库。输出威胁和漏洞列表，帮助人员了解潜在的设计、实现缺陷。识别设计阶段对默认配置或伪随机数算法使用不当的威胁；发现诸如在竞争条件下的订单重复取消导致金币退还问题、sql 注入漏洞，开始动手解决威胁。这里注意到各阶段的参与人员不同，列为看官需要将角色向应用生命周期前移。这个关系就像各安全文档是消防制度、安全漏洞修复是灭火器，甲方的主动测试为烟雾报警器。目前是问题驱动尽量前移，愿景是通过安全赋能或者优雅的自动化来实现。安全人员正是可以在与相干人的问与答之间权衡安全风险级别。以上说的是基于判断安全测试的范围和流程来说的威胁建模，不涉及设计阶段。
工具方面基本都是这基本上都是差不多，external，store，process，trust boundary 组成。微软提供了建模工具 threat modeling tool，根据 Threat modling 的结果去创建对应的 security test cases。尝试使用该工具画数据流图，但是由于是默认的模板，实在是不好用。突出问题有三：1、默认的 process、dataflow 有限，导致产生的报告基本是错的。2、bi-Directional connect 两个由标签构成，其实也只是两个连接线放在一起了，可以随意拖动不好用。解决的办法是用单向流向表示，因为风险已经发生在从 A-B 的，那么 B-A 已经是风险。不考虑什么 wifi、udp 的场景了。有时候放具体的东西较容易，比如某个请求中有那些数据，返回中却是不同的数据，可以分别列上去。工具提供的都是非常 general 的，具体自己用的时候具体灵活发挥。3、没有子系统的表示方式。攻击树又是另外一个问题了，构建合适 and 的 or 模型很麻烦，思维导图倒是有不少，工具方面 seamonster 已经不维护了，但是创建攻击树的体验非常好。

https://en.wikipedia.org/wiki/Misuse_case 另外还这种“基于错误案例的”建模方法。。

参考资料：

https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ff647894(v=pandp.10)

威胁建模还有多少用武之处 | 爱尖刀

Threats Manager 1.5.10 – BETA The second BETA Release of a new minor version for Threats Manager, introducing shortcuts to improve efficiency. Simone On Security - simoneonsecurity.com

https://msdn.microsoft.com/zh-cn/library/ms978518.aspx

https://www.synopsys.com/content/dam/synopsys/sig-assets/ebooks/threat-modeling-misconceptions.pdf

实际产出报告：
NA