Soatok的威胁模型非正式指南

背景

本文源自 Hacker News 上的一篇博客帖，作者 Soatok（一位以“毛茸茸”风格著称的独立安全研究员）有感于行业内对“威胁模型”（threat model）一词的滥用和误解。他指出，很多人把“威胁模型”当成时髦的 buzzword，却根本不理解其实际含义——尤其在混合后量子密码学、端到端加密应用端点攻击、以及政客推动的“年龄验证”等话题的争论中，这一缺失尤为明显。Soatok 因此撰写了一份非正式的入门指南，帮助零基础的人建立对威胁模型的直觉，而不是提供一本学术教科书。

核心内容

什么是威胁模型？

威胁模型在正式信息安全领域是一个系统性的流程，但即使是产品或服务在设计阶段进行一次非正式的威胁建模，也能显著改善最终结果。一个基础的威胁模型至少要回答以下四个问题：

1. 我们到底要保护什么？
   如果连这都答不上来，说明前期工作严重不足。

2. 谁/什么想要伤害我们保护的东西？
   黑客、活动人士、网络跟踪者、社交媒体骚扰网络、自然灾害/坏运气、超负荷工作的员工、被大公司游说收买的愚蠢立法机构、国家级对手……等等。

3. （2）将如何攻击（1）？
   攻击场景就在这里，墨菲定律也在这里。

4. 我们将采取什么措施来阻止（3）发生？
   墨菲定律同样适用这里。

如果能回答这四个问题，可以在某种意义上称这份文档为“威胁模型”。然而，实践中这样往往不够，因为会遗漏一些关键细节：

• 资产之间如何关联？（用图思考，而非列表；不同目标价值不同）
• 我们做了哪些假设？（尤其是在第4、5项上）
• 我们明确不处理哪些威胁？（不可能预见并解决所有攻击，不要假装可以）

假设的重要性

很多人讽刺地忽视了“假设”的重要性。如果某个假设是错的，那么模型至少是不完整的，需要重新考虑已接受的风险列表。作者举了一个例子：Invisible Salamanders 攻击。在某些端到端加密消息设计引入举报功能后，该攻击得以实现。原因在于所采用的 AEAD 方案（如 AES-GCM、ChaCha20-Poly1305）有一个假设：一条消息只有一个有效密钥。一旦引入多个有效密钥（或混淆代理人），就超出了算法的安全保证，攻击者便可利用这一点。

明确假设有助于识别“未知的未知”。威胁模型是活文档，不是快照，应当适时更新。

如何开始威胁建模

专业做法可参考 Threat Modeling Manifesto。作者的个人方法如下：

1. 抄下上述7项问题（4+3扩展），以便快速复制粘贴。
2. 在白纸上（或数字等价物）画出系统所有组件的结构图，明确哪个组件直接通信、依赖或交互另一个组件。
3. 在整张图外画一个大框，然后像玩 Fortnite 安全区一样，逐步缩小框体聚焦到每个组件。每轮迭代，记录组件的所有输入输出，尽量回答7个问题。
4. 重复直到深入到你抽象层的极限，然后头脑风暴你对未深入分析的层所做的假设。

这种做法是从最高层开始，逐步细化到具体部件。例如，数据库对 X25519 安全的依赖可能和负载均衡器不同，但数据库也不应该内置 RSS 源。注意不适当的关系并尽量切断。

作者自己的例子

作者正在为 Fediverse 实现密钥透明度（key transparency），项目跟踪在 publickey.directory。其规范中包含了突出的威胁模型，分为：

• 假设（首先声明）
• 资产
• 行动者（攻击者和被保护者，各有角色名）
• 风险（带有四种状态）：
  • 设计阻止：攻击根本不可能成功 😀
  • 缓解：攻击不应成功，除非假设错误——对研究人员最有趣。
  • 可解决：有办法缓解风险，但需要努力或谨慎，操作人员应知晓。
  • 开放：无法或不会缓解的风险，这类攻击将会成功。

该模型并不完美（例如未用可读图展示资产与行动者的关系，可能存在盲点，可能漏记重要假设）。但如果读者能看出其缺点，说明已经足够理解威胁建模，可以自己写了。

反面例子：Matrix 的威胁模型

作者之前两次批判过 Matrix，这里展示了 Matrix 的威胁模型（v1.18）片段，标题为“9. 安全威胁模型”，子节包括：

• 9.1 拒绝服务：攻击者可能阻止消息传递，以破坏商业对手的服务/营销、审查讨论或参与者、实施一般破坏。
  • 9.1.1 资源耗尽：攻击者导致受害者服务器耗尽特定资源（如 TCP 连接、CPU、内存、存储）。
  • 9.1.2 不可恢复的一致性违例：攻击者发送消息导致集群进入不可恢复的“分裂脑”状态。
  • 9.1.3 坏历史：攻击者诱使受害者接受无效消息，并将其纳入聊天室历史，其他服务器会拒绝这些消息并连带受害者的后续消息。
  • 9.1.4 阻断网络流量：攻击者尝试防火墙隔离受害者服务器与部分或全部其他服务器。

作者以此作为反面教材，暗示其威胁模型过于简单、缺乏对资产关系、假设和未解决威胁的清晰说明。

关键要点

• 威胁模型的核心是回答四个基本问题：保护什么、谁想伤害、怎么伤害、怎么阻止。但仅此不够，还需补充资产关系、假设和明确不处理的威胁。
• 假设是威胁模型中最脆弱也最重要的部分。一旦假设错误，整个模型可能失效。Invisible Salamanders 攻击就是例子。
• 威胁模型应当是活文档，不是一次性快照，应随系统变化更新。
• 推荐的建模方法：从高层架构图开始，逐步向内聚焦每个组件，记录输入输出，逐项回答威胁问题，直到无法再深入；然后思考对未深入层的假设。
• 好的威胁模型会明确区分风险状态（设计阻止、缓解、可解决、开放），并承认自己的不完美。
• 反面教材：像 Matrix 的威胁模型那样只列出 DoS 子类而缺少对资产关系、假设和未处理威胁的讨论，在实践中价值有限。

意义与影响

Soatok 这篇非正式指南的重要意义在于它拉低了威胁建模的门槛，让非安全专业的人也能快速理解并上手。在许多初创公司和开发者群体中，威胁模型往往被视为“安全团队的文档”而被忽视，导致产品在设计之初就埋下隐患。作者通过直白、幽默的语言（包括自嘲“毛茸茸的博客”）和具体例子（Invisible Salamanders、Matrix 模型）强调了两点：一是威胁模型不是学术专利，每个人都可以做；二是假设的明确化能帮助识别未知盲区，避免安全保证的虚假安全感。

对行业的影响是：鼓励更多开发者在设计阶段就引入非正式的威胁建模，而不是事后补救。同时，作者对 Matrix 威胁模型的批评也提醒了现有项目——即使是大组织的威胁文档，也可能流于表面。文章呼应了行业内近年来对“以设计安全”（security by design）的重视，威胁模型正是其核心工具之一。尽管原文风格轻松，但其核心建议——画图、列假设、接受不完美并持续迭代——为初学者提供了一条清晰的实践路径。