STRIDE 威胁建模

• STRIDE 六类威胁的英文全称与含义
• 每类威胁对应的安全属性与典型场景
• 六类威胁与 CIA 三元组等安全目标的关系

STRIDE 是 Microsoft 提出的威胁分类框架：Spoofing（欺骗/假冒）指攻击者伪装成他人或系统以绕过身份验证，对应身份认证属性；Tampering（篡改）指修改数据或代码，对应完整性；Repudiation（抵赖）指否认做过某操作，对应不可否认性；Information Disclosure（信息泄露）指未授权访问敏感数据，对应机密性；Denial of Service（拒绝服务）指资源耗尽导致服务不可用，对应可用性；Elevation of Privilege（提权）指从未授权权限提升到更高权限，对应授权。六类威胁共同覆盖了安全的核心目标，是 STRIDE 建模时逐一对数据流元素进行威胁枚举的基础目录。

STRIDE 的价值在于把抽象的"安全目标"转化为可逐一检查的威胁目录，使建模者不会遗漏某一类威胁。它偏重"技术视角"，更适合逐元素（进程、数据流、数据存储、外部实体）枚举，且每类威胁往往对应明确的缓解措施。

• 威胁、漏洞、攻击三者的定义与层级关系
• STRIDE 建模的出发点（威胁而非漏洞/攻击）
• 避免三者混用的工程实践

威胁是"可能发生的坏事情"（潜在破坏意图与能力），漏洞是"系统本身存在的弱点/缺陷"，攻击是"利用漏洞实际实施威胁的行为"。三者的关系是：威胁作用于系统，通过漏洞被利用，形成攻击。STRIDE 建模应从"威胁"这一层出发——即先假设"系统若存在某类弱点，可能遭受何种威胁"，而非直接枚举具体漏洞或攻击路径。这样做的原因是威胁是稳定的、可分类的（STRIDE 目录），而漏洞和攻击是动态演进的，如果从漏洞出发建模容易陷入"已知漏洞清单"的穷举，遗漏未知威胁。

从威胁层出发建立的是"意图-能力-可能后果"的抽象模型，再推导出需要哪些缓解措施，从而在需求阶段就防御潜在漏洞；而从漏洞/攻击出发往往是事后响应。实践中，威胁建模产出"威胁清单"，漏洞管理产出"漏洞清单"，两者通过缓解措施和测试用例关联，避免混用。

• STRIDE 的威胁分类与 ATT&CK 的战术层面的对应关系
• ATT&CK 的战术（为什么）与技术（怎么做）层级
• 两者互补使用的方式

STRIDE 是"威胁分类"框架（威胁是什么），MITRE ATT&CK 是"攻击行为知识库"，按战术（tactics，描述攻击目标/为什么攻击）与技术（techniques，描述具体怎么做）组织。两者存在对应关系：例如 STRIDE 的 Elevation of Privilege 对应 ATT&CK 的 Privilege Escalation 战术，Denial of Service 对应 Impact/Resource Hijacking 战术，Information Disclosure 对应 Collection/Exfiltration 战术。STRIDE 帮助建模者提出"可能存在哪类威胁"，ATT&CK 帮助回答"攻击者具体怎么做"，使威胁模型能落地为可检测、可测试的具体技术序列。

两者互补：STRIDE 偏"设计前"的预测性分析，ATT&CK 偏"已发生/已知"的实证性知识。实践中常用 STRIDE 生成威胁清单，再用 ATT&CK 技术项验证威胁的可达性并生成检测与测试用例，提升威胁建模的实战相关性。

• 架构评审与威胁建模的流程结合点
• 威胁建模作为评审的输入/输出
• 在架构决策阶段前置安全分析

STRIDE 应作为架构评审的组成部分而非独立活动。在架构评审时，先评审数据流图（DFD）与信任边界，然后对每个 DFD 元素逐类应用 STRIDE 枚举威胁，将产生的威胁清单与缓解措施作为评审结论的一部分，并纳入安全需求。这样安全分析前置到架构决策阶段，避免"先设计后补安全"。

集成关键是时序与角色：架构评审中由架构师主导、安全工程师参与威胁枚举，评审结论同时涵盖功能与非功能（安全）需求。威胁建模产出（威胁清单、缓解措施、追踪项）作为评审输出物，保证安全决策可追溯。

• 轻量级建模的四个核心问题
• 相比完整 STRIDE 的取舍
• 在敏捷环境的适用性

