威胁建模实际上是一种技能，基于经验，在了解什么有效和什么无效之后。
我不认为选择框架会让你的事情变得更容易，你仍然会遇到和现在一样的问题和困难。

相反，我会推荐 STRIDE-per-element 作为更好的起点，然后再酌情添加其他技术。

您可能更可能只需要一些关于如何有效地进行威胁建模的指示，简单地改变方法并不是您的灵丹妙药。

我的建议：

• 首先与经验丰富、知道如何做的人一起完成整个威胁建模练习——这确实是通过实践来学习的最佳方式。即使这意味着要聘请外部顾问几个小时。
• 推荐 DFD 的原因之一是因为这些通常已经存在。尝试找出是否有人拥有这些，甚至类似的东西。
• DFD 的另一个原因是因为它们相对简单。如果你说你卡在细节上，然后缩小，并将 DFD 保持在第 0 层或第 1 层，只是偶尔根据需要向下挖掘到第 2 层——但仅此而已。
• 请记住，您希望专注于高级概述、模块之间和跨信任边界的流程。您永远不必深入研究实现（尽管涉及了解其工作原理的开发人员/架构师，您能否帮助您发现需要额外映射的有趣点。）不要被细节迷惑！
• Microsoft 有两种不同的工具来帮助进行威胁建模，TAM 和 SDL TM。这些基于不同的观点和子方法，其中一个用作类似“向导”的应用程序。我更喜欢 SDL TM。
• 考虑一次将 TM 集中在应用程序的一个模块/部分上，而不是试图一次抓住所有的模块/部分。
• 请记住，在 TM 期间，您不是在寻找解决方案。这可以迅速转移任何 TM 的努力。
• 理想情况下，您将获得所有利益相关者（架构/产品管理/开发/QA/运营......）的观点和意见，但实际上，在许多组织中这是不可能的 - 相反，尝试集中一点时间与每个人的代表，并提出有助于充实您的模型的具体问题。如果没有 DFD 或其他图表，而您自己构建了它 - 获得他们的反馈，他们通常会感谢您为他们提供这些。

关于 TM 的一些额外想法，根据您最后的额外问题：
只需将适当的 Web 应用程序扫描仪指向您的服务器肯定会更容易。但是，我相信 TM 会更有效，从长远来看也会更有效（出于多种原因，尽管主题不同）。
即使该应用程序已经存在，仍然值得回过头来分析它 - 有些事情会更容易（减少猜测），有些事情可能不会成功，但您可以发现哪些类型的缺陷是有趣的。这就是可以帮助您返回并解决特定问题的方法，而不仅仅是不适用于您的业务的技术问题。最坏的情况——它所能做的就是帮助您将测试工作集中在更重要的领域 “有趣”，而不是对整个系统进行大规模测试。

在过去教别人如何做 TM 时，我发现一些链接很有帮助：

• 游击威胁建模
• Microsoft's Patterns&Practices: Threat Modeling Web Applications（整本书被标记为过时，但该部分仍然相关）。
• 威胁模型改进您的安全流程(Michael Howard)
• MS 的 Larry Osterman 的权威多部分 TM 指导（第一部分从这里开始）

Verison 有一个与行业一起开发的开放框架。我发现它非常轻量级，它可能对您用于威胁建模很有用。您可以在以下位置找到社区文档：https ://verisframework.wiki.zoho.com/ 。

Microsoft 拥有威胁分析和建模工具，该工具似乎包含了他们的许多 STRIDE / DREAD 信息以及来自他们的威胁和对策最佳实践的威胁对策。

一些方法和工具：

Microsoft 威胁建模 - 似乎非常以技术/工程为中心，需要经验丰富的安全分析师来构建详细的威胁模型。在敏捷环境中，扩展可能是一个问题。

PASTA（攻击模拟和威胁分析过程）- 在这里找到。这种方法似乎会涉及 SDLC 中的所有利益相关者，包括您的开发人员。

Trike - 通过考虑风险来进行威胁建模。

工具

• 微软 TAM
• MyAppSecurity ThreatModeler
• 三轮车
• 实际威胁分析