Threat Modeling Cheat Sheet / 威胁建模速查表

Introduction / 介绍

Threat modeling is an important concept for modern application developers to understand. The goal of this cheatsheet is to provide a concise, but actionable, reference for both those new to threat modeling and those seeking a refresher. The OWASP Threat Modeling project provides further information on various aspects of threat modeling.

威胁建模是现代应用开发者理解的重要概念。本速查表的目的是为那些对威胁建模新手和寻求复习的人提供简洁但实用的参考。OWASP 威胁建模项目提供了关于威胁建模各个方面更详细的信息。

Overview / 概述

In the context of application security, threat modeling is a structured, repeatable process used to gain actionable insights into the security characteristics of a particular system. It involves modeling a system from a security perspective, identifying applicable threats based on this model, and determining responses to these threats. Threat modeling analyzes a system from an adversarial perspective, focusing on ways in which an attacker can exploit a system.

在应用安全领域，威胁建模是一种结构化、可重复的过程，用于深入了解特定系统的安全特性。它涉及从安全角度对系统进行建模，根据此模型识别适用的威胁，并确定对这些威胁的响应。威胁建模从对抗性角度分析系统，关注攻击者可能利用系统的方式。

Threat modeling is ideally performed early in the SDLC, such as during the design phase. Moreover, it is not something that is performed once and never again. A threat model is something that should be maintained, updated and refined alongside the system. Ideally, threat modeling should be integrated seamlessly into a team's normal SDLC process; it should be treated as a standard and necessary step in the process, not an add-on.

威胁建模最好在软件开发生命周期（SDLC）的早期阶段进行，例如在设计阶段。此外，它不是一次性的，而是一直需要维护、更新和改进的系统的一部分。理想情况下，威胁建模应无缝集成到团队的正常SDLC流程中；它应被视为过程中的一个标准和必要步骤，而不是附加项。

According to the Threat Modeling Manifesto, the threat modeling process should answer the following four questions:

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

1. What are we working on?
   中文：我们在做什么？
2. What can go wrong?
   中文：可能出什么问题？
3. What are we going to do about it?
   中文：我们将如何处理？
4. Did we do a good enough job?
   中文：我们做得够好吗？

These four questions will act as the foundation for the four major phases described below.

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

Advantages / 优点

Before turning to an overview of the process, it may be worth addressing the question: why threat model? Why bother adding more work to the development process? What are the benefits? The following section will briefly outline some answers to these questions.

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

Identify Risks Early On / 尽早识别风险

Threat modeling seeks to identify potential security issues during the design phase. This allows security to be "built-into" a system rather than "bolted-on". This is far more efficient than having to identify and resolve security flaws after a system is in production.

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

Increased Security Awareness / 提高安全意识

Proper threat modeling requires participants to think creatively and critically about the security and threat landscape of a specific application. It challenges individuals to "think like an attacker" and apply general security knowledge to a specific context. Threat modeling is also typically a team effort with members being encouraged to share ideas and provide feedback on others. Overall, threat modeling can prove to be a highly educational activity that benefits participants.

适当的威胁建模要求参与者创造性地、批判性地思考特定应用程序的安全和威胁环境。它挑战个人“像攻击者一样思考”，并将一般安全知识应用于特定情境。威胁建模通常是一个团队努力的过程，鼓励成员分享想法并对他人提供反馈。总的来说，威胁建模可以证明是一个高度有益的教育活动，对参与者有益。

Improved Visibility of Target of Evaluation (TOE) / 提高评估目标（TOE）的可见性

Threat modeling requires a deep understanding of the system being evaluated. To properly threat model, one must understand data flows, trust boundaries, and other characteristics of the system. Thus improved visibility into a system and its interactions is one advantage of threat modeling.

威胁建模需要对被评估的系统有深入的了解。为了正确地进行威胁建模，必须了解数据流、信任边界和其他系统特征。因此，提高对系统和其交互的可见性是威胁建模的一个优势。

Addressing Each Question / 针对每个问题

