3. 资产识别：什么是网络安全资产，如何识别资产，资产分类与分级
做TARA的第一步，不是画数据流图，也不是列威胁场景。
是搞清楚一个问题：你到底要保护什么？
我见过不少团队，上来就对着系统架构图一顿猛分析，结果做到一半发现——连分析对象都没定清楚。说白了，你连资产都没识别出来，后面的威胁分析、风险评定全是空中楼阁。
3.1 什么是网络安全资产
先给个定义：网络安全资产，是指对组织有价值、需要被保护的任何东西。
在汽车领域，这个定义要更具体一些。我个人习惯把它拆成三层：
- 物理层：ECU、传感器、线束、T-Box、网关硬件
- 逻辑层：固件、软件、通信协议、诊断服务、密钥证书
- 数据层：用户隐私数据、车辆识别码、位置轨迹、驾驶行为
你想想看，一个智能座舱域控制器，它的硬件值多少钱？几千块。但里面的用户面部数据、支付凭证、驾驶习惯模型，泄露出去值多少钱？没法估量。
核心观点：资产不是“东西”，是“价值载体”。同一个物理设备，承载不同功能、不同数据，就是不同的资产。
3.2 如何识别资产
识别资产这件事，听起来简单，做起来全是坑。
我记得有一次做某个OEM的TARA，客户说“我们资产很清晰，就是那20个ECU”。结果一深入，发现每个ECU里跑了3-5个不同的软件组件，每个组件处理不同的数据，暴露不同的攻击面。如果只把ECU当资产，那等于把整个分析精度拉到了“城市级别”，而不是“街区级别”。
3.2.1 识别方法：自顶向下 vs 自底向上
| 方法 | 做法 | 适用场景 | 我踩过的坑 |
|---|---|---|---|
| 自顶向下 | 从功能需求出发，逐层分解到组件 | 新平台开发、功能定义清晰 | 容易遗漏底层硬件资产 |
| 自底向上 | 从硬件BOM、软件清单出发，逐层聚合 | 已有系统改造、逆向分析 | 容易陷入细节，忽略功能层面的资产 |
我现在的做法是：两条腿走路。先用自顶向下画出功能架构，再用自底向上核对物理清单。两边对不上？那就是资产识别有遗漏。
3.2.2 识别步骤
- 收集输入：系统架构图、软件组件清单、通信矩阵、功能规范、数据字典
- 功能分解：把整车功能拆成系统功能、子系统功能、组件功能
- 物理映射：每个功能落在哪些硬件上？跑在哪个软件栈里？
- 数据标注：每个功能处理什么数据？数据流向哪里？存储在哪里？
- 资产登记：形成资产清单，每个资产至少包含：ID、名称、类型、所属功能、安全属性
小技巧：资产ID的命名规则要统一。我习惯用 [功能缩写]-[组件名]-[序号]，比如 BCM-Flash-001。这样后期做威胁分析时，一眼就能看出资产归属。
3.3 资产分类
资产识别出来之后，不能堆在一起。得分类。
为什么？因为不同类型的资产，威胁场景、攻击路径、风险等级都不一样。你不可能用分析网关的方法去分析一个传感器。
3.3.1 按资产性质分类
| 类别 | 示例 | 安全关注点 |
|---|---|---|
| 硬件资产 | ECU、传感器、执行器、线束 | 物理篡改、侧信道、调试接口 |
| 软件资产 | Bootloader、OS、中间件、应用 | 代码注入、固件篡改、回滚攻击 |
| 数据资产 | 密钥、证书、用户隐私、诊断数据 | 泄露、篡改、重放、抵赖 |
| 通信资产 | CAN/LIN/Ethernet 报文、服务调用 | 伪造、拦截、重放、拒绝服务 |
3.3.2 按安全属性分类
这个分类方式，是TARA特有的。每个资产都要问：它的CIA属性是什么？
- C - 机密性：数据不能被未授权方读取。比如密钥、用户隐私
- I - 完整性：数据不能被未授权方篡改。比如固件、标定数据
- A - 可用性：系统在需要时必须可用。比如制动控制、转向控制
嗯，这里要注意：不是所有资产都同时需要CIA。一个温度传感器，完整性比机密性重要得多。一个车载娱乐系统，可用性优先级可能没那么高。
避坑指南：我曾经见过一个团队，把所有资产都标成“高机密性+高完整性+高可用性”。结果威胁分析做出来全是高风险，根本没法排优先级。资产的安全属性，一定要基于实际功能场景来定。
3.4 资产分级
分类是分类型，分级是分重要性。
资产分级的目的很简单：把有限的资源，投入到最重要的资产上。
3.4.1 分级维度
我个人习惯用三个维度来打分：
- 功能安全等级：ASIL等级越高，资产重要性越高
- 数据敏感度：涉及隐私、支付、身份认证的数据，等级高
- 攻击影响面：被攻击后影响多少功能、多少用户
3.4.2 分级示例
| 等级 | 描述 | 典型资产 |
|---|---|---|
| L1 - 关键 | 安全相关，失效直接导致人身伤害 | 制动控制器、转向控制器、安全气囊ECU |
| L2 - 重要 | 功能相关，失效导致车辆功能丧失 | 网关、域控制器、T-Box |
| L3 - 一般 | 体验相关，失效影响用户体验 | 娱乐系统、空调控制器、氛围灯 |
| L4 - 低 | 辅助相关，失效几乎无影响 | 诊断日志、非关键传感器 |
经验之谈：分级不是一成不变的。同一个ECU，在不同车型、不同配置下，等级可能不同。比如一个网关，在L2级自动驾驶车型上是L1级资产，在基础款车型上可能只是L2级。每次做TARA，都要重新审视分级。
3.5 资产识别全景图
说了这么多，我画了一张图，把资产识别的整个逻辑串起来。你一看就明白了。
3.6 常见误区与避坑
做资产识别这么多年，我总结了几条最常见的坑：
误区一：只识别硬件，忽略软件和数据
我曾经参与过一个项目，客户给的资产清单只有ECU列表。结果做威胁分析时发现，真正的攻击目标其实是OTA升级包和用户隐私数据。硬件只是载体，不是资产的全部。
误区二：资产粒度太粗或太细
太粗：把整个车机当成一个资产。太细：把每个函数、每个变量都当成资产。我的建议是：以“可独立更新/可独立攻击”的单元为最小粒度。一个固件镜像是一个资产，一个CAN报文是一个资产，一个诊断服务是一个资产。
误区三：资产清单做完就不管了
资产是会变的。软件升级、功能新增、硬件变更，都会影响资产清单。我建议把资产识别做成一个持续活动，每次变更都触发一次资产清单的更新。
我的习惯：每个项目开始前，先花半天时间做资产识别。拉上系统工程师、软件工程师、功能安全工程师一起过。人多眼杂，容易发现遗漏。资产清单出来后，贴在墙上，每天看一眼。你会发现，很多威胁分析的问题，在资产识别阶段就已经暴露了。