4. 损害场景与影响评级：定义与评定标准
好，我们进入TARA实战中非常关键的一步——损害场景定义和影响评级。说白了，就是要把“如果这个威胁真的发生了，会造成什么后果”这件事，用一套标准化的语言说清楚。
我个人习惯把这一步叫做“给风险画像”。你前面识别了威胁，分析了攻击路径，但最终决策层、项目经理、甚至法务部门关心的是：这玩意儿到底有多严重？ 没有这个评级，你前面做的所有技术分析都落不了地。
4.1 损害场景的定义
损害场景，不是让你写一篇小说。它是一段结构化、可验证的描述，讲清楚“谁、在什么情况下、受到了什么伤害”。
我见过很多新手工程师，写损害场景时喜欢写“可能导致车辆失控”。这太笼统了。你要问自己：怎么失控？在什么工况下？对谁造成了什么影响？
一个合格的损害场景，至少包含三个要素：
- 触发条件：威胁被利用时的车辆状态（如：高速行驶、充电中、OTA升级时）
- 受影响对象：驾驶员、乘客、行人、车辆本身、基础设施、厂商
- 具体后果：人身伤害、财产损失、功能失效、数据泄露、法规违反
示例（好 vs 坏）
❌ 坏：黑客攻击导致刹车失灵。
✅ 好：攻击者通过远程注入恶意CAN报文，使车辆在时速80km/h行驶时，ESC系统被禁用，制动助力失效，驾驶员无法在预期距离内刹停，导致追尾碰撞风险，可能造成驾驶员及乘客重伤。
你看，好的损害场景，几乎可以直接拿去给功能安全团队做危害分析（HARA）的输入。这也是ISO 21434和ISO 26262能协同的基础。
4.2 影响等级的四维标准：S、F、P、O
ISO 21434没有规定你必须用哪套评级标准，但它给出了四个必须评估的维度。我把它叫做“四维评分卡”：
| 维度 | 全称 | 关注点 | 典型问题 |
|---|---|---|---|
| S | Safety（安全） | 人身伤害 | 会不会死人？会不会受伤？ |
| F | Financial（财务） | 经济损失 | 修车多少钱？赔偿多少？ |
| P | Privacy（隐私） | 数据泄露 | 用户数据被偷了？ |
| O | Operational（运营） | 车辆功能/业务中断 | 车还能开吗？OTA还能用吗？ |
每个维度，我们一般分成4个等级：0（无影响）、1（轻微）、2（中等）、3（严重）。有些公司用1-5级，但4级制在工程实践中更好对齐，不容易出现“中间派”。
4.2.1 S（Safety）安全等级评定
这是最重的一个维度。我参与过的项目里，只要S评级到了3，基本就是最高优先级，没有商量余地。
评定标准参考：
- S0：无伤害风险
- S1：轻微伤害（如：皮肤擦伤、轻微不适），不需要专业医疗
- S2：中等伤害（如：骨折、轻度烧伤），需要医疗处理但无生命危险
- S3：严重伤害或死亡（如：重伤、多人伤亡）
我的经验：S评级不要只看“最坏情况”。ISO 21434要求你考虑可合理预见的误用。比如，一个警告信息被攻击者篡改，导致驾驶员忽略真实故障——这种间接伤害也要算进去。我曾经在一个项目中，就因为忽略了“信息误导”这个场景，导致后期补测，非常被动。
4.2.2 F（Financial）财务等级评定
财务影响不只是修车钱。它包括：
- 车辆维修/更换成本
- 厂商召回成本
- 法律诉讼赔偿
- 品牌声誉损失（这个很难量化，但必须考虑）
评定标准参考：
- F0：无经济损失
- F1：轻微损失（如：单个零部件更换，< 1000元）
- F2：中等损失（如：模块更换+工时，1000-10000元）
- F3：严重损失（如：整车报废、大规模召回、巨额罚款，> 10000元）
这里的金额阈值，每个公司可以自己定。我建议你根据车型定位来调整——10万的车和100万的车，阈值肯定不一样。
4.2.3 P（Privacy）隐私等级评定
这个维度在GDPR和《个人信息保护法》出来后，越来越重要。P评级关注的是：个人身份信息（PII）是否被未授权访问、泄露或篡改。
评定标准参考：
- P0：无隐私数据涉及
- P1：非敏感信息泄露（如：车辆VIN、配置信息）
- P2：中等敏感信息泄露（如：位置轨迹、驾驶习惯）
- P3：高度敏感信息泄露（如：生物特征、支付信息、身份证明）
避坑指南：我曾经遇到一个项目，团队认为“只泄露了车辆位置，不算隐私问题”。结果法务部门介入后，发现位置数据结合时间戳可以推断出用户家庭住址和工作单位，最终P评级从P1直接调整到P3。记住：隐私评级要考虑数据组合后的风险，不要只看单一字段。
4.2.4 O（Operational）运营等级评定
O维度评估的是：车辆或业务功能是否受到影响，以及影响的程度。 这个维度在网联汽车里特别重要——有些攻击不伤人、不偷钱、不泄露隐私，但就是让车用不了。
评定标准参考：
- O0：无功能影响
- O1：非关键功能受影响（如：娱乐系统重启、导航不可用）
- O2：关键功能受影响但可降级运行（如：ADAS部分功能禁用，但车辆仍可安全驾驶）
- O3：完全丧失运营能力（如：车辆无法启动、远程控制完全失效、充电中断）
4.3 损害场景与影响评级的映射关系
一个损害场景，通常对应多个维度的评级。比如，远程控制攻击导致车辆被锁：
- S：如果发生在行驶中，可能S2-S3；如果发生在停车状态，可能S0-S1
- F：拖车+维修，F1-F2
- P：不涉及隐私，P0
- O：车辆无法使用，O3
最终的风险值，不是简单取最大值。ISO 21434要求你分别记录每个维度的评级，然后在风险处置决策时综合考量。我个人习惯在TARA报告中用一张表来呈现：
| 损害场景ID | 描述 | S | F | P | O | 备注 |
|---|---|---|---|---|---|---|
| DS-001 | 高速行驶中制动助力失效导致追尾 | 3 | 2 | 0 | 2 | 需与功能安全联动 |
| DS-002 | 用户位置数据批量泄露 | 0 | 2 | 3 | 1 | 涉及GDPR合规 |
| DS-003 | OTA升级包被篡改导致ECU变砖 | 1 | 3 | 0 | 3 | 需回滚机制 |
4.4 损害场景与影响评级流程图
下面这张图，是我在项目里给团队培训时常用的。它把从威胁分析到损害场景定义、再到四维评级的流程串了起来。你想想看，是不是这个道理？
4.5 实战中的常见误区
嗯，这里我要多说几句。我带过不少TARA项目，发现新手最容易在损害场景和评级上犯三个错误：
- 场景写得太抽象：比如“黑客控制车辆”。这没法评级。你得具体到“通过什么方式、在什么工况下、导致什么具体后果”。
- 评级只关注S维度：很多工程师觉得“只要不死人，其他都不重要”。但现实是，一个P3的隐私泄露事件，可能让公司赔得比S2事故还多。四个维度要一视同仁。
- 忽略场景的时效性：同一个威胁，在停车状态和行驶状态，评级可能完全不同。我建议你在损害场景描述里，明确标注车辆状态。
核心原则：损害场景是TARA的“证据链”，影响评级是“判决书”。证据链不清晰，判决书就是废纸。每个场景都要经得起追问：“为什么是这个等级？依据是什么？”
好了，这一章的内容就到这里。损害场景和影响评级，是TARA从技术分析走向工程决策的桥梁。你把这个环节做扎实了，后面的安全目标和安全需求才能站得住脚。