4. 损害场景分析：定义损害场景与影响评估
损害场景分析，说白了就是回答一个问题：如果攻击者得手了，最坏会怎样？
我在做第一个TARA项目时，团队花了两周画攻击树，却没人认真想过“攻击成功之后到底会发生什么”。结果评审时被安全经理一句话问住了：“你们说这个漏洞严重，严重在哪？车会失控吗？用户隐私会泄露吗？还是只是仪表盘闪个故障灯？”
嗯，从那以后我养成了一个习惯——先想损害，再找威胁。今天我们就来聊聊怎么系统性地做这件事。
4.1 什么是损害场景
损害场景是TARA的核心产出之一。它描述的是：当某个威胁被成功利用后，对车辆、人员、环境或企业造成的负面后果。
一个完整的损害场景通常包含三个要素：
- 触发条件：什么攻击路径被激活了
- 受影响对象：谁/什么受到了伤害（驾驶员、乘客、行人、企业、社会）
- 具体后果：发生了什么样的损失或伤害
举个例子：
“攻击者通过远程OBD接口注入恶意CAN消息，导致制动系统在高速行驶时误触发紧急制动，造成车辆失控追尾，驾驶员受伤。”
这就是一个完整的损害场景。
4.2 四大影响维度
ISO 21434把损害影响分成四个维度。我个人习惯把它们记成S-F-O-P：
| 维度 | 英文 | 关注点 | 典型例子 |
|---|---|---|---|
| S - Safety | Safety | 人身安全 | 人员伤亡、健康损害 |
| F - Financial | Financial | 经济损失 | 维修费用、召回成本、罚款 |
| O - Operational | Operational | 功能/运营 | 车辆不可用、功能降级 |
| P - Privacy | Privacy | 隐私/数据 | 个人信息泄露、位置追踪 |
你想想看，同一个漏洞在不同维度下的严重程度可能天差地别。比如一个信息娱乐系统的缓冲区溢出：
- Safety：可能很低（不直接影响驾驶）
- Privacy：可能很高（能窃取通讯录、位置历史）
所以评估时必须四个维度都过一遍，不能只看安全。
4.3 损害场景的生成方法
我在项目中常用的方法是“威胁-资产-后果”三角映射法。具体分三步：
- 列出已识别的威胁（来自上一章的威胁分析）
- 关联受影响资产（安全属性：机密性、完整性、可用性）
- 推导具体后果（结合车辆实际使用场景）
一个小技巧：
我习惯用“如果……那么……”句式来生成损害场景。比如：
“如果攻击者篡改了GPS信号，那么导航系统会给出错误路线，导致驾驶员误入危险路段。”
这个句式能强迫你把攻击和后果之间的因果关系说清楚。
4.4 影响等级评定
每个损害场景都需要评定影响等级。ISO 21434没有规定具体的等级划分，但业界常用四级制：
| 等级 | Safety | Financial | Operational | Privacy |
|---|---|---|---|---|
| S0 | 无伤害 | 无损失 | 无影响 | 无泄露 |
| S1 | 轻伤 | 轻微（<1万） | 功能降级 | 非敏感信息 |
| S2 | 重伤 | 中等（1-10万） | 功能不可用 | 敏感信息 |
| S3 | 死亡 | 严重（>10万） | 车辆完全失效 | 大规模隐私泄露 |
注意：
我曾经在一个项目里看到团队把“仪表盘黑屏”评为S2（重伤），理由是“驾驶员可能因为看不到车速而超速导致事故”。这个推理链条太长了。损害场景评估要基于直接后果，而不是无限推导的间接后果。仪表盘黑屏的直接后果是功能降级（O1或O2），而不是人身伤害。
4.5 实战案例：远程空调控制的损害场景
我们拿一个具体的功能来练练手——远程空调控制（通过手机App远程开启/关闭空调）。
假设我们已经识别出一个威胁：攻击者通过重放攻击伪造空调控制指令。
现在我们来生成损害场景：
| 维度 | 损害场景描述 | 等级 |
|---|---|---|
| Safety | 攻击者反复开关空调，导致12V电池耗尽，车辆无法启动，驾驶员被困在偏远地区 | S1（轻伤风险） |
| Financial | 电池过度放电导致损坏，需要更换，费用约2000元 | F1（轻微） |
| Operational | 车辆无法启动，完全不可用，直到电池充电或更换 | O2（功能不可用） |
| Privacy | 攻击者通过空调开启状态推断车主是否在家（存在/不存在） | P2（敏感信息） |
你看，同一个威胁在四个维度下的影响完全不同。最终的风险值取最高等级——这里就是O2和P2。
4.6 损害场景与攻击路径的关系
这里有个容易混淆的点：损害场景不是攻击路径。
攻击路径描述的是“怎么攻进来”，损害场景描述的是“攻进来之后会怎样”。两者是因果关系，但评估时一定要分开。
我画了一张图来说明它们的关系：
4.7 常见误区与避坑指南
我曾经踩过的坑：
- 混淆损害场景和攻击路径：把“攻击者通过CAN总线注入消息”当作损害场景。不对，这是攻击路径。损害场景应该是“制动系统误触发导致追尾”。
- 只评估Safety：很多工程师天然只关注安全，忽略了Financial、Operational和Privacy。但有时候Privacy的影响比Safety更大（比如GDPR罚款）。
- 等级评定过于保守：把所有场景都评成S3，结果导致所有风险都变成“不可接受”，反而失去了优先级排序的意义。
我的建议：
做损害场景分析时，拉上功能工程师和售后工程师一起讨论。功能工程师知道系统在极限工况下的表现，售后工程师见过实际故障案例。他们的经验能帮你避免很多“纸上谈兵”式的误判。
4.8 小结
损害场景分析是TARA中最“接地气”的一步。它把抽象的安全威胁翻译成了具体的、可感知的后果。记住四个维度S-F-O-P，每个场景都要过一遍。