4、攻击路径分析：攻击树（Attack Tree）的绘制、攻击路径的量化评估、攻击可行性分析
攻击路径分析，说白了就是回答一个问题：攻击者到底能不能打进来？
我在做TARA项目时，见过不少团队把威胁场景写得天花乱坠，但一到攻击路径就卡壳了。要么画得过于抽象，要么路径多到没法看。其实，攻击树就是帮你把「攻击者怎么一步步达成目标」这件事，变成一张可视化的逻辑图。
4.1 攻击树的核心逻辑
攻击树是一种树形结构。根节点是攻击者的最终目标，子节点是达成目标需要满足的条件。节点之间有两种关系：
- AND关系：所有子条件必须同时满足，攻击才能成功。
- OR关系：任意一个子条件满足，攻击就能成功。
举个例子。攻击者的目标是「远程控制车辆制动系统」。那子节点可能是：
- OR：通过T-Box远程注入 / 通过蓝牙近距离注入
- AND（如果走T-Box）：突破防火墙 + 获取CAN总线访问权限 + 发送制动指令
嗯，这里要注意：攻击树不是越细越好。我见过有人把「打开车门」拆成「左手拉把手」和「右手拉把手」，这就过度设计了。攻击树的粒度，应该跟你的资产颗粒度对齐。
核心原则：攻击树的叶子节点，必须是可量化、可测试的攻击动作。比如「发送特定CAN ID报文」比「利用漏洞」更具体。
4.2 攻击树的绘制方法
我个人习惯用自顶向下的方式画。先定根目标，再逐层分解。工具方面，Visio、draw.io、甚至纸笔都行。但关键不是工具，是逻辑。
画攻击树时，我建议你遵循这四步：
- 定义根节点：攻击者的最终目标是什么？比如「窃取用户隐私数据」。
- 识别攻击入口：攻击者从哪里进来？外部接口、无线通信、物理端口？
- 分解攻击步骤：每一步需要什么条件？需要什么权限？
- 标注AND/OR关系：明确节点间的逻辑关系。
我曾经在一个项目中，团队画了整整三天的攻击树，结果发现根节点定义错了——他们把「车辆被盗」当成了目标，但实际应该分析的是「攻击者如何绕过防盗系统」。所以，根节点一定要跟威胁场景严格对应。
避坑指南：我曾经在画攻击树时，把「物理访问」和「远程访问」混在一个分支里，导致后续量化评估完全没法做。后来我强制要求：不同攻击向量必须分叉画，物理路径和网络路径不要混在一起。
4.3 攻击路径的量化评估
光画树不够，你得知道每条路径到底有多难。量化评估，就是给每条攻击路径打分。
常用的量化维度包括：
| 维度 | 说明 | 常见评分（1-5） |
|---|---|---|
| 攻击成本 | 攻击者需要投入多少资源（金钱、设备、人力） | 1=极低（免费工具），5=极高（专用设备+团队） |
| 攻击难度 | 攻击者需要多高的技术水平 | 1=脚本小子，5=国家级APT |
| 攻击时间 | 从开始到成功需要多久 | 1=几分钟，5=数月 |
| 检测概率 | 攻击过程中被安全机制发现的概率 | 1=几乎不会被发现，5=极易被发现 |
你想想看，如果一条路径的攻击成本是1，难度是1，时间也是1，那基本就是「裸奔」状态。反之，如果成本5、难度5、时间5，那攻击者大概率会放弃。
我习惯用加权求和的方式算总分。比如：
攻击可行性 = 攻击成本 × 0.3 + 攻击难度 × 0.4 + 攻击时间 × 0.2 + (6 - 检测概率) × 0.1注意，检测概率是反向指标——检测概率越高，攻击可行性越低，所以用6减去它。
重要提醒：量化评估不是数学考试。分数只是参考，最终判断还是要结合业务场景。我曾经见过一个项目，某条路径量化得分很低，但攻击者就是通过那条路径攻进来了——因为攻击者根本不在乎成本。
4.4 攻击可行性分析
量化评估之后，就是判断这条攻击到底能不能发生。攻击可行性分析，说白了就是回答三个问题：
- 攻击者有没有动机？
- 攻击者有没有能力？
- 攻击者有没有机会？
这三个问题缺一不可。举个例子，攻击者有能力也有机会，但没动机——比如攻击者是个白帽子，他根本不想搞破坏。那这条路径的可行性就是0。
我建议用攻击可行性矩阵来做最终判断：
| 动机 | 能力 | 机会 | 可行性结论 |
|---|---|---|---|
| 高 | 高 | 高 | 极高风险，必须处理 |
| 高 | 高 | 低 | 中等风险，可监控 |
| 高 | 低 | 高 | 低风险，攻击者可能放弃 |
| 低 | 高 | 高 | 低风险，缺乏动机 |
为什么会这样？因为攻击者也是理性的。如果动机不足，哪怕能力再强，他也不会动手。反过来，动机再强，能力不够也是白搭。
实战经验：我在做某个OEM的TARA时，发现一条攻击路径的量化得分很高，但攻击可行性分析显示「动机低」。后来跟业务方一聊，发现那个功能只在实验室环境下使用，量产车根本不会部署。所以，攻击可行性分析一定要结合业务上下文，不能只看数字。
4.5 攻击树与攻击路径的SVG结构图
下面这张图展示了攻击树的核心结构、量化评估流程以及可行性分析的逻辑关系。你可以把它当作本章的知识骨架。
4.6 实战中的常见误区
最后，我总结几个我在项目中踩过的坑，希望能帮你少走弯路。
- 误区一：攻击树画得太完美。现实中攻击路径往往有交叉，攻击树不可能覆盖所有可能性。别追求完美，够用就行。
- 误区二：量化评估只看总分。总分低不代表安全。如果某个维度（比如攻击成本）是1，其他维度再高，攻击者也可能赌一把。
- 误区三：忽略攻击者的学习曲线。攻击难度不是一成不变的。今天难，明天可能就简单了。所以攻击可行性分析要定期更新。
我的习惯：每次做完攻击路径分析，我都会问自己一个问题——「如果我是攻击者，我会选哪条路？」然后顺着那条路再走一遍，往往能发现遗漏的细节。
攻击路径分析不是一次性的工作。随着系统迭代、新漏洞曝光、攻击技术演进，你的攻击树和量化评估都需要跟着更新。保持动态，才能让TARA真正落地。