3、威胁场景建模：STRIDE方法论详解、威胁场景的构建步骤、我在项目中常用的威胁建模技巧。
威胁建模，说白了就是站在攻击者的角度想问题。你得先知道坏人会怎么下手，才能把门锁好。STRIDE 是我最常用的方法论，没有之一。它把威胁分成了六类，每一类都对应一个具体的攻击目标。
3.1 STRIDE 方法论详解
STRIDE 是微软提出来的，名字来自六种威胁类型的首字母。我习惯把它贴在工位上，每次做 TARA 都过一遍，防止漏项。
| 威胁类型 | 英文 | 攻击目标 | 我遇到过的真实案例 |
|---|---|---|---|
| S - 欺骗 | Spoofing | 身份认证 | 伪造 OBD 诊断仪，冒充合法工具刷写 ECU |
| T - 篡改 | Tampering | 数据完整性 | 中间人篡改 CAN 总线上的车速信号 |
| R - 抵赖 | Repudiation | 不可否认性 | 攻击者否认发送过恶意远程解锁指令 |
| I - 信息泄露 | Information Disclosure | 机密性 | 通过调试接口 dump 出车机内的用户隐私数据 |
| D - 拒绝服务 | Denial of Service | 可用性 | 向车载以太网发送大量垃圾报文，导致 ADAS 系统宕机 |
| E - 权限提升 | Elevation of Privilege | 授权 | 从 Guest 账户提权到 Root，刷写非原厂固件 |
我的经验： 别把 STRIDE 当成填空题。每个威胁类型都要结合具体的资产和场景去推演。比如「篡改」，你要想清楚是篡改了什么数据？在哪个通信链路上？篡改后对车辆安全有什么影响？
3.2 威胁场景的构建步骤
光知道 STRIDE 还不够，你得会用它构建威胁场景。我一般分四步走，每一步都有明确的产出物。
- 第一步：画数据流图（DFD）
把系统拆成进程、数据存储、外部实体和数据流。别画太细，粒度到 ECU 级别就够了。我见过有人把每个函数都画出来，结果图比代码还长，根本没法分析。 - 第二步：逐元素应用 STRIDE
对 DFD 里的每个元素，挨个问「这个元素能不能被欺骗？能不能被篡改？」。比如对「外部实体 - 手机 App」，重点看 Spoofing 和 Tampering。 - 第三步：描述威胁场景
用「攻击者 + 攻击入口 + 攻击方法 + 攻击目标」的句式写清楚。举个例子：「攻击者通过蓝牙接口，利用未加密的配对请求，注入恶意诊断会话，最终篡改网关路由表。」 - 第四步：记录到 TARA 工作表
每个威胁场景都要有编号、描述、STRIDE 分类、影响等级和可行性等级。这是后面做风险评估的基础。
小技巧： 我习惯在 DFD 上用不同颜色标注 STRIDE 类型。红色代表 Spoofing，蓝色代表 Tampering，一眼就能看出哪个区域风险最集中。
3.3 我在项目中常用的威胁建模技巧
做了十几个项目，踩过不少坑。下面这几个技巧，是我觉得最实用的。
- 技巧一：从攻击面入手，别从资产入手
很多人上来就列资产，然后对着资产想威胁。我更喜欢先找攻击面——物理接口、无线接口、调试接口、云端接口。找到入口，再往里推演。这样效率高，而且不容易漏。 - 技巧二：用「攻击树」辅助 STRIDE
当 STRIDE 分析出一个威胁场景后，我会画一棵攻击树，把攻击路径拆成 OR 和 AND 节点。比如「篡改 OTA 升级包」这个场景，攻击路径可以是「破解签名」OR「劫持下载通道」OR「物理替换存储芯片」。攻击树能帮你找到最薄弱的环节。 - 技巧三：区分「可能」和「可行」
做威胁建模时，很容易把「理论上可能」当成「实际可行」。我曾经犯过这个错，把「通过量子计算机破解 RSA-2048」写进了威胁场景，结果被评审专家怼了。记住，威胁场景要基于攻击者的实际能力、成本和动机来构建。
避坑指南： 我曾经在一个项目里，把 DFD 画得太细，结果 STRIDE 分析做了两个月还没做完。后来我学乖了，先画 Level 0 的 DFD，只包含主要 ECU 和通信链路。等威胁场景初步筛选出来后，再针对高风险区域细化 Level 1 的 DFD。这样既保证了覆盖率，又控制了工作量。
3.4 威胁建模知识体系总览
下面这张图，是我自己总结的威胁建模核心逻辑。它把 STRIDE、DFD、攻击面和攻击树串在了一起。每次做 TARA 前，我都会看一眼，提醒自己别跑偏。
嗯，这套流程走下来，威胁场景基本不会漏。但你要记住，工具只是辅助，真正值钱的是你对系统的理解。多跟功能安全工程师聊聊，多看看实车测试报告，你的威胁建模水平自然就上去了。