Back to Details

threat-modelling

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Threat Modelling (STRIDE / SDL)

威胁建模（STRIDE / SDL）

Threat modelling is a structured Microsoft Security Development Lifecycle (SDL) practice for identifying, communicating, and mitigating threats early in design - before code is written, and re-applied whenever the design materially changes.
威胁建模是Microsoft Security Development Lifecycle（SDL）中的一项结构化实践，用于在设计阶段（代码编写前）识别、沟通并缓解威胁，且每当设计发生重大变更时需重新开展。

When to use

适用场景

Designing a new system, significantly changing an existing one, evaluating an architecture for security, or running a formal security design review.
Do not use this skill for:
  • Org-wide security architecture or roadmap (use 
    security-architecture
    )
  • Runtime detection or incident response (use 
    sentinel
    / 
    defender-xdr
    )
  • Code-level vulnerability scanning (use SAST/DAST tooling)
设计新系统、大幅变更现有系统、评估架构安全性，或开展正式的安全设计评审时。
请勿将此技能用于：
  • 全组织范围的安全架构或路线规划（请使用
    security-architecture
    ）
  • 运行时检测或事件响应（请使用
    sentinel
    / 
    defender-xdr
    ）
  • 代码级漏洞扫描（请使用SAST/DAST工具）

STRIDE - the six categories at a glance

STRIDE：六大威胁类别概览

LetterThreatSecurity property it breaksTypical mitigation
SSpoofingAuthenticationMFA, mutual TLS, signed tokens
TTamperingIntegritySigning, hashing, write-protected stores
RRepudiationNon-repudiationAudit logging, signed transactions
IInformation disclosureConfidentialityEncryption (rest+transit), authorization
DDenial of serviceAvailabilityRate limiting, quotas, autoscale, WAF
EElevation of privilegeAuthorizationLeast privilege, input validation, sandboxing
Rule of thumb: walk each element of the data-flow diagram against all six STRIDE categories. Skipping categories because "they don't apply here" is the most common way real threats are missed.
字母威胁类型破坏的安全属性典型缓解措施
S身份欺骗（Spoofing）身份验证（Authentication）MFA、双向TLS、签名令牌
T篡改（Tampering）完整性（Integrity）签名、哈希、写保护存储
R抵赖（Repudiation）不可抵赖性（Non-repudiation）审计日志、签名交易
I信息泄露（Information disclosure）保密性（Confidentiality）加密（静态+传输）、授权机制
D拒绝服务（Denial of service）可用性（Availability）速率限制、配额、自动扩缩容、WAF
E权限提升（Elevation of privilege）授权（Authorization）最小权限原则、输入验证、沙箱隔离
经验法则： 针对数据流图中的每个元素，逐一对照全部六个STRIDE类别进行排查。因“此处不适用”而跳过类别，是遗漏真实威胁的最常见原因。

Approach

实施步骤

  1. Define scope and assumptions - State what is in scope, what is out, the trust model (who you trust to do what), and the assets being protected. A threat model without scope is an opinion. Verify: a one-page scope statement names assets, actors, in-scope components, and explicit out-of-scope items.
  2. Build the data-flow diagram (DFD) - Draw external entities, processes, data stores, data flows, and trust boundaries. Trust boundaries are where authority/data crosses between principals - that is where most threats live. Verify: every data flow crossing a trust boundary is highlighted; no boundary-crossing flow is missing.
  3. Enumerate threats with STRIDE per element - For each element/flow, walk through all six STRIDE categories. For each applicable threat, write a one-line description. Verify: every element has been evaluated against all six letters; you can show the coverage matrix.
  4. Rank threats by risk - Use DREAD or a simple high/medium/low based on likelihood and impact. Triage so the team works the top tier first. Verify: top 10 threat list is risk-ranked, not order-of-discovery.
  5. Map each threat to a concrete mitigation - Mitigation = a specific control (MFA, input validation, signing, encryption, rate limiting, least privilege) plus an owner and a target date. Abstract "we should secure that" is not a mitigation. Verify: every top-tier threat has a named mitigation, an owner, and an implementation target.
  6. Validate mitigations are implemented - During build, confirm each mitigation lands in code, configuration, or process. During review, test that the mitigation actually blocks the threat (negative test). Verify: mitigation tests exist in the test suite or in a security review checklist.
  7. Re-model on material change - Treat threat modelling as iterative. Every new trust boundary, new external integration, new data classification, or major refactor is a trigger to re-model the affected slice. Verify: the team has a written trigger list and the model is updated after the most recent trigger event.
  8. Use tooling where it helps - The Microsoft Threat Modeling Tool generates STRIDE threats per DFD element automatically. Threat-modelling cards / templates work well for workshops without tooling.
  1. 定义范围与假设 - 明确纳入范围的内容、排除的内容、信任模型（信任哪些主体执行哪些操作）以及需保护的资产。没有范围的威胁模型只是主观观点。 验证标准：一页篇幅的范围声明需明确资产、参与者、纳入范围的组件以及明确排除的项。
  2. 构建数据流图（DFD） - 绘制外部实体、流程、数据存储、数据流以及信任边界。信任边界是权限/数据在主体间传递的位置，也是大多数威胁存在的地方。 验证标准：所有跨越信任边界的数据流均已高亮显示；无遗漏的跨边界数据流。
  3. 按元素枚举STRIDE威胁 - 针对每个元素/数据流，逐一梳理全部六个STRIDE类别。对于每个适用的威胁，撰写一行描述。 验证标准：每个元素均已针对全部六个字母进行评估；可展示覆盖矩阵。
  4. 按风险等级排序威胁 - 使用DREAD模型或基于可能性与影响的简单高/中/低分级。进行优先级排序，确保团队先处理最高级别的威胁。 验证标准：前10位威胁列表按风险排序，而非发现顺序。
  5. 为每个威胁映射具体缓解措施 - 缓解措施需包含具体控制手段（MFA、输入验证、签名、加密、速率限制、最小权限）、负责人和目标日期。抽象的“我们应该加强此处安全”不构成缓解措施。 验证标准：每个顶级威胁均有明确的缓解措施、负责人和实施目标日期。
  6. 验证缓解措施已落地 - 在构建阶段，确认每个缓解措施已体现在代码、配置或流程中。在评审阶段，测试缓解措施是否确实能阻断威胁（负面测试）。 验证标准：测试套件或安全评审 checklist 中包含缓解措施测试项。
  7. 重大变更时重新建模 - 将威胁建模视为迭代过程。每当出现新的信任边界、新的外部集成、新的数据分类或重大重构时，需针对受影响的部分重新建模。 验证标准：团队有书面的触发事件列表，且模型已在最近一次触发事件后更新。
  8. 合理使用工具 - Microsoft Threat Modeling Tool可针对数据流图元素自动生成STRIDE威胁。在无工具的研讨会上，威胁建模卡片/模板也能发挥良好作用。

