跳到内容

威胁建模备忘单

简介

威胁建模是现代应用程序开发人员需要理解的重要概念。本备忘单旨在为威胁建模新手和寻求复习的人员提供一份简洁但可操作的参考。官方项目页面是 https://owasp.org/www-project-threat-model/。

概述

在应用程序安全的背景下，威胁建模是一个结构化、可重复的过程，用于获取特定系统安全特征的可操作洞察。它涉及从安全角度对系统进行建模，根据此模型识别适用的威胁，并确定对这些威胁的响应。威胁建模从对抗角度分析系统，侧重于攻击者如何利用系统。

威胁建模最好在软件开发生命周期 (SDLC) 的早期（例如设计阶段）进行。此外，它并非一次性完成，永不再进行。威胁模型应该与系统同步维护、更新和完善。理想情况下，威胁建模应无缝集成到团队的常规 SDLC 流程中；它应被视为流程中标准且必要的步骤，而不是附加项。

根据《威胁建模宣言》，威胁建模过程应回答以下四个问题：

  1. 我们正在做什么？
  2. 可能出现什么问题？
  3. 我们打算如何应对？
  4. 我们做得足够好吗？

这四个问题将作为下面描述的四个主要阶段的基础。

优点

在概述流程之前，可能值得回答一个问题：为什么进行威胁建模？为什么要在开发过程中增加更多工作？有什么好处？以下部分将简要概述这些问题的一些答案。

尽早识别风险

威胁建模旨在在设计阶段识别潜在的安全问题。这使得安全能够“内置”到系统中，而不是“事后补救”。这比在系统投入生产后识别和解决安全漏洞要高效得多。

提高安全意识

适当的威胁建模要求参与者对特定应用程序的安全和威胁态势进行创造性和批判性思考。它挑战个人“像攻击者一样思考”，并将通用的安全知识应用于特定上下文。威胁建模通常也是一项团队工作，鼓励成员分享想法并提供反馈。总的来说，威胁建模可以被证明是一项非常有教育意义的活动，使参与者受益。

提高对评估目标 (TOE) 的可见性

威胁建模需要对所评估的系统有深入的理解。要正确进行威胁建模，必须理解数据流、信任边界和系统的其他特征。因此，Stiliyana Simeonova 断言，提高对系统及其交互的可见性是威胁建模的一个优点。

解答每个问题

威胁建模过程没有普遍接受的行业标准，也没有适用于所有用例的“正确”答案。然而，尽管存在这种多样性，大多数方法确实以某种形式包含系统建模、威胁识别和风险响应过程。受这些共同点启发，并以我们上面讨论的四个关键威胁建模问题为指导，本备忘单将威胁建模分解为四个基本步骤：应用程序分解、威胁识别和排名、缓解以及审查和验证。也有一些与此不太一致的过程，包括 PASTA 和 OCTAVE，它们各自都有热情的倡导者。

系统建模

系统建模的步骤旨在回答“我们正在构建什么？”这个问题。如果不了解一个系统，就无法真正理解哪些威胁最适用于它；因此，这一步为后续活动提供了关键基础。尽管在威胁建模的第一步中可以使用不同的技术，但数据流图 (DFD) 无疑是最常见的方法。

DFD 允许人们可视化地建模一个系统及其与数据和其他实体的交互；它们使用少量简单符号创建。DFD 可以在专用的威胁建模工具中创建，例如OWASP 的 Threat Dragon 或微软的 Threat Modeling Tool，也可以使用通用绘图解决方案，例如draw.io。如果您偏好代码即方法，OWASP 的 pytm 可以提供帮助。根据所建模系统的规模和复杂性，可能需要多个 DFD。例如，可以创建一个 DFD 来表示整个系统的高级概述，以及一些更侧重于子系统的详细 DFD。技术工具并非严格必要；在某些情况下，白板可能就足够了，尽管最好以易于存储、引用和根据需要更新的形式保存 DFD。

