威胁建模与风险评估：STRIDE模型在OTA中的应用
威胁建模这事儿，说白了就是在攻击者动手之前，先替他们把路走一遍。我做了这么多年OTA安全，最深的体会就是：如果你不知道敌人会从哪里来，那你的防御就是瞎忙活。
这一章，咱们就聊聊怎么用STRIDE模型给OTA全链路做一次“体检”。我会结合自己踩过的坑，把资产识别、威胁分析和风险等级划分这些事儿讲透。
为什么是STRIDE？
市面上威胁建模的方法论不少，比如PASTA、Trike、VAST。但我个人习惯用STRIDE。为什么？因为它够直观，够落地。
STRIDE是微软提出的一套威胁分类框架，把安全威胁分成六类：
- S - Spoofing（欺骗）
- T - Tampering（篡改）
- R - Repudiation（抵赖）
- I - Information Disclosure（信息泄露）
- D - Denial of Service（拒绝服务）
- E - Elevation of Privilege（权限提升）
你想想看，OTA全链路从云端到车端，中间经过网络、网关、ECU，每一个环节都可能被这六种威胁中的某一种盯上。STRIDE的好处就是帮你“按图索骥”，不会漏掉关键点。
核心观点：STRIDE不是银弹，但它是一张很好的“威胁地图”。有了这张地图，你才知道该在哪个路口设卡。
第一步：资产识别——你得知道你要保护什么
做威胁建模之前，先得搞清楚一件事：我们的资产是什么？
我在项目中遇到过不少团队，上来就画数据流图、分析威胁，结果做到一半发现连保护对象都没定义清楚。这就像你要修一堵墙，却不知道墙里面放的是黄金还是稻草。
OTA全链路的资产，我习惯分成三类：
| 资产类别 | 具体内容 | 示例 |
|---|---|---|
| 数据资产 | OTA升级包、签名证书、密钥、车辆配置信息 | 固件镜像、增量补丁、根证书 |
| 系统资产 | 云端服务器、网关、ECU、T-Box | OTA管理平台、刷写工具、安全存储区 |
| 流程资产 | 升级流程、回滚机制、校验逻辑 | 签名验证流程、断点续传机制 |
嗯，这里要注意：很多人只关注数据资产，忽略了流程资产。我曾经见过一个项目，密钥管理做得滴水不漏，但回滚流程里有个逻辑漏洞——攻击者可以利用旧版本固件的已知漏洞绕过校验。这就是典型的“流程资产”没保护好。
我的习惯：做资产识别时，我会拉上开发、测试、运维一起开个“资产盘点会”。每个人从自己的视角列清单，最后汇总。这样不容易漏。
第二步：威胁分析——用STRIDE逐项过筛子
资产清单有了，接下来就是拿STRIDE这把筛子，一项一项地过。
我一般会画一张数据流图（DFD），把OTA全链路拆成几个关键节点：云端→网络→车端网关→目标ECU。然后对每个节点，问自己六个问题：
- Spoofing：谁能冒充合法实体？比如伪造OTA服务器、伪造车端身份。
- Tampering：数据在传输或存储过程中能被篡改吗？比如升级包被中间人修改。
- Repudiation：操作行为能否被追溯？比如ECU刷写失败后，是谁的责任？
- Information Disclosure：敏感信息会泄露吗？比如密钥、固件被窃取。
- Denial of Service：服务能被中断吗？比如恶意刷请求打垮OTA服务器。
- Elevation of Privilege：低权限实体能获得高权限吗？比如普通用户提权刷写Bootloader。
举个例子，咱们看“OTA升级包下载”这个环节：
| 威胁类型 | 具体场景 | 影响 |
|---|---|---|
| Spoofing | 攻击者伪造OTA服务器，诱导车端下载恶意固件 | 车辆被远程控制 |
| Tampering | 中间人篡改升级包，植入后门 | 固件完整性被破坏 |
| Repudiation | 车端否认收到升级包，云端无法追溯 | 责任不清，无法审计 |
| Information Disclosure | 升级包被窃听，泄露固件内部逻辑 | 知识产权泄露 |
| Denial of Service | 攻击者大量发送下载请求，耗尽服务器带宽 | 正常车辆无法升级 |
| Elevation of Privilege | 利用升级包漏洞获取ECU最高权限 | 整车安全防线被突破 |
你看，一个简单的下载环节，就能挖出六种威胁。这就是STRIDE的价值——它逼着你把每个角落都翻一遍。
避坑指南：我曾经在一个项目中，只分析了“云端→车端”这条链路，忽略了“车端→ECU”的内部通信。结果攻击者通过CAN总线直接篡改了ECU的升级指令，绕过了云端的全部防护。记住：威胁分析要覆盖全链路，不能有盲区。
第三步：风险等级划分——别想一口吃成胖子
威胁清单列出来了，少说几十条，多则上百条。你不可能全部修复，资源也不允许。这时候就需要风险等级划分，帮你决定先修什么、后修什么。
我常用的方法是DREAD模型，它和STRIDE是绝配。DREAD从五个维度给每个威胁打分：
- D - Damage Potential（潜在损害）
- R - Reproducibility（可复现性）
- E - Exploitability（可利用性）
- A - Affected Users（受影响用户）
- D - Discoverability（可发现性）
每个维度打1-3分，总分15分。然后按分数划分等级：
| 风险等级 | 分数范围 | 处理策略 |
|---|---|---|
| 高危 | 12-15分 | 必须立即修复，不能上线 |
| 中危 | 8-11分 | 需要修复，可接受短期风险 |
| 低危 | 4-7分 | 可接受，持续监控 |
| 信息 | 1-3分 | 记录在案，暂不处理 |
举个例子，刚才说的“伪造OTA服务器”这个威胁：
- Damage Potential：3分（能控制整车）
- Reproducibility：3分（只要有网络就能复现）
- Exploitability：2分（需要一定技术能力）
- Affected Users：3分（影响所有在线车辆）
- Discoverability：2分（需要分析OTA协议）
总分13分，妥妥的高危。必须上证书校验、双向认证、域名白名单等多层防护。
我的经验：打分的时候别一个人拍脑袋。我习惯拉上安全团队和业务团队一起评，因为业务方更清楚某个威胁的实际影响有多大。有时候你觉得是低危，业务方一句话“这个漏洞会导致召回”，立马变高危。
一张图看懂STRIDE+OTA威胁建模
说了这么多，咱们用一张SVG图把整个流程串起来。这张图展示的是OTA全链路威胁建模的核心逻辑：从资产识别开始，经过STRIDE逐项分析，最后用DREAD打分定级。
威胁建模的常见误区
做了这么多年，我总结了几条容易踩的坑，分享给你：
- 误区一：只做一次威胁建模。OTA系统是动态的，固件版本在变、网络环境在变、攻击手法也在变。我建议每个大版本迭代都重新做一次威胁建模。
- 误区二：威胁建模和开发脱节。我见过最离谱的情况是，安全团队花了两周做完威胁建模，扔给开发一份100页的文档，然后就没然后了。威胁建模一定要嵌入开发流程，比如在需求评审阶段就引入。
- 误区三：只关注技术威胁，忽略流程威胁。比如升级失败后的回滚流程、密钥轮换流程，这些流程本身也可能有漏洞。
我曾经踩过的坑：有一次我们做威胁建模，发现云端到车端的通信有中间人攻击风险，于是上了TLS双向认证。但忽略了车端内部CAN总线上的威胁。结果攻击者通过OBD接口接入，直接往CAN总线上发伪造的升级指令，绕过了所有云端防护。从那以后，我要求威胁建模必须覆盖“端到端”，不能只盯着网络层。
小结
威胁建模不是一次性的“交作业”，而是贯穿OTA全生命周期的持续活动。STRIDE给你提供了分类框架，DREAD帮你排优先级，但最终能不能落地，取决于你愿不愿意把这件事嵌入到日常开发中。
记住一句话：威胁建模的价值不在于那张图，而在于你通过它发现了什么、改了什么。