简单记录对安全设计、威胁建模的实践和心得,部分资料来自于大神@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)

    http://www.ijiandao.com/2b/baijia/117251.html

    https://docs.microsoft.com/zh-cn/azure/security/azure-security-threat-modeling-tool

    https://simoneonsecurity.com/threatsmanagersetup-v1-5-10/

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

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

    实际产出报告:
    NA