无论 DFD 或可比较模型如何生成，重要的是解决方案能够清晰地展示信任边界、数据流、数据存储、流程以及可能与系统交互的外部实体。这些通常代表可能的攻击点，并为后续步骤提供关键输入。

数据流图 (DFD) 的另一种方法可以是头脑风暴技术，这是一种有效的生成想法和发现项目领域的方法。在此背景下应用头脑风暴可以带来诸多好处，例如提高团队参与度、统一知识和术语、对领域形成共同理解，以及快速识别关键流程和依赖关系。使用头脑风暴的主要论点之一是其灵活性和几乎适用于任何场景的适应性，包括业务逻辑。此外，当非技术人员参与会议时，这种技术特别有用，因为它消除了与理解和应用 DFD 模型组件及其正确性相关的障碍。

头脑风暴能吸引所有参与者，促进更好的沟通和对问题的相互理解。每个团队成员都有机会做出贡献，这增加了责任感和参与感。在头脑风暴会议期间，参与者可以协作定义和商定关键术语和概念，从而在项目中使用统一的语言。这在不同团队可能对术语有不同方法的复杂项目中尤为重要。由于头脑风暴的动态性质，团队可以快速识别关键业务流程及其相互关系。

将头脑风暴的结果与正式建模技术相结合，可以更好地理解领域并更有效地设计系统。

威胁识别

在系统建模完成后，现在是时候回答“可能出现什么问题？”这个问题了。必须结合第一步的输入来探讨这个问题；也就是说，它应该侧重于在所评估的特定系统的上下文中识别和排序威胁。在尝试回答这个问题时，威胁建模者拥有大量可用的数据源和技术。为便于说明，本备忘单将利用 STRIDE；然而，在实践中，可以与 STRIDE 并用或替代 STRIDE 的其他方法。

STRIDE 是一种成熟且流行的威胁建模技术和助记符，最初由微软员工开发。为了促进威胁识别，STRIDE 将威胁分为六个一般性提示，鼓励工程师系统地考虑这些一般性威胁如何在所评估的特定系统中实现。每个 STRIDE 威胁都可以被视为违反了理想的安全属性；这些类别和相关的理想属性如下：

威胁类别 违反 示例
Spoofing (欺骗) 真实性 攻击者窃取合法用户的认证令牌并冒充该用户。
Tampering (篡改) 完整性 攻击者滥用应用程序对数据库执行非预期的更新。
Repudiation (抵赖) 不可否认性 攻击者操纵日志以掩盖其行为。
Information Disclosure (信息泄露) 保密性 攻击者从包含用户账户信息的数据库中提取数据。
Denial of Service (拒绝服务) 可用性 攻击者通过多次失败的认证尝试将合法用户锁定在其账户之外。
Elevation of Privileges (权限提升) 授权 攻击者篡改 JWT 以更改其角色。

STRIDE 为回答“可能出现什么问题”提供了有价值的结构。它也是一种高度灵活的方法，并且入门无需复杂。最初可以使用头脑风暴、白板甚至游戏等简单技术。STRIDE 也被集成到流行的威胁建模工具中，例如OWASP 的 Threat Dragon 和微软的 Threat Modeling Tool。此外，作为一种相对高级的流程，STRIDE 与杀伤链或MITRE 的 ATT&CK 等更具战术性的方法很好地搭配（请参阅本文了解 STRIDE 和 ATT&CK 如何协同工作）。

识别出可能的威胁后，人们通常会对其进行排名。理论上，排名应基于已识别威胁的发生可能性及其影响的数学乘积。一个很可能发生并导致严重损害的威胁将比一个不太可能发生且仅具有中等影响的威胁优先级别高得多。然而，这两者都难以计算，并且它们忽略了修复问题所需的工作。一些人主张将其纳入单一的优先级划分中。

响应与缓解

