ISO SAE 21434：每个汽车零件都是攻击面
读完你能理解汽车网络安全工程标准的核心框架，以及它如何改变整个供应链的游戏规则。
2021 年 8 月，ISO/SAE 21434 正式发布。这不是一份建议性的白皮书，而是汽车网络安全工程的强制性标准——它定义了从概念设计到退役报废，汽车产品在每个生命周期阶段必须满足的网络安全要求。
如果说 ISO 26262 解决的是「车不能自己出故障」，ISO/SAE 21434 解决的是「车不能被别人搞出故障」。
最大的误解
大多数人对汽车网络安全的认知停留在「车联网才会被攻击」。这个想法在五年前还勉强成立，但 21434 彻底打破了它。
标准不关心你的产品是智能座舱还是门把手，它只关心一件事：这个组件是否存在网络安全威胁场景。只要存在，就必须执行 TARA（威胁分析与风险评估）。这意味着一个传统 Tier 1 供应商生产的车窗控制器、座椅调节模块、方向盘锁——这些过去完全不涉及信息安全的产品——现在都必须逐个进行威胁分析。
这个变化的本质是：网络安全不再是一个技术附加题，而是一道准入门槛。
TARA：威胁分析的核心方法论
TARA 是 21434 中最核心的技术方法。它不是一个模糊的安全审计，而是一套结构化的评估流程，分为四步：
识别资产：明确被分析对象中哪些信息或功能具有安全价值。一个 ECU 的资产可能包括固件代码、标定数据、通信密钥、控制指令。
识别威胁场景：针对每项资产，分析可能的攻击方式。例如固件可能被逆向提取，通信密钥可能被侧信道攻击泄露，控制指令可能被重放。
评估影响等级：从四个维度打分——安全影响（是否危及人身）、财务影响、操作影响、隐私影响。取最高分作为该威胁场景的影响等级。
评估攻击可行性：同样从四个维度打分——攻击向量（远程还是物理接触）、所需专业技术、所需设备和工具、攻击所需时间窗口。综合评估后得出可行性等级。
影响等级和可行性等级交叉，就得到该威胁场景的风险等级。风险等级越高，所需的缓解措施就越严格。
TARA 的真正价值不在于填完这张表，而在于迫使工程师系统性地思考攻击面。很多团队在做完第一次 TARA 后才发现，自己设计的产品存在从未考虑过的攻击路径。一个只有 CAN 接口的 ECU，看似攻击面很小，但诊断通道（UDS）的刷写功能、标定接口、甚至唤醒/休眠的网络管理报文，都可能成为攻击入口。
CSMS：组织级的网络安全管理
21434 不只规定了产品该怎么做，还规定了组织该怎么做。标准要求企业建立 CSMS（Cyber Security Management System，网络安全管理系统），这是一个贯穿组织层面的管理框架，核心包括：
- 网络安全政策：组织对产品网络安全的总体方针和原则
- 网络安全治理：明确角色职责、决策流程和汇报机制
- 风险管理：在组织层面识别和管理网络安全风险
- 事件响应：建立漏洞监控、事件响应和持续改进的闭环机制
- 能力保障：确保人员具备网络安全知识和技能，工具链支撑安全活动
CSMS 的关键在于它不是一次性的认证，而是持续运行的管理过程。标准要求在整个产品生命周期的每个阶段都产出可审计的工作成果（Work Products），包括网络安全目标、概念阶段的安全声明、验证确认报告等。没有这些可审计的证据，OEM 无法向监管机构证明产品的网络安全合规性。
对于习惯了 AUTOSAR 功能安全流程的团队来说，CSMS 的很多概念并不陌生——它的组织架构与功能安全管理（FSMS）高度相似。但两者有一个根本区别：功能安全的危害分析是一次性的，而网络安全威胁是持续演化的。
今天安全的设计，明天可能因为新的攻击技术而失效。CSMS 必须具备持续监控和响应新威胁的能力。
供应链：能力必须传递
21434 最深远的影响不在 OEM，而在供应链。当 OEM 被要求对整辆车的网络安全负责时，它必须确保所有供应商都具备相应的网络安全能力。这意味着 OEM 会反过来审核 Tier 1 和 Tier 2 供应商。
供应商审核通常聚焦在四个维度：
- 能力成熟度：是否建立了网络安全管理流程，还是在临时应对
- 流程一致性：网络安全活动是否覆盖了标准要求的全部生命周期阶段
- 工具链支撑：是否有成熟的工具支持 TARA 分析、安全需求管理、漏洞监控等关键活动
- 事件响应能力：发现新漏洞时，能否在合理时间内完成评估和响应
一个残酷的现实是：很多供应商在功能安全领域有深厚积累，但在网络安全领域几乎是白纸。功能安全的流程和工具不能直接复用——它们的设计目标是防止随机硬件失效和系统性设计错误，而不是抵御蓄意攻击。供应商需要从零建立独立的网络安全流程，培养专业人员，升级工具链。能力不达标的供应商，面临被 OEM 淘汰的风险。
技术落地：从分析到实现
做完 TARA、建好 CSMS 之后，最终还是要落到产品实现上。汽车网络安全的技术方案集中在几个层面：
硬件层：HSM（Hardware Security Module）是信任根，提供密钥存储、加密运算和真随机数生成。没有 HSM，所有的软件安全方案都建立在沙滩上。
启动层：Secure Boot 确保固件完整性——从 Bootloader 到应用程序，逐级验证签名，任何一级被篡改都会被拒绝执行。
通信层：SecOC 在 CAN/LIN 等低带宽总线上提供轻量级认证，通过截断的 MAC 和 Freshness Value 防止消息伪造和重放。以太网通信则使用标准的 TLS/DTLS。
这些模块在 AUTOSAR 的 BSW 中已有标准化实现——加密服务（CS）模块提供统一的加解密接口，密钥管理（CryIf）抽象底层 HSM 的差异，SecOC 模块直接集成在 车载网络 通信栈中。
监控层：IDS（入侵检测系统）监控总线和网络流量中的异常行为——频率异常的报文、非法的诊断请求、不在白名单内的通信模式。
更新层：OTA 安全更新需要完整的签名验证机制，同时支持更新失败时的安全回滚。
法规倒逼：合规时间线
联合国法规 UN R155 和 UN R156 在欧盟已经强制执行。进入欧盟市场的车辆必须具备网络安全管理体系（UN R155）和软件更新管理体系（UN R156）。新车从 2024 年 7 月起强制执行，所有在产车从 2026 年 7 月起强制执行。
中国工信部也在推进汽车信息安全技术要求的国家标准，美国 NHTSA 同样发布了网络安全最佳实践指南。方向是确定的：汽车网络安全合规正在从「可选项」变成「市场准入条件」。
对于 Tier 1 供应商而言，这意味着一个不可回避的结论：无论产品技术复杂度如何，网络安全能力已经成为获得订单的前提条件。那些认为「我的产品很简单，不需要信息安全」的供应商，正在失去进入新项目的资格。
网络安全不是一张可以外包的证书，而是一种必须内化到组织 DNA 中的能力。越早开始建设，代价越小。