一、威胁分析与风险评估（TARA）：从方法论到实战落地

各位工程师朋友，咱们今天聊聊TARA。说实话，我刚入行那会儿，觉得TARA就是个形式化的文档工作——画几个图、填几张表，应付审核就完事了。直到有一次，我在实车测试中真抓到了一个被漏掉的攻击路径，才意识到：TARA不是走过场，它是整个安全测试的“导航地图”。

你想想看，一辆车上有上百个ECU、几千万行代码，如果没有系统性的威胁分析，你根本不知道从哪里下手。所以这一章，咱们把TARA的底牌翻个底朝天。

1.1 TARA方法论概述

TARA，全称Threat Analysis and Risk Assessment。说白了，就是回答三个问题：

  • 什么东西值得保护？（资产识别）
  • 谁会来搞破坏？（威胁分析）
  • 搞成了后果多严重？（风险评估）

目前主流的TARA方法论，我接触过的有这几种：

方法论 来源 特点
EVITA 欧盟项目 偏重硬件安全，适合早期架构设计
HEAVENS 瑞典研究 量化程度高，适合安全等级评定
ISO 21434 国际标准 流程完整，是目前行业主流
STRIDE 微软 简单粗暴，适合快速头脑风暴

我个人习惯用ISO 21434的框架，但具体分析时结合STRIDE来拆解威胁类型。为什么呢？因为ISO 21434告诉你“要做什么”，而STRIDE告诉你“怎么想”。

核心要点：TARA不是一次性工作。在概念阶段、开发阶段、生产阶段、运维阶段，都需要迭代更新。我见过不少团队只在项目启动时做一次TARA，后面就扔一边了——结果测试时发现新功能根本没覆盖到。

1.2 资产识别与损害场景

资产识别，是TARA的第一步，也是最容易出错的一步。嗯，这里要注意：资产不只是硬件和代码，还包括数据、功能、甚至通信信道。

举个例子，我在项目中遇到过这样一个案例：团队只把“网关ECU”列为资产，却忽略了“网关与T-Box之间的CAN报文”。结果呢？攻击者通过伪造CAN报文，成功绕过了网关的防火墙。你看，通信信道本身也是资产。

资产识别的一般步骤：

  1. 列出所有系统元素：ECU、传感器、执行器、通信总线
  2. 识别数据流：谁和谁通信？传什么数据？
  3. 标注安全属性：哪些数据需要保密？哪些功能不能中断？
  4. 定义损害场景：如果这个资产被攻击，会怎样？

损害场景的典型分类：

  • 人身安全：比如刹车失灵、气囊误爆
  • 财产损失：比如车辆被盗、电池损坏
  • 隐私泄露：比如位置轨迹、通话记录被窃取
  • 功能降级：比如导航不可用、空调失控

避坑指南：我曾经犯过一个错误——只分析了“最坏情况”。比如认为“刹车失灵”就是最严重的，结果忽略了“刹车响应延迟200ms”这种渐进式风险。实际上，后者在高速场景下同样致命。所以，损害场景要覆盖直接后果和间接后果。

1.3 威胁场景分析与攻击路径

资产和损害场景定好了，接下来就是“坏人会怎么干”。这里我推荐用攻击树（Attack Tree）来建模。为什么？因为它直观，而且能帮你发现组合攻击。

攻击树的基本结构：

  • 根节点：攻击目标（比如“远程控制车辆”）
  • 子节点：达成目标需要的步骤（比如“获取远程访问权限”→“绕过身份认证”→“发送控制指令”）
  • 叶子节点：具体的攻击方法（比如“暴力破解PIN码”、“利用T-Box固件漏洞”）

举个例子，咱们分析一个“通过OBD接口攻击网关”的场景：

攻击目标：通过OBD接口控制车辆
├── 物理接入OBD端口
│   ├── 撬开车窗（物理入侵）
│   └── 通过诊断设备连接（合法但被滥用）
├── 绕过网关过滤规则
│   ├── 发送伪造的诊断请求
│   └── 利用CAN ID白名单漏洞
└── 发送控制指令
    ├── 解锁车门
    └── 关闭发动机

你可能会问：“这些攻击路径怎么发现的？”说实话，没有捷径。我个人的经验是：多问“如果...会怎样”。比如：

  • 如果攻击者物理接触了车辆？
  • 如果攻击者能发送任意CAN报文？
  • 如果攻击者拿到了云端服务器的私钥？

每个“如果”都可能引出一条新的攻击路径。

注意：攻击路径分析时，不要只盯着技术漏洞。社会工程学攻击（比如骗取维修人员的诊断账号）同样需要纳入考虑。我曾经参与的一个项目，攻击者就是通过钓鱼邮件拿到了TSP平台的登录凭证——这比破解任何加密算法都简单。

1.4 风险等级评定与处置决策

风险评定，说白了就是算一笔账：攻击发生的可能性 × 攻击造成的严重性。

ISO 21434中，风险等级通常分为四级：

等级 描述 处置策略
Critical 可能造成人员伤亡 必须消除或缓解到可接受水平
Major 可能造成重大财产损失或隐私泄露 必须缓解，可接受残余风险需审批
Moderate 可能造成功能降级或轻微损失 建议缓解，可接受残余风险
Minor 影响很小，几乎无后果 可记录但不强制处理

这里有个关键点：可能性怎么算？很多团队拍脑袋定“高/中/低”，这其实不科学。我建议从三个维度评估：

  • 攻击门槛：需要专业设备吗？需要物理接触吗？
  • 攻击成本：需要多少时间？多少资金？
  • 攻击收益：攻击者能得到什么？值得冒险吗？

举个例子，一个需要“拆解ECU并焊接飞线”的攻击，可能性就很低——因为门槛太高，收益又不大。但一个“通过蓝牙广播漏洞远程攻击”的场景，可能性就很高——因为攻击者坐在车里就能干。

处置决策通常有四种：

  1. 消除：从架构上移除这个风险点（比如去掉不用的调试接口）
  2. 缓解：增加安全措施降低风险（比如加防火墙、加密通信）
  3. 转移：通过保险或合同转嫁风险
  4. 接受：风险很低，暂时不处理

我的建议：对于Critical和Major等级的风险，一定要有可验证的安全目标。比如“攻击者无法通过OBD接口发送未经授权的CAN报文”这个目标，后续要通过渗透测试来验证。别写那种“确保系统安全”的空话——没法测，等于白写。

好了，这一章咱们把TARA的骨架搭起来了。下一章，我会带大家手把手做一个完整的TARA案例——从资产识别到风险处置，每一步都有实战数据。到时候你会发现，TARA其实没那么玄乎，就是一套系统化的“找茬”方法。

记住：没有完美的安全，只有可控的风险。咱们做TARA的目的，不是消灭所有威胁——那不可能——而是把有限的资源投入到最需要的地方。

← 上一章 📖 返回目录 下一章 →