威胁模型的陌生现状在忙碌疲惫的一天里参与了关于混合后量子密码学的讨论应付端点攻击找茬的人还参与留言板讨论后发现“威胁模型”对多数人仍是陌生概念且多被当作时髦用语。有趣的相关画作有一幅由 Embyr 创作的画画中穿着 DEFCON 衬衫的人说“威胁模型”Soatok蓝色豺狗形象有相应反应。这幅画是在反疫苗者将“威胁模型”用作时髦用语时期委托创作的即便没这背景也挺有趣。博客适用人群说明若想找有超 100 篇引用、关于为涉及多个区块链的新初创公司撰写正式威胁模型文档的学术资源这个博客可能不合适可从 STRIDE 和系统理论入手若想从零培养对好的威胁模型应回答哪些问题的直觉可能来对地方了。新手的威胁建模有一幅由 Harubaki 创作的名为“新手”的画。从宏观看别把威胁建模想得太复杂虽它是正式网络安全流程有专家专门研究但也可在新产品或服务设计和架构阶段进行非正式威胁建模且可能有更好结果。一个威胁模型至少应回答这些基本问题1. 我们最初要保护的是什么若答不上来还有很多基础工作要做。2. 谁或什么想要损害我们要保护的东西包括黑客、激进分子等多种主体。3. 第 2 点中的主体可能如何攻击第 1 点中的目标要列出攻击场景考虑墨菲定律。4. 我们将采取什么措施来防止第 3 点中的情况发生墨菲定律同样适用。若能回答上述问题可称文档为威胁模型但实践中往往因关键细节遗漏而无用。还有 5. 第 1 点中的资产是如何关联或连接的要从图的角度思考并非所有目标都有同等价值。6. 我们做了哪些假设尤其是在第 4 点和第 5 点中将在下面详细说明。7. 我们故意不处理哪些威胁不可能应对所有可能攻击别假装能做到。明确假设极其重要若假设错误模型至少不完整或需重新考虑接受的风险列表。例如隐形蝾螈攻击会破坏某些端到端加密消息设计中的滥用报告功能前提是引入滥用报告机制这是因为相关 AEAD 方案的假设被打破。明确假设能识别未知的未知因素威胁模型应是动态文档可适时更新。还有一幅由 CMYKat 创作的击掌贴纸画。如何开始威胁建模若想专业进行威胁建模可阅读《威胁建模宣言》。做法是先将上述 7 点写成可快速复制粘贴的格式接着绘制系统组件及关系设置好后在图周围画框像玩《堡垒之夜》一样迭代记录组件输入输出尝试回答 7 个问题重复过程直到深入底层思考对未深入研究层的假设。还有一幅由 CMYKat 创作的剪贴板贴纸画。要从最高层面开始逐步深入注意不恰当关系并尽量切断。示例自己的工作正在为 Fediverse 实现密钥透明性可在 publickey.directory 查看进展。该工作始于一份规范其中包含显著的威胁模型分为假设、资产、参与者并赋予角色名称、风险等部分风险有设计上可防止、可缓解、可解决、开放四种状态。当然这个威胁模型并不完美可能存在呈现关系不完美、有盲点、忘记写重要假设等问题。若能看出不足可能已足够理解如何编写自己的威胁模型但只看此例学不到太多还需糟糕的威胁模型文档示例。还有一幅由 CMYKat 创作的 Soatok 喝咖啡的画。糟糕的示例Matrix 的威胁模型之前曾批评过 MatrixMatrix 的威胁模型列出了拒绝服务、欺骗、垃圾邮件、间谍活动等攻击类型及具体威胁但存在只是攻击类型列表、无假设列表、无资产列表及关系说明、攻击列表不完整、多年基本不变等问题。尽管如此Matrix 至少有威胁模型相比之下Signal 只提供技术规范让用户自己琢磨威胁模型。所以给 Matrix 的威胁模型打 C - 一个糟糕的威胁模型总比没有好。还有一幅画得很糟糕的星星上面写着“一次尝试”。威胁模型如何帮助你构建更好的产品在信息安全领域初期会听到“防御者必须每次都做对而攻击者只需要成功一次”但装备精良的防御者可选择战场。安全从业者鼓吹纵深防御真正做到需充分理解威胁模型迫使攻击者陷入死胡同。防止凭证填充攻击凭证填充攻击有效是因为人们重复使用密码而人们重复使用密码是因为只能记住有限数量密码。为降低风险密码管理器曾是正确答案如今通行密钥更好因为它是更用户友好的身份验证方式理想情况用户用硬件安全令牌一般情况操作系统或密码管理器提供功能。不断追问“为什么”可了解安全控制中固有威胁但有陷入死胡同风险。若想避免凭证填充和相关攻击可采取设计应用程序要求使用通行密钥、要求用户注册多个通行密钥、为管理员提供添加新通行密钥方法并记录操作、尽量不支持密码身份验证等措施。通行密钥无法被网络钓鱼采用它能节省成本、避免无效测试、消除多种攻击并提高可用性。一个好的威胁建模练习可让人有此发现。有一句名言“以牺牲可用性为代价的安全最终也会损害安全”。还有一幅由 CMYKat 创作的 Soatok 戴着用胶带粘起来的眼镜的画。分布式端到端加密密码学专家和去中心化爱好者讨论两种直接消息端到端加密提案即 ActivityPub E2EE 规范和 Germ Network 项目都曾考虑用 MLS 作为密钥管理协议但在非中心化系统中使用 MLS 有两个重要注意事项。一是 MLS 定义的认证服务被 SimpleX 负责人误解提出的密钥透明性提案是解决方法二是消息排序对 MLS 时代的棘轮树安全性至关重要。对于 ActivityPub采用密钥透明性后需处理 KeyUpdate 消息竞争问题对于 ATProto / BlueSky 情况更棘手。为什么 ATProto 让问题更难解决ATProto 不像 Fediverse 有实例部分原因是其由受比特币影响的开发者设计认为拥有“全局状态”是不错的服务设计选择而区块链是难稳定的全局状态。与 ActivityPub 不同不能简单构建加密消息传递工具安全分析时要将内容视为点对点需设计复杂协议保证消息排序或放弃 MLS 采用成对端到端加密。还有一幅由 AJ 创作的 Soatok 对着电脑大喊的画。威胁建模的帮助若将用户消息保密性视为安全目标且希望托管去中心化ATProto 受区块链启发的设计会阻碍使用有效群组密钥协商协议。目前有工程师在解决问题但设计阶段可避免错误。还有一幅由 AJ 创作的 Soatok 出现故障的画。威胁模型的非实用用途读到这里应明白什么是威胁模型、好的威胁模型应包含什么、如何识别糟糕的威胁模型、威胁建模如何帮助构建更好的产品。这些实用内容可能枯燥提升威胁建模技能还能在技术讨论中识破胡说八道。后量子密码学的威胁建模最近写了关于混合后量子结构的博客IETF 的 TLS 工作组邮件列表在进行最后一轮讨论Daniel J. Bernstein 召集人谴责。像 Patrick Timothy Dalrymple、Willow 等人的言论引发 DJB 回应。除了不讲道理和性骚扰者要求很多人说明具体安全担忧他们遵循非黑即白思维方式。为应用威胁建模理解这种情况需确定事实1. ML - KEM 不是 NSA 的设计主要提交者是 Peter Schwabe其他提交者分布在欧洲各地。2. 信息论排除 ML - KEM 存在后门的可能性。3. ML - KEM 是通过公开、长达十年的国际努力被选中进行标准化的。4. NIST / FIPS / NSA 要求在机密系统中使用非混合的 ML - KEM / ML - DSA若有后门他们急于迁移系统就太愚蠢。不同意这些事实的人是拒绝现实应拿出证据。当前 IETF 讨论发布为非混合的 ML - KEM 建立代码点的 RFC混合 KEM 更受青睐发布该 RFC 对配置为始终使用混合 KEM 的系统安全性无降低。谷歌 Chrome 已支持非混合的 ML - KEM阻止该 RFC 对大多数互联网用户的现实世界安全无好处。该 RFC 对需遵守特定规则且要求有稳定 IETF RFC 编号的组织有作用。出于意识形态反对 RFC 会让相关人陷入困境与减少危害目标相反。技术上有人认为混合后量子 传统密码学比纯后量子更好这就需运用威胁建模技能思考。用 Q - Day 简称“对手建造出与密码学相关的量子计算机的那一刻”KEM 面临“现在收集以后解密”风险。纯 ECDH 在 Q - Day 时会被追溯性破解纯后量子算法在 Q - Day 时若本身未被破解则不会被破解混合后量子 ECDH 是对 Q - Day 之前算法被破解的对冲策略但 Q - Day 之后完全没用。DJB 煽动反对纯后量子算法支持混合后量子 ECDH但 ECDH 在 Q - Day 时对安全性贡献为零。如今主张使用 ECDH ML - KEM 承认 ML - KEM 长远来看是安全算法选择。选择混合方案一是能更快过渡到后量子时代二是对冲 ML - KEM 或基于格的密码学算法类在 Q - Day 之前被破解的风险。最理智的主张是使用 ML - KEM HQC ECDH 的三方混合方案反对 RFC 的人没人主张此方案。对 RFC 的反对意见往往愚蠢且考虑不周全是锻炼辨别能力的好机会也不必信任 NSA 等间谍机构。还有一幅由 CMYKat 创作的吐舌贴纸画。结语互联网上有正式介绍威胁模型及处理方法的指南但希望读完这篇博客后能对威胁模型文档质量和有效性有初步判断甚至更认真对待这个话题。
（支持资料、图片参考_相关定制）_)
