3. 威胁场景建模:STRIDE方法论详解、威胁场景构建、攻击路径分析

威胁建模这件事,说白了就是「站在攻击者的角度思考问题」。你想想看,如果不知道坏人会从哪里下手,你怎么防?我在多个量产项目里发现,很多团队把大量精力花在漏洞扫描上,却忽略了最根本的一步——系统性地识别威胁。今天我们就来聊聊STRIDE这个经典框架,以及怎么用它构建真实的威胁场景。

3.1 STRIDE方法论:六类威胁的实战解读

STRIDE是微软提出的威胁分类模型,六个字母分别代表六类威胁。我个人习惯把它当作「检查清单」来用——每分析一个系统组件,就挨个过一遍这六类,基本不会漏东西。

威胁类型 英文 核心问题 典型场景
S - 欺骗 Spoofing 攻击者能否伪装成合法实体? 伪造ECU身份、冒充OTA服务器
T - 篡改 Tampering 数据或代码能否被非法修改? 篡改固件、修改CAN报文
R - 抵赖 Repudiation 用户能否否认做过某操作? 否认发送过诊断指令
I - 信息泄露 Information Disclosure 敏感数据能否被未授权读取? 窃取用户隐私、读取密钥
D - 拒绝服务 Denial of Service 系统资源能否被耗尽? CAN总线泛洪、GPS信号干扰
E - 权限提升 Elevation of Privilege 低权限用户能否获得高权限? 从APP提权到系统层
我的经验: 刚开始做TARA时,我总把「欺骗」和「篡改」搞混。后来我给自己定了个规则——欺骗是对「身份」的伪造,篡改是对「数据」的破坏。比如伪造一个ECU的ID是欺骗,但修改它发出的报文内容就是篡改。

3.2 威胁场景构建:从数据流到威胁故事

光知道六类威胁还不够,你得把它们「翻译」成具体的场景。我习惯用三步法来构建威胁场景:

  1. 画数据流图 —— 标出所有外部实体、过程、数据存储和数据流
  2. 逐元素套STRIDE —— 对每个数据流元素问「这六类威胁可能发生吗?」
  3. 写威胁故事 —— 用「攻击者 + 攻击目标 + 攻击手段 + 造成后果」的句式描述

举个例子,分析一个OTA升级流程:

  • 数据流:云端服务器 → 车载T-Box → 网关 → 目标ECU
  • STRIDE分析:对「云端→T-Box」这条链路,S(欺骗)意味着攻击者可能伪造OTA服务器;T(篡改)意味着固件包可能在传输中被修改
  • 威胁故事:「攻击者通过伪造OTA服务器,向车辆推送篡改过的固件,导致ECU功能异常」
关键点: 威胁场景不是技术细节的堆砌,而是一个完整的攻击叙事。它要回答:谁?通过什么?攻击哪里?造成什么影响?

3.3 攻击路径分析:把碎片连成线

单个威胁场景就像一块拼图,攻击路径分析就是把这些拼图连起来。我记得在某个Tier 1的项目中,客户只关注了单个ECU的威胁,结果攻击者通过组合两个低风险漏洞,绕过了整个安全架构。嗯,这就是为什么我们要做攻击路径分析。

攻击路径分析的核心步骤:

  1. 识别入口点 —— 攻击者从哪里进入系统?(如:蓝牙、Wi-Fi、OBD接口)
  2. 绘制攻击链 —— 从一个入口点出发,攻击者能「跳」到哪些内部组件?
  3. 标注攻击难度 —— 每一步需要什么条件?(如:物理接触、逆向工程、已知漏洞)
  4. 评估可达性 —— 攻击者最终能到达哪个高价值目标?(如:网关、安全域控制器)

下面这张图展示了一个典型的攻击路径分析框架:

攻击路径分析框架 入口点 蓝牙/Wi-Fi/OBD 攻击链 步骤1: 突破边界 步骤2: 横向移动 步骤3: 权限提升 高价值目标 网关/安全域控 分析要点: • 每个入口点可能对应多条攻击链,需要逐一分析 • 攻击链中的每一步都需要标注「攻击难度」和「所需条件」 • 高价值目标通常是安全域控制器、网关、数据存储中心 • 我曾经见过一个案例:攻击者通过OBD接口进入,经过3步横向移动最终控制了网关

3.4 实战中的避坑指南

做了这么多年TARA,我踩过不少坑。分享几个典型的:

我曾经犯过的错: 在第一个项目中,我只分析了「外部攻击者」的场景,完全忽略了「内部人员威胁」。结果后来发现,一个拥有合法诊断工具的维修工,其实能造成比外部攻击者更大的破坏。记住:威胁建模要覆盖所有可能的攻击者画像。
  • 别只盯着技术威胁 —— 物理攻击(如:撬开OBD接口、拆卸ECU)往往被忽略,但实际中很常见
  • 攻击路径不是越复杂越好 —— 我见过有人把攻击链画了十几步,但现实中攻击者根本不会走那么绕的路。保持简洁,聚焦在「最可能的路径」上
  • 别忘了「组合攻击」 —— 单个低风险威胁可能不可怕,但两个组合起来可能就是致命漏洞

3.5 从理论到实践:一个完整的威胁场景示例

最后,我们用一个完整的例子把今天的内容串起来。假设我们要分析一个「远程解锁车门」的功能:

分析维度 内容
数据流 手机APP → 云端服务器 → T-Box → 车身域控制器 → 门锁执行器
STRIDE威胁 S: 伪造手机APP身份
T: 篡改解锁指令
I: 窃取用户凭证
D: 对云端发起DoS攻击
威胁场景 攻击者通过伪造手机APP身份,向云端发送解锁指令,绕过身份认证,最终非法解锁车门
攻击路径 入口点:手机APP → 突破点:伪造Token → 横向移动:控制T-Box → 目标:门锁执行器

你看,通过STRIDE+攻击路径分析,一个看似简单的功能,背后其实藏着不少威胁。我个人习惯在项目初期就把这些分析做完,而不是等到测试阶段才发现问题——那时候改起来成本就高了。

一个小技巧: 做攻击路径分析时,可以试着用「攻击者的视角」走一遍流程。我会问自己:「如果我是黑客,我会怎么搞这个系统?」——这个视角转换往往能发现很多遗漏的威胁。