There is no universally accepted industry standard for the threat modeling process, no "right" answer for every use case. However, despite this diversity, most approaches do include the processes of system modeling, threat identification, and risk response in some form. Inspired by these commonalities and guided by the four key questions of threat modeling discussed above, this cheatsheet will break the threat modeling down into four basic steps: application decomposition, threat identification and ranking, mitigations, and review and validation. There are processes that are less aligned to this, including the Process for Attack Simulation and Threat Analysis (PASTA) and Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE), each of which has passionate advocates.

没有普遍接受的威胁建模流程行业标准，也没有适用于每个用例的“正确”答案。然而，尽管存在这种多样性，大多数方法都以某种形式包括系统建模、威胁识别和风险响应的过程。受这些共同点启发，并遵循上述讨论的威胁建模四个关键问题，这份速查表将威胁建模分解为四个基本步骤：应用分解、威胁识别和排序、缓解措施以及审查和验证。还有一些流程与这一流程不太一致，包括攻击模拟和威胁分析流程（PASTA）以及操作关键威胁、资产和漏洞评估（OCTAVE），每个流程都有热情的倡导者。

System Modeling / 系统建模

The step of system modeling seeks to answer the question "what are we working on"? Without understanding a system, one cannot truly understand what threats are most applicable to it; thus, this step provides a critical foundation for subsequent activities. Although different techniques may be used in this first step of threat modeling, data flow diagrams (DFDs) are arguably the most common approach.

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

DFDs visually model a system, its data flows, and interactions with external entities. Create them using a diagramming tool or a whiteboard, and save them in a form the team can update. For complex systems, use a high-level overview alongside more detailed diagrams of individual components.

DFDs以图形方式模拟系统、其数据流以及与外部实体的交互。可以使用绘图工具或白板创建它们，并以团队可以更新的形式保存。对于复杂的系统，可以使用高级概述和更详细的单个组件图。

Regardless of how a DFD or comparable model is generated, it is important that the solution provides a clear view of trust boundaries, data flows, data stores, processes, and the external entities which may interact with the system. These often represent possible attack points and provide crucial input for the subsequent steps.

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

Another approach to Data Flow Diagrams (DFD) could be the brainstorming technique, which is an effective method for generating ideas and discovering the project's domain. Applying brainstorming in this context can bring numerous benefits, such as increased team engagement, unification of knowledge and terminology, a shared understanding of the domain, and quick identification of key processes and dependencies. One of the main arguments for using brainstorming is its flexibility and adaptability to almost any scenario, including business logic. Additionally, this technique is particularly useful when less technical individuals participate in the session, as it eliminates barriers related to understanding and applying the components of DFD models and their correctness.

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

Brainstorming engages all participants, fostering better communication and mutual understanding of issues. Every team member has the opportunity to contribute, which increases the sense of responsibility and involvement. During a brainstorming session, participants can collaboratively define and agree on key terms and concepts, leading to a unified language used in the project. This is especially important in complex projects where different teams might have different approaches to terminology. Due to the dynamic nature of brainstorming, the team can quickly identify key business processes and their interrelations.

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

Integrating the results of brainstorming with formal modeling techniques can lead to a better understanding of the domain and more effective system design.

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

Cloud Threat Modeling / 云威胁建模

Most modern systems are cloud-native or hybrid. Traditional threat modeling techniques (like STRIDE or DFDs) often need adaptation for cloud architectures, which introduce:

大多数现代系统都是云原生或混合型。传统的威胁建模技术（如STRIDE或DFDs）通常需要适应云架构，这引入了：

• Shared responsibility models
  中文：共享责任模型
• Managed services and APIs
  中文：托管服务和API
• Multi-tenant and identity federation considerations
  中文：多租户和身份联合考虑
• Dynamic infrastructure (IaC, serverless, containers)
  中文：动态基础设施（IaC、无服务器、容器）

Cloud-native systems introduce unique considerations for threat modeling due to their distributed, service-oriented nature and shared responsibility model. In this context, the threat modeling process should account for:

由于云原生系统的分布式、面向服务的特性和共享责任模型，它们在威胁建模方面引入了独特的考虑因素。在这种情况下，威胁建模过程应考虑：