轻量级 4 步快速建模通过四个问题快速覆盖威胁面：1) 系统在做什么？2) 系统里有谁/什么？3) 系统信任什么？4) 系统来自哪里、数据流向哪里？通过这四个问题快速勾勒出系统的数据流、参与者、信任边界与外部依赖，再针对高风险区域应用 STRIDE 枚举威胁。相比完整 STRIDE（详尽的 DFD 逐元素分析），轻量级框架成本低、适合敏捷迭代，能在不花费大量工时的情况下发现主要威胁。

轻量级框架的取舍是"快而粗"，用于快速识别高价值威胁并决定是否深入，而非追求穷尽。它适合在 sprint 计划、功能设计评审时快速扫一遍，把完整建模留给高风险或复杂变更。

• 两款工具的功能与特点
• DFD 绘制与威胁生成方式
• 适用场景与选型

Microsoft Threat Modeling Tool 是微软官方工具，基于 DFD 绘制架构图，自动应用 STRIDE 生成威胁清单，集成在 Windows 平台，输出结构化威胁报告，适合微软技术栈与 DFD 建模。OWASP Threat Dragon 是开源、跨平台工具，支持 Web 与桌面版，支持 DFD 绘制与规则化威胁生成，模型文件可版本化（便于 CI 集成），适合开源与跨平台团队。两者都内建 STRIDE 目录与威胁库，帮助建模者自动枚举威胁。

选型关键看团队技术栈与集成需求：微软工具与 Windows/Azure 生态集成好；Threat Dragon 开源、可审计、文件可纳入版本控制，适合希望威胁模型随代码演进并做 CI 集成的团队。

• DFD 的四大元素：进程、数据存储、数据流、外部实体
• 各元素在 STRIDE 威胁枚举中的关注点
• 信任边界在 DFD 中的标注

DFD 由四类元素组成：外部实体（External Entity，如用户、外部系统，是数据来源或终点）、数据流（Data Flow，数据在实体与进程间流动）、进程（Process，对数据进行处理）、数据存储（Data Store，如数据库、文件）。STRIDE 对每个元素逐类应用威胁枚举：例如外部实体可能被 Spoofing（假冒），数据流可能被 Tampering（篡改），数据存储可能被 Information Disclosure（泄露），进程可能被 Elevation of Privilege（提权）。信任边界（trust boundary）用虚线标出，跨边界的每条数据流都需重点分析。

DFD 的价值是把抽象的"系统"转化为可逐元素分析的结构化模型，使 STRIDE 枚举有明确的附着点，避免遗漏。DFD 层级（context → level 0 → 分解）帮助控制复杂度。

• 信任边界的定义与识别方法
• 跨边界数据流的高风险属性
• 信任边界与安全控制的关系

信任边界是"信任级别改变的边界"，例如从不可信网络到可信内部系统的边界、从浏览器到 Web 服务器的边界、从应用层到数据库层的边界。识别方法：找到信任级别变化的点，如进出系统、进出网络分区、进程间权限切换处。跨边界的数据流应明确标注并在分析时重点对待，因为跨边界意味着数据穿过信任较低的区域，需要相应安全控制（认证、加密、校验、授权）。

信任边界是 DFD 中最重要的标注之一，因为 STRIDE 威胁往往集中在跨边界的数据流上。把每条跨边界数据流单独列出并逐类应用 STRIDE，可显著减少威胁遗漏。

• 可追踪性矩阵的构建方法
• 威胁清单→安全需求→测试用例的映射
• 追踪性的工程价值

可追踪性矩阵将威胁建模产出建立纵向与横向的关联：每条威胁（Threat）对应一条安全需求（Security Requirement）与若干缓解措施（Mitigation），每条需求再对应若干验证该缓解的测试用例（Test Case），形成"威胁→需求→缓解→测试"的追踪链。矩阵可用表格或工具（如需求管理工具、威胁建模平台）维护，每个元素有唯一 ID 便于引用。这保证每条已识别威胁都有对应的需求与测试落地，避免"只建模不落实"。

可追踪性矩阵的核心价值是闭环与可审计：发现威胁后必须落到需求与测试，否则威胁清单只是纸面产出。同时，当需求或测试变更时，可通过矩阵追溯受影响的威胁，评估安全影响。

• 威胁建模的触发条件（架构变更、新信任边界、新数据类别）
• 评审频率与持续化
• 一次性建模的弊端

