2、项目定义与资产识别：确定TARA范围、识别系统边界、定义安全目标、识别关键资产
好，咱们正式开始干TARA的第一步。很多新手一上来就急着找漏洞、列攻击树，结果做到一半发现范围没定清楚，资产漏了一堆，又得回头重来。我见过好几个项目，就是因为这一步没走稳，后面评审被安全审计追着问“你这个边界怎么划的？这个资产为什么不算？”——场面一度很尴尬。
说白了，项目定义和资产识别就是给整个TARA画个圈、打个地基。圈画歪了，地基打浅了，后面盖的楼再漂亮也白搭。今天我就带你把这个圈画明白。
2.1 确定TARA范围：先画圈，再干活
TARA范围不是拍脑袋定的。你得先搞清楚：咱们这次分析的是哪个系统？是整车级、系统级、还是零部件级？范围定得太宽，分析工作量爆炸；定得太窄，关键风险全漏了。
我个人习惯用“三要素法”来锁定范围：
- 系统边界：物理边界在哪？逻辑边界在哪？通信边界在哪？
- 运行场景：车辆在什么状态下分析？行驶中、充电中、还是停车休眠？
- 生命周期阶段：是开发阶段、生产阶段、还是售后运维阶段？
关键原则：TARA范围必须与项目开发范围对齐。如果项目只做T-Box，你就别把整个车联网的安全分析都揽进来。范围越大，资产越多，分析越浅，最后反而容易漏掉真正要命的东西。
我在一个OEM的项目里遇到过这种情况：客户要求对“智能座舱系统”做TARA，结果他们把中控屏、仪表盘、后排娱乐、语音助手、甚至手机互联全塞进来了。我一看，这哪是TARA，这是要写百科全书。后来我建议他们按功能模块拆成三个独立的TARA，每个模块单独定范围、单独出报告。评审一次过，效率翻倍。
2.2 识别系统边界：把墙砌清楚
系统边界就是你的“安全责任田”。边界画清楚了，你才知道哪些东西归你管，哪些东西是外部环境。
边界通常分三层：
| 边界类型 | 描述 | 典型例子 |
|---|---|---|
| 物理边界 | 硬件模块的物理接口、外壳、线束 | ECU外壳、CAN总线接口、以太网接口 |
| 逻辑边界 | 软件进程、虚拟机、域隔离 | Hypervisor分区、容器、安全域 |
| 通信边界 | 网络协议、数据链路、消息格式 | CAN ID范围、SOME/IP服务、MQTT主题 |
你想想看，如果连边界都画不清楚，你怎么判断一个攻击是从外部进来的还是内部扩散的？
小技巧：画边界的时候，我习惯先画一张“系统上下文图”（System Context Diagram）。把目标系统放在中间，外部实体（人、云端、其他ECU、诊断工具）放在外面，箭头标出数据流。这张图画完，边界自然就出来了。
2.3 定义安全目标：从“要防什么”到“要做到什么”
安全目标不是“我们要安全”，那是废话。安全目标必须是可验证、可测试的。
ISO 21434里安全目标通常长这样：
- “防止未授权的远程控制”——太模糊，没法测。
- “当车辆处于行驶状态时，远程诊断接口不得执行写操作”——这个就能测。
我一般把安全目标拆成三个维度：
- 威胁场景：什么情况下会发生什么坏事？
- 防护措施：我们要做什么来阻止它？
- 验证标准：怎么证明我们做到了？
注意：安全目标不是拍脑袋定的。它必须来自TARA的威胁分析结果。换句话说，先有威胁，后有目标。别反过来——先定目标再去找威胁，那是本末倒置。
我记得有一次，一个团队在项目启动会上就写好了安全目标，然后让我帮忙做TARA。我一看，目标写得挺漂亮，但跟实际系统完全不搭。我问他们：“你们这个目标对应的威胁是什么？”他们答不上来。最后只能推倒重来，白白浪费了两周。
2.4 识别关键资产：数据、功能、硬件、软件
资产识别是TARA里最费功夫的一步，也是最容易出错的一步。很多人只盯着数据资产，把功能、硬件、软件全忘了。
ISO 21434里资产分四大类：
| 资产类型 | 定义 | 典型例子 |
|---|---|---|
| 数据资产 | 存储或传输的信息 | 用户隐私数据、车辆VIN、加密密钥、诊断日志 |
| 功能资产 | 系统提供的服务或能力 | 自动紧急制动（AEB）、远程解锁、OTA升级 |
| 硬件资产 | 物理组件 | ECU、传感器、执行器、HSM安全芯片 |
| 软件资产 | 代码、固件、配置 | Bootloader、操作系统、应用软件、安全策略配置 |
识别资产的时候，我建议你用“功能分解法”：
- 先把系统功能拆成最小功能单元（比如“远程解锁”是一个功能单元）。
- 每个功能单元背后，列出它依赖的数据、硬件、软件。
- 把这些列出来的东西全部登记到资产清单里。
举个例子，“远程解锁”这个功能：
- 数据资产：用户身份凭证、解锁指令、车辆状态信息
- 功能资产：远程解锁服务本身
- 硬件资产：T-Box通信模块、BCM车身控制器
- 软件资产：T-Box固件、BCM固件、云端解锁服务API
你看，一个简单的功能，背后就牵出这么多资产。要是只盯着数据，那硬件和软件的风险就全漏了。
避坑指南：我曾经在一个项目里，团队只识别了“数据资产”，结果评审的时候安全专家问：“你们这个ECU的Bootloader有没有安全漏洞？”他们答不上来，因为Bootloader是软件资产，根本没在清单里。后来补了30多个资产，TARA报告重写了三分之一。
2.5 知识结构图：项目定义与资产识别全景
下面这张图把整个流程串起来了。你可以把它当成一张“导航地图”，做TARA的时候随时回来看一眼，别走偏了。
2.6 资产清单模板：拿来就能用
最后，我给你一个我项目里一直在用的资产清单模板。每次做TARA，我先把这张表填完，再往下走。你直接复制用就行。
| 资产ID | 资产名称 | 资产类型 | 所属功能 | 安全属性（C/I/A） | 备注 |
|---|---|---|---|---|---|
| A-001 | 用户身份凭证 | 数据 | 远程解锁 | C, I | 存储在T-Box安全存储区 |
| A-002 | 远程解锁服务 | 功能 | 远程解锁 | A, I | 依赖云端和T-Box通信 |
| A-003 | T-Box通信模块 | 硬件 | 远程解锁 | A | 4G/5G模块 |
| A-004 | T-Box固件 | 软件 | 远程解锁 | I | 版本v2.3.1 |
| A-005 | 车辆VIN | 数据 | 车辆身份识别 | C, I | 唯一标识 |
| A-006 | AEB功能 | 功能 | 自动紧急制动 | A, I | 功能安全ASIL-D相关 |
我的习惯：资产ID用“A-三位数字”的格式，方便后面做威胁分析和风险计算时引用。别用中文名当ID，Excel排序会乱，你试试就知道了。
好了，项目定义和资产识别这块就讲到这里。记住一句话：范围定清楚，边界画明白，目标有依据，资产全覆盖。这四步走稳了，后面的威胁分析和风险计算就是水到渠成的事。