• Cloud architecture components: virtual networks, IAM roles, managed services, and storage buckets.
  中文：云架构组件： 虚拟网络、IAM 角色、托管服务和存储桶。
• Shared responsibility: understanding which security controls are managed by the provider vs. the customer.
  中文：共享责任： 理解哪些安全控制由提供商管理，哪些由客户管理。
• Dynamic environments: container orchestration, serverless functions, and ephemeral infrastructure.
  中文：动态环境： 容器编排、无服务器函数和短暂基础设施。
• Compliance and data residency: ensuring that workloads meet jurisdictional and privacy requirements.
  中文：合规性和数据驻留： 确保工作负载符合司法管辖权和隐私要求。

Threat Identification / 威胁识别

After the system has been modeled, it is now time to address the question of "what can go wrong?". This question must be explored with the inputs from the first step in mind; that is, it should focus on identifying and ranking threats within the context of the specific system being evaluated. In attempting to answer this question, threat modelers have a wealth of data sources and techniques at their disposal. For illustration purposes, this cheatsheet will leverage STRIDE; however, in practice, other approaches may be used alongside or instead of STRIDE.

在系统建模完成后，现在需要解决的问题是“可能出什么问题？”。这个问题必须考虑到第一步的输入；也就是说，它应该专注于在特定系统评估的上下文中识别和排序威胁。在尝试回答这个问题时，威胁建模者拥有大量数据来源和技术可供使用。为了说明目的，这份速查表将利用 STRIDE；然而，在实际操作中，可能还会使用其他方法与 STRIDE 一起使用或代替 STRIDE。

STRIDE is a mature and popular threat modeling technique and mnemonic originally developed by Microsoft employees. To facilitate threat identification, STRIDE groups threats into one of six general prompts and engineers are encouraged to systematically consider how these general threats may materialize within the context of the specific system being evaluated. Each STRIDE threat may be considered a violation of a desirable security attribute; the categories and associated desirable attributes are as follows:

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

Threat Category / 威胁类别	Violates / 违反	Examples / 示例
Spoofing	Authentication 身份验证	An attacker steals the authentication token of a legitimate user and uses it to impersonate the user. 攻击者窃取了合法用户的认证令牌并使用它来冒充该用户。
Tampering 篡改	Integrity 完整性	An attacker abuses the application to perform unintended updates to a database. 攻击者滥用应用程序对数据库执行未预期的更新。
Repudiation 否认	Accounting 会计	An attacker manipulates logs to cover their actions. 攻击者操纵日志以掩盖其行为。
Information Disclosure 信息泄露	Confidentiality 机密性	An attacker extracts data from a database containing user account info. 攻击者从包含用户账户信息的数据库中提取数据。
Denial of Service DoS攻击	Availability 可用性	An attacker locks a legitimate user out of their account by performing many failed authentication attempts. 攻击者通过执行多次失败的认证尝试，将合法用户锁定在他们的账户之外。
Elevation of Privileges Elevated Privileges攻击	Authorization 授权	An attacker tampers with a JWT to change their role. 攻击者篡改JWT以更改其角色。

Use STRIDE's six categories as prompts while reviewing the system model. Brainstorm threats with the team and record which components, data flows, or trust boundaries they affect.

在审查系统模型时，使用STRIDE的六个类别作为提示。与团队一起头脑风暴威胁，并记录它们影响的组件、数据流或信任边界。

After possible threats have been identified, people will frequently rank them. In theory, ranking should be based on the mathematical product of an identified threat's likelihood and its impact. A threat that is likely to occur and result in serious damage would be prioritized much higher than one that is unlikely to occur and would only have a moderate impact. However, these both can be challenging to calculate, and they ignore the work to fix a problem. Some advocate for including that in a single prioritization.

在识别可能的威胁后，人们通常会对其进行排序。理论上，排序应基于已识别威胁的可能性与其影响的数学乘积。一个可能发生并造成严重损害的威胁应比一个不太可能发生且只会造成适度影响的威胁优先级高得多。然而，这两者都很难计算，并且忽略了解决问题的工作。有些人主张将它们包含在单一的优先级排序中。

