1. ISO21434概述：标准背景与目标、适用范围、与其他标准的关系（如ISO26262）、核心术语定义

大家好，我是老张。在汽车行业摸爬滚打了十几年，从最早的CAN总线刷写，到后来的功能安全，再到现在的网络安全，一路走来感触挺深。今天咱们聊聊ISO21434这个标准。说实话，我第一次看到这个标准草案时，心里想的是「又来一个要学的」。但真正落地做项目后，我发现它其实没那么玄乎。

为什么会有ISO21434？说白了，就是车联网时代来了，汽车不再是孤立的机械产品。你想想看，现在的车有多少个ECU？少则几十，多则上百。再加上T-Box、网关、OTA升级，攻击面一下子大了很多。

我记得2015年做过一个项目，客户要求做远程诊断功能。当时团队里没人考虑网络安全，结果测试阶段发现，通过OBD接口居然能直接刷写发动机控制器固件。嗯，这要是被恶意利用，后果不堪设想。

ISO21434的目标很明确：建立一套覆盖汽车全生命周期的网络安全管理体系。从概念阶段到产品开发，再到生产、运维、报废，每个环节都要考虑网络安全。

核心目标拆解：

这个标准覆盖的范围挺广的。我习惯把它分成三个维度来看：

这里有个容易混淆的点：ISO21434不直接覆盖零部件本身，而是覆盖与网络安全相关的活动和工件。举个例子，一个ECU的硬件设计本身不归这个标准管，但它的安全启动、安全通信机制就属于标准范围。

我的经验：在实际项目中，我建议把Tier 1和Tier 2的供应商都拉进网络安全工作流里。曾经有个项目，我们只要求Tier 1做安全分析，结果Tier 2提供的芯片有硬件后门，差点导致项目延期。供应链安全，真的不能省。

说到ISO21434，就不得不提ISO26262。这两个标准是什么关系？我经常被问到这个问题。

简单来说：ISO26262管「安全」，ISO21434管「安保」。前者防止随机硬件失效和系统性故障，后者防止恶意攻击。但两者在方法论上有很多相似之处。

关键区别：

我在项目中遇到过这样的情况：一个ADAS系统，功能安全要求ASIL D，网络安全要求CAL 4。两个团队各自做分析，结果发现安全机制和安保机制有冲突。比如，功能安全要求冗余校验，但网络安全要求加密传输，两者叠加导致延迟超标。后来我们专门建立了联合评审机制，才把问题解决。

除了ISO26262，ISO21434还和以下标准有交集：

搞懂术语，是落地第一步。我挑几个最关键的说说：

保护车辆及其组件免受网络威胁的能力。注意，这里强调的是「能力」，不是「状态」。也就是说，你要证明你有这个能力，而不是说你的车绝对安全。

针对特定威胁场景，你要达到的安全状态。比如「防止通过CAN总线注入恶意消息」。这个目标要可验证、可测试。

实现网络安全目标的方案。包括安全机制、架构设计、技术选型等。我习惯用表格来梳理：

任何与网络安全相关的异常情况。不一定是攻击成功，也可能是尝试攻击被检测到。我在项目中要求团队记录所有事件，哪怕只是IDS报了个警。这些数据对后续的威胁分析很有价值。

避坑指南：我曾经犯过一个错误，把「网络安全事件」和「功能安全故障」混在一起管理。结果安全团队和安保团队互相推诿，问题定位花了三周。后来我强制要求分开记录，但建立关联机制。这样既清晰，又不遗漏信息。

证明你的产品满足网络安全目标的证据集合。包括分析文档、测试报告、评审记录等。这个案例要贯穿整个生命周期，不是做完就扔的。

好了，这一章的内容就这些。记住一句话：ISO21434不是束缚，而是帮你系统化地做安全。下一章我们聊聊如何搭建网络安全管理体系，那是落地的第一步。