资产识别与分类：如何定义网络安全资产
做TARA分析，第一步就是搞清楚：你到底在保护什么？
很多人一上来就画数据流图、找威胁场景，结果做到一半发现资产没定义清楚，又回头返工。我见过好几个项目，就是因为资产清单漏了某个ECU的调试接口，最后审计时被开了严重不符合项。
说白了，资产识别是TARA的地基。地基歪了，上面盖的楼再漂亮也没用。
什么是网络安全资产？
在ISO 21434语境下，网络安全资产不是指「值多少钱的东西」，而是指需要被保护、一旦受损会影响车辆安全或用户隐私的任何对象。
我个人习惯把资产分成三类：
- 功能资产：能执行某个功能的实体，比如ECU、传感器、执行器
- 数据资产：存储或传输的信息，比如密钥、用户身份、诊断日志
- 接口资产：功能资产之间的通信通道，比如CAN总线、以太网链路、蓝牙连接
关键判断标准：如果一个对象被破坏（机密性、完整性、可用性受损），会导致车辆安全风险或用户隐私泄露，那它就是网络安全资产。
举个例子。一个雨量传感器，本身可能不值几个钱。但如果攻击者通过它注入虚假数据，导致雨刮器在晴天疯狂工作——嗯，这不算安全事件。但如果攻击者通过传感器漏洞进入车内网络，进而控制刹车系统——那这个传感器就是网络安全资产。
资产的价值评估：怎么判断它「值不值得保护」？
资产价值评估，不是让你去查物料成本。在TARA里，资产价值取决于受损后造成的后果严重程度。
我通常用三个维度来打分：
| 维度 | 说明 | 评分参考（1-5） |
|---|---|---|
| S（安全） | 资产受损是否直接导致人员伤亡 | 5=致命伤害，1=无影响 |
| P（隐私） | 是否涉及个人身份、位置、生物特征等敏感数据 | 5=大规模泄露，1=无隐私数据 |
| F（财务） | 是否造成车企或用户的经济损失 | 5=巨额索赔/召回，1=无损失 |
打分时要注意：不是所有资产都要打满分。我曾经遇到一个团队，把所有ECU的安全维度都打了5分，理由是「万一呢？」——结果导致风险评估完全失效，所有资产都是高风险，等于没有风险。
我的建议：先做一轮粗筛，把明显不涉及安全、隐私、财务的资产排除掉。比如一个车内氛围灯控制器，安全维度打1分，隐私维度打1分，财务维度打1分——那它就不值得花大量精力做TARA。
资产分类方法：软件、硬件、数据
ISO 21434没有强制要求资产分类方式，但我在实际项目中总结了一套好用的分类法。你想想看，一个车联网系统里，资产无非就这三类：
1. 硬件资产
硬件资产是物理存在的。包括：
- ECU、传感器、执行器
- 网关、T-Box、域控制器
- 调试接口（OBD、JTAG、UART）
- 安全芯片（HSM、TPM）
硬件资产的价值评估，重点看物理访问可行性和接口暴露程度。一个藏在座舱深处的ECU，和直接暴露在车底的传感器，风险等级完全不同。
2. 软件资产
软件资产包括固件、操作系统、应用程序、中间件等。我习惯再细分成：
- 基础软件：Bootloader、OS、Hypervisor
- 应用软件：ADAS算法、IVI应用、V2X协议栈
- 配置数据：标定参数、VIN码、网络配置
避坑指南：我曾经见过一个项目，把「OTA升级包」当作普通数据资产处理，结果审计时被指出——OTA升级包涉及完整性和来源认证，应该作为关键软件资产，单独评估其签名验证机制。
3. 数据资产
数据资产是最容易被忽视的。很多人只关注ECU和代码，忘了数据本身也是资产。常见的数据资产包括：
- 密钥和证书（私钥、对称密钥、CA证书）
- 用户隐私数据（位置、驾驶行为、生物特征）
- 诊断和日志数据（DTC、事件记录）
- 通信数据（CAN报文、以太网帧、V2X消息）
数据资产的价值评估，重点看机密性和完整性要求。比如私钥泄露，整个PKI体系就废了；诊断日志被篡改，事故溯源就不可信了。
资产分类的实战流程
我在项目里通常按以下步骤走：
- 列出所有功能实体：从系统架构图里，把每个ECU、传感器、执行器列出来
- 识别每个实体的数据流：输入什么数据？输出什么数据？存储什么数据？
- 标注接口和协议：每个数据流走的是什么总线？用什么协议？
- 分类打标签：硬件/软件/数据，并标注安全、隐私、财务维度的初步评分
- 评审和确认：和系统工程师、功能安全工程师一起过一遍，确保没有遗漏
核心原则：资产清单不是一次性的。每次架构变更、功能新增、供应链切换，都要重新审视资产清单。我习惯在项目里程碑节点（如需求冻结、设计评审、集成测试前）做一次资产清单刷新。
资产识别与分类的SVG框架图
下面这张图是我自己总结的资产识别与分类框架，你可以直接用在项目文档里：
常见误区与避坑指南
做了这么多年TARA，我总结了几条资产识别阶段的常见坑：
我曾经在一个项目里，团队把「OTA服务器」当作外部实体直接排除在资产清单外。结果审计时被指出——OTA服务器虽然不在车上，但它和T-Box之间有加密通信通道，这个通道的密钥管理本身就是资产。后来我们补了一份「外部依赖资产清单」，才算过关。
- 误区一：只列ECU，不列数据——数据资产往往比硬件更容易被攻击，也更容易被忽略
- 误区二：所有资产打同样的分——这样会导致风险评估失去区分度，无法聚焦高价值资产
- 误区三：资产清单做完就不管了——架构变更、功能OTA升级、供应链切换，都会引入新资产或改变资产属性
- 误区四：忽略接口和协议——CAN总线、以太网链路、蓝牙连接本身也是资产，它们的可用性和完整性同样重要
我的习惯：每次项目启动时，先花半天时间和系统工程师一起过一遍架构图，把每个方框、每条连线都问一遍：「这个是什么？它存了什么数据？它和谁通信？如果它坏了会怎样？」——这样过一遍，资产清单基本不会漏。
资产识别与分类，说白了就是搞清楚「你要保护什么」以及「它值不值得保护」。这一步做扎实了，后面的威胁分析、风险评估才能有的放矢。别急着往下走，先把资产清单打磨好。