Choosing a Threat Modeling Technique / 选择威胁建模技术

Start with STRIDE for a technical design, and select another technique when the scope requires a different view. The Software Engineering Institute comparison of threat modeling methods explains that methods focus on different concerns and may be combined.

从STRIDE开始进行技术设计，当范围需要不同的视角时，选择另一种技术。软件工程研究所对威胁建模方法的比较解释说，方法关注不同的关注点，并且可以组合使用。

When the team needs to analyze / 当团队需要分析时	Consider / 考虑	How to use it / 如何使用它
Security threats in a technical design 技术设计中的安全威胁	STRIDE	Apply the six threat categories above to components, data flows, and trust boundaries. 将上述六个威胁类别应用于组件、数据流和信任边界。
A high-value attacker goal or multi-step attack 高价值攻击者的目标或多步骤攻击	Attack trees 攻击树	Start with the attacker's goal and decompose the alternative or required paths to reach it. 从攻击者的目标开始，分解达到该目标的不同或必需路径。
Abuse of a valid workflow or business rule 滥用有效的流程或业务规则	Misuse or abuse cases 误用或滥用案例	Explore actions performed out of order, repeatedly, concurrently, or for an unintended outcome. 探索出序、重复、并发执行或非预期结果执行的动作。
Privacy properties and harms 隐私属性和危害	LINDDUN (Linking, Identifying, Non-repudiation, Detecting, Data disclosure, Unawareness and Unintervenability, Non-compliance) LINDDUN (链接、识别、不可否认性、检测、数据泄露、无意识和无干预性、不合规)	Apply privacy-specific prompts that are not fully represented by STRIDE's security properties. 应用特定的隐私提示，这些提示不能完全由 STRIDE 的安全属性所代表。
Application threats with business impact 具有业务影响的应用威胁	PASTA	Connect business objectives and technical requirements to application threats. 将业务目标和技术需求与应用威胁相连接。
Organization-wide risk to critical assets 对关键资产的组织风险	OCTAVE	Assess organizational risk and plan a security strategy for critical assets. 评估组织风险并制定针对关键资产的安全策略。
Application and operational threats across many teams 跨多个团队的应用和操作威胁	VAST (Visual, Agile, and Simple Threat Modeling) VAST（视觉、敏捷和简单威胁建模）	Maintain separate application and operational threat models within development workflows. 在开发工作流程中维护独立的应用和操作威胁模型。

Do not add techniques only to make the model appear comprehensive. State why each technique fits the scope and record any concerns it does not address.

不要仅仅为了使模型看起来全面而添加技术。说明为什么每种技术适合范围，并记录它未解决的问题。

Response and Mitigations / 响应和缓解

Equipped with an understanding of both the system and applicable threats, it is now time to answer "what are we going to do about it"? Each threat identified earlier must have a response. Threat responses are similar, but not identical, to risk responses. Adam Shostack lists the following responses:

在了解系统和适用威胁的基础上，现在是时候回答“我们将如何处理它”了？每个之前识别出的威胁都必须有一个响应。威胁响应与风险响应相似，但并不相同。Adam Shostack列出了以下响应：

• Mitigate: Take action to reduce the likelihood that the threat will materialize.
• Eliminate: Simply remove the feature or component that is causing the threat.
• Transfer: Allocate contractual or financial responsibility to another party. Risk transfer does not itself reduce the likelihood or harmful consequences of an event; document who owns the remaining controls and residual risk.
  中文：转让：将合同或财务责任分配给另一方。风险转让本身并不降低事件发生的可能性或有害后果；记录剩余控制权和残余风险的拥有者。
• Accept: Do not mitigate, eliminate, or transfer the risk because none of the above options are acceptable given business requirements or constraints.

Document each threat's response and turn agreed mitigations into actionable security requirements. Record how the team will implement each mitigation and why it accepts any remaining risk. Keep these decisions current as the system changes, as recommended by NIST SP 800-218, practice PW.1.2.

