3. 威胁场景分析：定义、STRIDE 方法论与构建实战

威胁场景分析，说白了就是回答一个问题：攻击者到底能怎么搞我们？

我刚开始做 TARA 的时候，总觉得威胁分析就是对着清单打勾。后来在一次真实项目中，一个看似不起眼的 OBD 接口威胁被我们忽略了，结果渗透测试团队只用了一根十几块钱的线，就拿到了网关的控制权。嗯，从那以后我再也不敢小看威胁场景的构建了。

3.1 什么是威胁场景？

威胁场景不是一句「有人会攻击我们」这种废话。它是一个具体的、可描述的、有上下文的故事。

我个人习惯这样定义：威胁场景 = 攻击者 + 攻击入口 + 攻击路径 + 造成的损害。

举个例子，一个「远程攻击 T-Box」的描述太模糊了。真正的威胁场景应该是：

「攻击者通过蜂窝网络向 T-Box 发送恶意 CAN 报文，绕过身份验证，导致车辆非预期加速。」

看到了吗？入口、路径、后果，全都有了。

3.2 STRIDE 方法论：威胁分类的六把刀

STRIDE 是微软提出来的威胁分类模型。说实话，它不是我见过最复杂的模型，但是最实用的。我在好几个量产项目里都用它，没出过大的遗漏。

字母	威胁类型	破坏的安全属性	一句话理解
S	Spoofing（欺骗）	身份认证	假装自己是别人
T	Tampering（篡改）	完整性	改数据、改代码
R	Repudiation（抵赖）	不可否认性	做了不承认
I	Information Disclosure（信息泄露）	机密性	不该看的被看到了
D	Denial of Service（拒绝服务）	可用性	系统瘫了、用不了
E	Elevation of Privilege（权限提升）	授权	普通用户干管理员的事

3.3 如何构建威胁场景？—— 四步法

我总结了一套四步法，在多个项目里验证过，效率不错。

1. 第一步：确定分析对象 —— 是哪个 ECU？哪个功能？哪个数据流？
2. 第二步：识别攻击界面 —— 物理接口？无线接口？传感器？诊断口？
3. 第三步：套用 STRIDE 逐类分析 —— 对每个界面，问自己六类威胁是否存在。
4. 第四步：描述具体场景 —— 用「攻击者 + 入口 + 路径 + 后果」的格式写出来。

举个例子，我们分析一个 智能座舱的 OTA 升级功能：

步骤	内容
分析对象	OTA 升级模块（从云端下载固件到座舱域控制器）
攻击界面	蜂窝网络、Wi-Fi、USB 本地刷写
STRIDE 分析	S：伪造 OTA 服务器 → 欺骗 T：篡改固件包 → 篡改 D：发送大量升级请求 → DoS
威胁场景描述	攻击者伪造 OTA 服务器证书，向座舱域控制器推送含恶意代码的固件，导致系统被植入后门。

3.4 STRIDE 在车载场景的适配技巧

STRIDE 是通用模型，但车载场景有它的特殊性。我个人习惯做一点微调：

• Spoofing：重点关注 V2X 消息伪造、ECU 身份伪造、传感器数据欺骗（比如 GPS 欺骗）。
• Tampering：重点关注 CAN 报文篡改、固件篡改、配置参数篡改。
• Repudiation：重点关注日志系统是否可信，事件溯源是否完整。
• Information Disclosure：重点关注密钥泄露、用户隐私数据泄露、调试接口暴露。
• Denial of Service：重点关注 CAN 总线泛洪、OTA 带宽耗尽、传感器盲化。
• Elevation of Privilege：重点关注诊断会话提权、Hypervisor 逃逸、安全域绕过。

3.5 威胁场景构建的常见误区

我带过不少团队做 TARA，发现新手最容易犯这几个错：

3.6 本章知识结构图

下面这张图概括了威胁场景分析的核心逻辑，我建议你把它贴在工位旁边：

3.7 实战建议

最后，给你几个我在项目里沉淀下来的建议：

• 别一个人闷头想 —— 拉上系统工程师、功能安全工程师一起做 STRIDE 脑暴，不同视角能发现更多威胁。
• 用模板固化输出 —— 每个威胁场景都按统一格式写，方便后续风险评估和追溯。
• 定期更新威胁场景库 —— 新漏洞、新攻击手法出现后，回头看看之前的场景有没有遗漏。