Guardrails

注意事项

  • Threat modelling is iterative - revisit each major design change, not once at project start. A model frozen at design time has no relationship to the shipped system.
  • Capture assumptions and out-of-scope items explicitly - undocumented assumptions are the next year's security incidents.
  • Tie threats to actionable mitigations with owners and dates, not abstract risks.
  • Walk all six STRIDE letters per element - skipping categories is the most common gap.
  • Threat modelling is not a substitute for code review, dependency scanning, or pen testing. It complements them by shaping what to test.
  • The output is the shared understanding, not the document. If the dev team cannot explain the top threats verbally, the model has not landed.
  • 威胁建模是迭代过程 - 需在每次重大设计变更时重新审视，而非仅在项目启动时开展一次。冻结在设计阶段的模型与最终交付的系统毫无关联。
  • 明确记录假设与排除项 - 未记录的假设会成为来年的安全事件隐患。
  • 将威胁与可落地的缓解措施绑定，明确负责人和日期，而非仅记录抽象风险。
  • 针对每个元素逐一梳理全部六个STRIDE类别 - 跳过类别是最常见的疏漏。
  • 威胁建模不能替代代码评审、依赖项扫描或渗透测试。它通过明确测试重点来补充这些工作。
  • 输出成果是共识理解，而非文档。如果开发团队无法口头解释顶级威胁，说明模型未真正落地。

Common anti-patterns

常见反模式

  • "We did a threat model at project kickoff" - and never updated it. The system being threat-modelled no longer exists.
  • A 200-threat spreadsheet with no ranking. Nothing gets fixed because everything looks equal. Triage is the deliverable.
  • STRIDE letters skipped because "they don't apply." Force the walk; document why a category genuinely does not apply rather than skipping silently.
  • Mitigation = "use TLS". Not a mitigation. Mitigation = TLS 1.2+ enforced on the gateway with cipher suite X, validated by test Y, owned by Z.
  • Threat model as a security-team artefact that engineering never reads. The dev team must own the model; security facilitates.
  • “我们在项目启动时做过威胁建模” - 但从未更新。当前威胁建模的系统早已不复存在。
  • 包含200项威胁的电子表格，未做优先级排序。所有威胁看起来都同等重要，导致没有任何问题得到解决。优先级排序才是核心交付物。
  • 因“不适用”而跳过STRIDE类别。强制完成逐一排查；若某个类别确实不适用，需记录原因，而非默默跳过。
  • 缓解措施仅写“使用TLS”。这不是有效的缓解措施。有效的缓解措施应是：网关强制使用TLS 1.2+，采用密码套件X，通过测试Y验证，由Z负责。
  • 威胁建模成为安全团队专属文档，开发团队从未阅读。开发团队必须拥有模型所有权，安全团队仅提供协助。

Example prompts

示例提示词

  • Run a STRIDE threat model with a data flow diagram and trust boundaries.
  • Use the Microsoft Threat Modeling Tool for a design review.
  • How do I identify threats and map mitigations for a new system?
  • Conduct an SDL threat modelling session.
  • What does the E in STRIDE cover and how is it mitigated?
  • Run a STRIDE threat model with a data flow diagram and trust boundaries.
  • Use the Microsoft Threat Modeling Tool for a design review.
  • How do I identify threats and map mitigations for a new system?
  • Conduct an SDL threat modelling session.
  • What does the E in STRIDE cover and how is it mitigated?

Microsoft Learn

Microsoft Learn 资源