威胁建模不是一次性活动，而应在以下触发条件下重新建模：重大架构变更、引入新的信任边界（如新增第三方集成、开放新服务）、引入新的数据类别（如新增敏感数据 PII/支付信息）、引入新技术栈或新攻击面。评审频率通常与发布节奏对齐（如每个发布前、每个 sprint 做增量建模），对高风险系统做定期评审。因为系统演进会不断引入新的攻击面，一次性建模会快速过时，威胁模型必须随代码与架构演进。

持续化威胁建模把安全分析嵌入开发周期，使威胁模型与系统同步演进。可将威胁建模纳入 Definition of Done、架构变更评审门禁，或作为 CI 流水线中触发式任务。

• 六类威胁对应的典型缓解措施
• 缓解措施与安全控制（认证、授权、加密、审计等）的对应
• 纵深防御的应用

每类威胁的典型对策：Spoofing 用强认证（多因素认证、证书、签名验证）防止假冒；Tampering 用完整性校验（哈希、数字签名、消息认证码 MAC）与防篡改机制；Repudiation 用审计日志、不可否认机制（数字签名、时间戳）记录操作；Information Disclosure 用加密（传输层 TLS、存储层加密）、访问控制与最小权限；Denial of Service 用限流、配额、冗余部署、负载均衡与 DDoS 防护；Elevation of Privilege 用最小权限原则、边界隔离、输入校验与权限分离（如沙箱）。

对策不是单一控制，而是纵深防御组合——例如防 Information Disclosure 既需要传输加密又需要访问控制与数据脱敏。缓解措施应被记录为安全需求并追踪到测试用例。

• 元素×威胁的矩阵遍历方法
• 避免遗漏与重复的技巧
• 结构化枚举的产出

系统化应用的关键是建立"元素×威胁"矩阵：对 DFD 中的每个元素（外部实体、数据流、进程、数据存储），分别询问 STRIDE 六类威胁是否适用，并记录适用性、理由与缓解措施。为避免遗漏，基线是逐元素逐类遍历，不跳过任何组合；为避免重复，对同一威胁若已在边界或父元素识别，则合并去重并标注关联。实践中可先对信任边界内的跨边界数据流全部过一遍，再处理边界内元素。

矩阵遍历把"头脑风暴式"的威胁识别转化为可重复的结构化流程，使产出可审计、可复现。工具（如 Threat Dragon、MSTMT）内建规则自动枚举，辅助人工补充。

• 风险 = 可能性 × 影响的排序方法
• DREAD 评分模型（Damage、Reproducibility、Exploitability、Affected users、Discoverability）
• 排序结果如何指导缓解投入

威胁清单产出后需排序以指导缓解投入。基本方法是用"可能性 × 影响"得到风险值排序；更细致的方法是用 DREAD 评分模型，对每条威胁按五个维度打分：Damage（损害程度）、Reproducibility（可复现性）、Exploitability（可利用性）、Affected users（受影响用户数）、Discoverability（可发现性），每项 1-10 分，求和或平均得到风险分数，按分数从高到低优先缓解。排序结果决定缓解投入顺序：高风险优先修复并纳入当前迭代，低风险可接受或记录。

排序解决"安全资源有限"的核心问题——不能对每条威胁同等投入。DREAD 的局限是主观、依赖评分者经验，因此常与 CVSS/EPSS 等客观数据结合，并让多人独立评分取均值降低偏差。

• 攻击树的结构与用途
• STRIDE 识别威胁、攻击树建模攻击路径的互补
• 结合使用的流程

STRIDE 用于识别"存在哪类威胁"，攻击树用于对单个威胁深入建模"攻击者如何达成该威胁的多种路径"。攻击树以攻击目标为根节点，攻击步骤为子节点，用 AND/OR 关系表示路径组合，帮助识别攻击的多种达成方式与最小攻击成本。协同方式：先用 STRIDE 枚举威胁分类，对高风险威胁构建攻击树，验证威胁的可达性与攻击面，进而设计对应的检测与缓解。

STRIDE 提供广度（覆盖所有威胁类别），攻击树提供深度（深入某威胁的路径）。两者结合使威胁建模既有分类覆盖又有具体攻击路径分析，特别适合验证威胁是否真实可达。

• 滥用用例的定义与用途
• 与 STRIDE 的互补关系
• 结合使用的流程

