第3章 TARA方法论概述：它在ISO 21434中的位置与实战价值
说实话，刚接触ISO 21434那会儿，我也有点懵。标准里一堆术语，TARA、CAL、HARA……到底哪个先做？哪个是核心？
后来做项目多了，我慢慢摸出门道——TARA（威胁分析与风险评估）就是整个标准的中枢神经。你想想看，没有它，你连该防谁、防什么都搞不清楚，后面的安全开发全是瞎忙活。
3.1 TARA在ISO 21434中的位置
ISO 21434把网络安全活动分成了几个大块：
- 组织层管理（第5-10章）——定规矩、管流程
- 项目层活动（第11-14章）——具体干活
- 分布式开发（第15章）——跟供应商扯皮
- 持续活动（第16章）——运维监控
TARA就卡在项目层活动的最前面。标准里第11章专门讲它，位置非常靠前。为什么？
因为TARA的输出直接决定了后面所有安全工作的方向。我见过一个团队，上来就闷头做安全设计，结果TARA一做完发现威胁模型全错了，前面白干三个月。嗯，这坑我踩过。
核心观点：TARA不是可选项，它是ISO 21434合规的起点。没有TARA，你的安全活动就没有依据，审计也过不了。
3.2 TARA的输入与输出
搞懂TARA，先搞清楚它吃什么、拉什么。说白了就是输入输出。
输入：你得先有这些
- 系统定义——你要分析的对象是什么？功能边界在哪？
- 功能描述——这玩意儿能干啥？跟谁通信？
- 初步架构——ECU、传感器、执行器怎么连的？
- 资产清单——哪些数据、哪些功能是值钱的？
- 安全目标——客户或法规有没有硬性要求？
我个人习惯，在项目启动会上就把这些材料对齐。不然TARA做到一半发现输入不全，那才叫痛苦。
输出：TARA给你什么
- 威胁场景列表——谁可能攻击你？怎么攻击？
- 攻击路径——攻击者会走哪条路进来？
- 风险等级——每个威胁有多严重？多容易发生？
- 安全目标——针对高风险项，你要达到什么安全水平？
- 安全需求——具体怎么做才能防住？
我的经验：输出里最容易被忽略的是安全目标。很多人做完风险评估就停了，忘了把风险转化成可验证的安全目标。结果后面做测试时发现没有验收标准，又得回头补。
我整理了一个输入输出对照表，方便你快速查阅：
| 类别 | 输入 | 输出 |
|---|---|---|
| 系统层面 | 系统定义、功能描述 | 威胁场景、攻击路径 |
| 资产层面 | 资产清单、安全目标 | 风险等级、安全目标 |
| 需求层面 | 初步架构 | 安全需求 |
3.3 TARA与系统开发V模型的关系
搞汽车开发的都知道V模型。左边是设计，右边是测试，中间是实现。TARA在V模型里扮演什么角色？
我直接说结论：TARA是V模型左侧的起点。
你看V模型的左边：
- 系统需求 → 2. 系统设计 → 3. 组件设计 → 4. 实现
TARA做完之后，输出的安全目标直接变成系统需求的一部分。也就是说，安全需求不是额外加进来的，而是跟功能需求一起进入V模型。
我曾经在一个项目里看到，团队把安全需求单独拎出来做，结果跟功能需求打架——安全要加密，功能要低延迟，两边互不相让。后来我建议他们把TARA输出的安全目标直接写进系统需求文档，跟功能需求一起评审、一起变更管理。问题就解决了。
注意：TARA不是一次性活动。V模型是迭代的，TARA也要跟着迭代。架构变了、功能改了、新威胁出现了，都得重新跑TARA。我见过最惨的案例是项目快量产了才发现有个关键威胁没分析到，结果紧急召回……
下面这张图是我自己画的，帮你理解TARA在V模型里的位置：
3.4 实战中的TARA流程
理论说完了，聊聊实战。我一般把TARA分成6步：
- 定义分析范围——搞清楚你要分析哪个系统、哪个功能
- 资产识别——找出值钱的数据和功能
- 威胁场景识别——想攻击者会怎么搞破坏
- 影响评级——如果被攻击了，后果有多严重
- 攻击可行性分析——攻击者要花多大代价才能得手
- 风险判定——综合影响和可行性，定风险等级
这6步走完，你就能得到安全目标。然后拿着安全目标去找系统工程师，告诉他们：这些必须加进需求里。
避坑指南：我曾经在第三步「威胁场景识别」上卡了整整两周。后来发现是因为团队对攻击者的能力没有统一认知。我的建议是——先建一个攻击者画像，明确攻击者的资源、技能、动机。这样大家讨论时才有共同语言。
3.5 小结：TARA不是终点，是起点
记住一句话：TARA做得好，后面安全开发就顺；TARA做得糙，后面全是坑。
我在多个项目里验证过这个规律。凡是TARA阶段投入足够时间的项目，后面安全测试通过率都高。凡是赶进度、草草了事做TARA的，最后都在测试阶段返工。
所以，别把TARA当成应付审计的文档。它是你整个安全工程的地基。地基稳了，楼才能盖得高。