4、威胁场景建模：STRIDE方法论详解、如何将STRIDE应用于汽车系统、威胁场景的文档化标准

好，咱们进入第四章。前面几章我们把TARA的骨架搭起来了，知道了要分析什么资产，怎么定风险等级。但有个关键问题一直没解决——威胁到底从哪来？

你想想看，一个智能座舱域控制器，有蓝牙、有Wi-Fi、有CAN总线、有以太网，还有一堆第三方应用。你光说“它有安全风险”，这太笼统了。我们需要一个系统性的方法，把抽象的“风险”拆解成具体的、可操作的“威胁场景”。

这就是STRIDE要干的事。

4.1 STRIDE：微软的“威胁分类学”

STRIDE是微软在2000年代初提出的一套威胁分类模型。名字是六个威胁类型的首字母缩写：

字母	威胁类型	通俗理解	违反的安全属性
S	Spoofing（欺骗）	假装成别人	身份认证
T	Tampering（篡改）	数据被动了手脚	完整性
R	Repudiation（抵赖）	做了事不认账	不可否认性
I	Information Disclosure（信息泄露）	不该看的被看到了	机密性
D	Denial of Service（拒绝服务）	系统瘫了，用不了	可用性
E	Elevation of Privilege（权限提升）	小兵拿到了将军的权限	授权

STRIDE的精髓在于：它不直接告诉你“有什么威胁”，而是给你一套“威胁的语法”。你拿着这套语法，去分析你的系统架构图，就能把每个数据流、每个组件、每个存储节点可能面临的威胁类型枚举出来。

4.2 如何将STRIDE应用于汽车系统

好，理论说完了。咱们来点实战的。我拿一个典型的车载信息娱乐系统（IVI）举例。

首先，你得画出系统的数据流图（DFD）。这是STRIDE分析的前提。DFD里有几个基本元素：外部实体（人、云端）、进程（APP、服务）、数据存储（文件、数据库）、数据流（箭头）。

然后，对每个元素，挨个问STRIDE的六个问题。

4.2.1 对“外部实体”应用STRIDE

外部实体通常是攻击的入口点。主要关注Spoofing和Repudiation。

• Spoofing：攻击者能否伪装成合法的手机APP，向IVI发送指令？
• Repudiation：云端服务器能否否认它曾经下发过某个OTA升级包？

4.2.2 对“进程”应用STRIDE

进程是系统的“大脑”。所有威胁类型都可能涉及。

• Spoofing：一个恶意进程能否冒充系统服务，获取用户隐私？
• Tampering：攻击者能否通过缓冲区溢出，修改进程的执行逻辑？
• Repudiation：进程执行了关键操作（如解锁车门），但没有日志记录？
• Information Disclosure：进程处理用户语音时，是否会把原始音频明文存储？
• Denial of Service：攻击者能否发送大量无效请求，让导航进程崩溃？
• Elevation of Privilege：一个普通的媒体播放器进程，能否获取系统root权限？

4.2.3 对“数据存储”应用STRIDE

数据存储是“金库”。重点关注Tampering和Information Disclosure。

• Tampering：攻击者能否篡改存储在eMMC里的系统固件？
• Information Disclosure：车辆位置历史记录是否以明文存储在本地数据库？
• Denial of Service：攻击者能否填满存储空间，导致系统无法写入新日志？

4.2.4 对“数据流”应用STRIDE

数据流是“血管”。重点关注Tampering和Information Disclosure。

• Tampering：CAN总线上的制动信号是否可能被中间人篡改？
• Information Disclosure：以太网上的诊断流量是否被加密？
• Denial of Service：攻击者能否在CAN总线上灌入大量错误帧，阻塞正常通信？

4.3 威胁场景的文档化标准

分析出威胁还不够，你得把它写下来。写得不清楚，开发看不懂，测试没法测，安全评审也过不了。

我见过很多团队，威胁描述就写一句“攻击者可能篡改CAN报文”。这太模糊了。篡改哪个报文？从哪进来的？篡改后有什么后果？

一个合格的威胁场景文档，至少应该包含以下字段：

字段	说明	示例
威胁ID	唯一标识符	THR-IVI-0042
威胁名称	简短描述	通过蓝牙伪装合法手机APP
STRIDE分类	S/T/R/I/D/E	Spoofing
威胁描述	详细说明攻击步骤	攻击者使用自定义蓝牙设备，模拟已配对的手机，发送解锁车门指令。
受影响资产	关联的资产ID	ASSET-BT-001（蓝牙连接服务）
攻击入口	攻击者从哪里进入	蓝牙无线接口
攻击前提	攻击需要什么条件	车辆蓝牙处于可发现模式，且已与目标手机配对过。
安全影响	违反的安全属性	身份认证失效，导致非授权访问
风险等级	根据TARA计算	Severity: 4, Probability: 3 → Risk: 12 (High)
缓解措施	建议的安全控制	1. 蓝牙配对时使用双向认证；2. 所有指令需经过会话令牌验证。

4.4 知识结构图：STRIDE与威胁场景建模流程

下面这张图，把整个流程串起来了。从系统架构出发，经过STRIDE分析，最终输出结构化的威胁场景文档。

4.5 实战中的几个要点

最后，分享几个我在项目中积累的经验。

1. STRIDE不是一次性工作。架构变了，DFD变了，STRIDE就得重新过一遍。我见过有的团队，年初做了一次STRIDE，年底评审时发现架构早改了三轮了，威胁分析还是年初那份。这等于白做。
2. 别在“抵赖（Repudiation）”上钻牛角尖。在汽车嵌入式系统里，Repudiation通常不是最高优先级的威胁。你想想，ECU会抵赖它发过某个CAN报文吗？除非有日志审计需求，否则这个威胁可以快速过掉。
3. 威胁场景文档要“可测试”。写缓解措施时，要想着“测试工程师看到这个，能不能写出测试用例”。比如“使用加密通信”就不如“使用TLS 1.3加密所有以太网诊断通信”来得具体。