滥用用例（abuse case）是逆用系统用例的建模方法，从攻击者视角描述系统被恶意使用时的行为场景，常与正常的 use case 配对。STRIDE 提供威胁分类，滥用用例提供"攻击者如何与系统交互"的行为场景。协同方式：对每个高风险功能，以正常用例为基线逆向设计滥用用例（攻击者如何绕过、滥用该功能），再结合 STRIDE 归类威胁，生成对应的安全需求与测试用例。

滥用用例偏"行为/场景"视角，STRIDE 偏"分类/结构"视角，两者互补。滥用用例特别适合功能层面的威胁分析，能生成黑盒测试用例。

• 微服务集群中的信任边界与东西向流量
• 服务间通信的威胁与缓解
• 服务网格对信任建模的支持

在微服务架构中，服务间通信（东西向流量）是主要攻击面，信任边界应画在各服务之间以及服务与外部网关之间。STRIDE 建模时重点分析：服务间认证（Spoofing，防止服务 A 冒充服务 B）、服务间数据完整性（Tampering）、服务间通信加密（Information Disclosure）、服务间配额与熔断（DoS）、提权（Elevation of Privilege，如横向移动）。缓解常用服务网格（如 Istio）的 mTLS、RBAC、授权策略与限流实现。

微服务的信任模型往往是"零信任"——默认不信任任何服务，需显式认证与授权。信任边界从系统边界细化到服务边界，威胁建模粒度随之细化。

• 威胁缓解项作为 backlog 条目的落地
• 状态跟踪与验收
• 闭环管理流程

将威胁建模产生的缓解措施转化为 backlog 中的安全任务（如"为服务间通信启用 mTLS"），每个任务带威胁 ID、优先级、验收标准与负责人。在迭代中实现后用测试用例验证缓解有效性，关闭任务并更新状态。通过定期评审未关闭的缓解项，保证所有高优先级威胁都有缓解且被验证，形成"发现威胁→缓解→验证→关闭"的闭环。

闭环的关键是让威胁缓解项与其他开发任务同流程管理（同一 backlog、同一验收标准），避免安全任务被边缘化。可追踪性矩阵与状态看板结合，支撑安全审计。

• 威胁建模的标准步骤（DFD → 识别威胁 → 排序 → 缓解）
• 各步骤的输入输出
• 流程的迭代性

威胁建模的标准流程：1) 确定分析范围与资产；2) 绘制数据流图（DFD），标注进程、数据存储、数据流、外部实体与信任边界；3) 对 DFD 每个元素逐类应用 STRIDE 识别威胁，得到威胁清单；4) 对威胁排序（风险/DREAD）；5) 为高优先级威胁设计缓解措施并转化为安全需求；6) 验证缓解有效性并纳入测试。流程可迭代，随架构变更重跑。

该流程的关键是"结构化输入→结构化输出"：DFD 是结构化输入，威胁清单是结构化输出，中间用 STRIDE 目录保证遍历完整。流程保证可复现、可审计。

• 威胁建模与设计评审的集成时机
• 评审中威胁建模的产出
• 组织保障

威胁建模应作为设计评审的固定环节，在设计评审时对架构方案进行 DFD 绘制与 STRIDE 分析，产生威胁清单与安全需求，作为设计评审的通过条件之一。关键是让威胁建模成为评审流程的一部分而非可选附加项，并明确安全工程师在评审中的角色与责任。

结合设计评审让安全前置到设计阶段，成本最低、效果最好。可把威胁建模纳入评审检查单、Definition of Done，并设安全评审人做门禁。

• STRIDE 的盲区（隐私、业务逻辑）
• LINDDUN 隐私威胁建模框架
• 补充建模的方法

STRIDE 偏重"安全"（保密、完整、可用、认证、授权），对隐私威胁（数据最小化、不可链接性、数据主体权利）与业务逻辑类威胁（如利用规则漏洞、逻辑缺陷）覆盖不足。LINDDUN 是专门针对隐私威胁的建模框架，涵盖 Linking、Identifiability、Non-repudiation、Detectability、Disclosure of info、Unawareness、Non-compliance 等隐私威胁。业务逻辑类威胁可结合滥用用例、专项逻辑评审补充。实践中用 STRIDE 做安全，用 LINDDUN 做隐私，用滥用用例补业务逻辑，形成完整威胁覆盖。

单一框架无法覆盖所有威胁类型，需要多框架组合。对于涉及个人数据（PII/GDPR）的系统，隐私建模是合规必需，LINDDUN 使隐私分析系统化。