在理解了系统和适用的威胁之后，现在是时候回答“我们打算如何应对？”这个问题了。之前识别出的每个威胁都必须有一个响应。威胁响应与风险响应相似，但并非完全相同。Adam Shostack 列出了以下响应：

  • 缓解：采取行动降低威胁发生的可能性。
  • 消除：简单地移除导致威胁的功能或组件。
  • 转移：将责任转移给另一个实体，例如客户。
  • 接受：不缓解、消除或转移风险，因为考虑到业务需求或限制，上述选项均不可接受。

如果决定缓解某个威胁，则必须制定缓解策略并将其记录为需求。根据系统的复杂性、所识别威胁的性质以及用于识别威胁的过程（STRIDE 或其他方法），缓解响应可以应用于类别或单个威胁级别。在前者的情况下，缓解将适用于该类别中的所有威胁。缓解策略必须是可操作的，而不是假设的；它们必须是实际可以构建到正在开发的系统中的东西。尽管缓解策略必须针对特定应用程序量身定制，但诸如OWASP 的 ASVS 和MITRE 的 CWE 列表等资源在制定这些响应时可以证明很有价值。

审查与验证

最后，是时候回答“我们做得足够好吗？”这个问题了。威胁模型必须由所有利益相关者审查，而不仅仅是开发或安全团队。需要关注的领域包括：

  • DFD（或类似模型）是否准确反映了系统？
  • 所有威胁都已识别了吗？
  • 对于每个已识别的威胁，是否已就响应策略达成一致？
  • 对于希望以缓解作为响应的已识别威胁，是否已制定将风险降低到可接受水平的缓解策略？
  • 威胁模型是否已正式文档化？威胁模型过程中的工件是否以“需要了解”的人员可以访问的方式存储？
  • 商定的缓解措施是否可以测试？威胁模型中的要求和建议的成功或失败是否可以衡量？

威胁建模与开发团队

挑战

威胁建模对开发团队来说可能具有挑战性，原因有几个关键点。首先，许多开发人员缺乏足够的安全领域知识和经验，这阻碍了他们有效使用方法和框架、识别和建模威胁的能力。如果没有适当的培训和对基本安全原则的理解，开发人员可能会忽视潜在威胁或错误评估其风险。

此外，威胁建模过程可能复杂且耗时。它需要系统的方法和深入的分析，这往往难以与紧张的日程和交付新功能的压力相协调。开发团队可能会感到缺乏工具和资源来支持这项任务，从而导致挫败感和气馁。

另一个挑战是组织内不同部门之间的沟通和协作。如果开发团队、安全团队和其他利益相关者之间缺乏有效的沟通，威胁建模可能不完整或方向错误。

应对挑战

在许多情况下，解决方案在于邀请安全团队成员参与威胁建模会议，这可以显著改善流程。安全专家带来关于潜在威胁的基本知识，这对于有效的识别、风险分析和缓解至关重要。他们的经验以及对网络犯罪分子使用的最新趋势和技术的理解，可以为开发团队的学习和能力发展提供关键洞察。这种联合会议不仅增强了开发人员的知识，还在组织内部建立了协作和相互支持的文化，从而形成了更全面的安全方法。

为了改变现状，组织应为其开发团队投资定期的 IT 安全培训。这些培训应由专家进行，并根据团队的具体需求量身定制。此外，实施简化和自动化威胁建模的流程和工具也是有益的。这些工具可以帮助识别和评估威胁，使过程更易于访问且更省时。

在整个组织中推广安全文化也很重要，将威胁建模视为软件开发生命周期（SDLC）不可或缺的一部分，而不是额外的负担。定期的审查会议和跨团队研讨会可以改善协作和沟通，从而形成更有效和全面的安全方法。通过这些行动，组织可以使威胁建模成为一个负担更少、效率更高的过程，为系统安全带来真正的益处。

参考资料

方法与技术

按字母顺序排列的技术列表

工具

一般参考