Review and Validation

Finally, it is time to answer the question "did we do a good enough job"? The threat model must be reviewed by all stakeholders, not just the development or security teams. Areas to focus on include:

• Does the DFD (or comparable) accurately reflect the system?
• Have all threats been identified?
• For each identified threat, has a response strategy been agreed upon?
  中文：对于每个已识别的威胁，是否已达成响应策略的共识？
• For identified threats for which mitigation is the desired response, have mitigation strategies been developed which reduce risk to an acceptable level?
  中文：对于希望采取缓解措施的已识别威胁，是否已开发出缓解策略，以将风险降低到可接受的水平？
• Has the threat model been formally documented? Are artifacts from the threat model process stored in such a way that it can be accessed by those with "need to know"?
  中文：威胁模型是否已正式记录？威胁模型过程中的工件是否以这种方式存储，以便“知悉必要者”可以访问？
• Can the agreed upon mitigations be tested? Can success or failure of the requirements and recommendations from the threat model be measured?
  中文：达成的缓解措施是否可以测试？能否衡量威胁模型中的要求和推荐的成功或失败？

Threat Modeling and the Development Team / 威胁模型与开发团队

Challenges / 挑战

Threat modeling can be challenging for development teams for several key reasons. Firstly, many developers lack sufficient knowledge and experience in the field of security, which hinders their ability to effectively use methodologies and frameworks, identify, and model threats. Without proper training and understanding of basic security principles, developers may overlook potential threats or incorrectly assess their risks.

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

Additionally, the threat modeling process can be complex and time-consuming. It requires a systematic approach and in-depth analysis, which is often difficult to reconcile with tight schedules and the pressure to deliver new functionalities. Development teams may feel a lack of tools and resources to support them in this task, leading to frustration and discouragement.

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

Another challenge is the communication and collaboration between different departments within the organization. Without effective communication between development teams, security teams, and other stakeholders, threat modeling can be incomplete or misdirected.

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

Addressing the Challenges / 应对挑战

In many cases, the solution lies in inviting members of the security teams to threat modeling sessions, which can significantly improve the process. Security specialists bring essential knowledge about potential threats that is crucial for effective identification, risk analysis, and mitigation. Their experience and understanding of the latest trends and techniques used by cybercriminals can provide key insights for learning and developing the competencies of development teams. Such joint sessions not only enhance developers' knowledge but also build a culture of collaboration and mutual support within the organization, leading to a more comprehensive approach to security.

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

To change the current situation, organizations should invest in regular IT security training for their development teams. These training sessions should be conducted by experts and tailored to the specific needs of the team. Additionally, it is beneficial to implement processes and tools that simplify and automate threat modeling. These tools can help in identifying and assessing threats, making the process more accessible and less time-consuming.

为了改变当前状况，组织应为其开发团队投资定期的IT安全培训。这些培训应由专家进行，并针对团队的具体需求定制。此外，实施简化和自动化威胁建模的流程和工具也是有益的。这些工具可以帮助识别和评估威胁，使流程更加便捷和节省时间。

It is also important to promote a culture of security throughout the organization, where threat modeling is seen as an integral part of the Software Development Life Cycle (SDLC), rather than an additional burden. Regular review sessions and cross-team workshops can improve collaboration and communication, leading to a more effective and comprehensive approach to security. Through these actions, organizations can make threat modeling a less burdensome and more efficient process, bringing real benefits to the security of their systems.

在组织内部推广安全文化也很重要，将威胁建模视为软件开发生命周期（SDLC）的组成部分，而不是额外的负担。定期的审查会议和跨团队研讨会可以提高协作和沟通，从而带来更有效和全面的网络安全方法。通过这些行动，组织可以使威胁建模变得不那么繁重，更加高效，为系统安全带来实际效益。

References / 参考

• Threat Modeling Manifesto) （威胁建模宣言）
• SEI: Threat Modeling — A Summary of Available Methods) （SEI：威胁建模 - 可用方法的概述）
• NIST SP 800-218: Secure Software Development Framework) （NIST SP 800-218：安全软件开发框架）