1. 课程导入
智能网联汽车把原本封闭的机械系统变成了“轮子上的分布式计算平台”。一辆现代智能汽车通常包含 70～150 个电子控制单元（ECU）、多条 CAN/CAN FD 总线、车载以太网骨干、T-Box 远程通信模块、OTA 升级通道以及 V2X 对外接口。功能越丰富，攻击面越大：2015 年两位安全研究员远程入侵 Jeep Cherokee，通过蜂窝网络控制车辆转向与刹车；此后针对无钥匙进入的 Relay Attack、针对 CAN 总线的报文注入、针对 OTA 服务器的供应链攻击层出不穷。车载网络安全验证与审计工程，正是为应对这类风险而生的系统性工程方法。
一、学习目标：从“知道风险”到“能验证、能审计”
本课程的目标不是让学员背诵标准条款，而是建立一套可落地的工程能力。完成学习后，应能达成以下四层目标：
- 概念层：理解资产、威胁、脆弱性、风险、攻击面、信任边界等核心术语，能区分“功能安全”与“信息安全”的不同关注点。
- 标准层：掌握 ISO/SAE 21434 的 TARA 流程、UN R155/R156 的合规要求、ISO 21434 与 ASPICE 的协同关系，以及 GB 44495 等国内强标要点。
- 技术层：能对 CAN、以太网、BLE、Wi-Fi、UWB 等接口开展渗透测试，能使用 SecOC、IDS、防火墙、安全启动等防护机制并验证其有效性。
- 审计层：能设计验证用例、采集并分析日志、编写可追溯的审计报告，支撑车型准入与持续合规。
二、核心概念：验证与审计的区别与联系
“验证（Verification）”回答的是“防护措施是否按设计生效”，偏向技术测试与证据采集；“审计（Audit）”回答的是“过程与证据是否符合标准与法规要求”，偏向流程、文档与可追溯性。二者互为支撑：没有验证证据，审计就是空谈；没有审计框架，验证结果无法形成合规闭环。
其中，TARA（Threat Analysis and Risk Assessment）是贯穿全流程的主线方法，其输出直接决定验证用例的优先级与审计的关注点。
三、整体框架：V 模型下的安全工程闭环
车载网络安全工程遵循典型的 V 模型：左侧从整车级 TARA 出发，逐层分解到系统、ECU、软件与通信矩阵的安全需求；右侧从单元测试、集成测试、整车渗透测试逐层向上验证，最终形成车型安全案例（Security Case）。验证与审计并非只在右侧出现，而是贯穿需求、设计、实现、测试、运维、报废全生命周期。
四、行业背景与典型场景
从法规看，UN R155 要求车企建立网络安全管理体系（CSMS）并获得车型批准，UN R156 要求软件更新管理体系（SUMS）；欧盟自 2022 年 7 月起对新车型强制实施，2024 年 7 月起对所有新注册车辆生效。国内 GB 44495《汽车整车信息安全技术要求》已于 2024 年发布，对整车信息安全提出强制性要求。这意味着网络安全验证与审计不再是“加分项”，而是车型上市的前置条件。
从攻击场景看，典型威胁包括：
| 攻击面 | 典型攻击手法 | 验证重点 | 审计证据 |
|---|---|---|---|
| CAN/CAN FD 总线 | 报文注入、重放、DoS 泛洪 | SecOC 校验、IDPS 告警 | 总线日志、告警记录 |
| T-Box / 远程通信 | 蜂窝接口漏洞、弱口令、固件提取 | 接口加固、证书校验 | 渗透报告、配置基线 |
| OTA 升级通道 | 签名绕过、降级攻击、中间人 | 签名验证、回滚保护 | 升级日志、密钥审计 |
| 无钥匙进入 | Relay Attack、信号重放 | UWB 测距、挑战响应 | 测试用例、复现记录 |
| 诊断接口 OBD | UDS 服务滥用、会话劫持 | 诊断权限、安全访问 | 诊断日志、权限矩阵 |
五、常见误区与复盘要点
误区二：只关注整车，忽略供应链。Tier1/Tier2 的软件组件漏洞同样会传导到整车，审计必须覆盖供应链安全协议与 SBOM。
误区三：验证一次就结束。车辆全生命周期内会经历 OTA、召回、零部件更换，安全状态是动态的，必须持续验证与复审。
复盘时建议围绕三个问题展开：第一，TARA 识别的风险是否都有对应的验证用例？第二，验证发现的漏洞是否都进入闭环管理并完成回归？第三，审计证据链是否可追溯到具体需求、测试记录与责任人？只有这三问都能给出肯定回答，车载网络安全验证与审计才算真正落地。