汽车网络安全 CyberSecurity ISO/SAE 21434 测试之二
一、ISO/SAE 21434 第4章
书接上回，我们在 汽车网络安全 CyberSecurity ISO/SAE 21434 测试之一 中提到过，标准的第4章主要对 ISO/SAE 21434 进行了一个总括性的描述。具体来说，主要包含两个方面，一个是研究对象和范围；一个是提出了风险管理的概念。
简单来说 ，在 21434 标准中，网络安全工程的研究对象被称为item，可翻译为“相关项”，就是车上实现某个功能的电子器件和软件。它包含了一个或多个Component以及其之间的交互和运行环境。Item可以是车辆的E/E架构或实现车辆某个功能的系统。比如特斯拉的自动驾驶系统，或者比亚迪的车载娱乐系统、刹车系统等，都算一个“相关项”。
举个栗子 ：假设你要分析刹车系统的网络安全，那“相关项”就包括刹车的ECU（电子控制单元）、传感器、软件代码，甚至和刹车相关的通信网络。
以上是针对研究对象的说明，就范围来讲，网络安全工程的范围涵盖车辆的全生命周期，因此也包括了售后和服务环节。车辆外部的系统（如后台）在标准中也会涉及，但不是该文件研究的重点。
风险管理是ISO 21434的核心思想。
它要求车企像“防贼”一样，针对不同风险设计多层防护，这就是纵深防御（Defense in Depth）。
就像我们在 汽车网络安全 CyberSecurity ISO/SAE 21434 测试之一 说的HSM一样，它是物理层的防御；同样，我们还会有入侵检测系统IDSM，以及数据安全SecOC。
用通俗的比喻来说，HSM就像是防盗门，IDSM就像是监控摄像头，SecOC就像是保险柜。
举个栗子 ：黑客想偷车，得先撬开防盗门（物理安全），再躲过摄像头（网络防护），最后还得破解保险柜密码（数据加密）——难度直接拉满！
风险管理是一项贯穿产品整个生命周期的持续性活动。
- 在开发阶段，主要关注威胁分析和风险评估以及通过纵深防御缓解网络安全风险；
- 在运维阶段，通过安全监控、漏洞管理和安全事件响应等持续的网络安全活动，处置不断变化的外部环境中出现的安全风险。
- 此外，风险管理活动可针对项目进行相应的适配和裁剪，对于分布式开发的环节，需要明确客户与供应商的网络安全职责。
运维阶段有三个关键动作：
- 一个是安全监控，在内部项目中我们采用的是IDSM，即入侵检测管理系统，实时盯着车里的网络流量、系统日志，发现异常立刻报警。比如有人用异常指令控制刹车。
- 其次是漏洞管理，又分为漏洞扫描、漏洞评估和修复验证三步。
- 最后是安全事件响应，这个主要是万一黑客真黑进了系统，车企得立刻启动应急预案——切断攻击源、修复漏洞、通知车主，甚至召回车辆。
此外，不同项目的风险管理不能“一刀切”。这就是上面所说的适配和裁剪。
大型项目 （比如开发自动驾驶系统）：需要更详细的流程，拉上更多专家一起“找茬”，覆盖更多风险场景。
小型项目 （比如车载音响升级）：可以简化流程，重点盯住几个关键风险（比如防止黑客通过音响系统入侵整车网络）。
二、ISO/SAE 21434 第5章
接下来，咱继续聊 ISO/SAE 21434的第5章——组织级网络安全管理 。这一章的核心是：车企怎么从公司层面建立一套网络安全的“规矩”和“文化” 。
组织级网络安全管理规定了公司/组织层面网络安全管理的要求，是组织内部最高层面的安全方针。标准中从7个方面提出了要求：
1. 网络安全治理
首先是网络安全治理的5大“必做清单”。
（1）领导层必须“真重视”，提升公司整体的车辆网络安全风险管理意识
关键点 ：老板和高管不能只嘴上喊安全，得真金白银投资源 ，比如批预算、招人、买工具。
举个栗子 ：如果领导不重视，下面的人想推动安全流程？门都没有！
（2）流程要“全覆盖”，包括：概念、开发、生产、运维、退役、威胁分析和风险评估、安全监控、信息共享、应急响应
干啥的？ 建立一套网络安全管理体系（CSMS） ，覆盖车辆从设计、生产到报废的每个环节。
包括啥？ 比如：
- 怎么做风险分析（TARA方法论）
- 怎么监控安全事件
- 怎么和行业共享漏洞信息
- 怎么应对黑客攻击
（3）职责要“分清楚”，确保分配职责和授予权限，保障流程落地
关键点 ：不能没人管，也不能所有人管！必须责任到人。
举个栗子 ：张三负责漏洞扫描，李四负责应急响应，王总负责审批安全策略。
（4）资源要“给够”，保证足够的、具备合格能力的人员，合适的工具
资源包括 ：
**人 ：**招够懂网络安全、功能安全、车辆工程的专家
**工具 ：**买漏洞扫描工具、代码检查工具、产线检测设备等
（5）别“另起炉灶”，要“融合”，确保与其他现有流程的结合，比如与V流程结合，同时考虑与功能安全等要求结合
**关键点 ：**别单独搞一套安全流程，直接嵌入现有流程 （比如V模型开发流程）。
**好处 ：**省时省力，还能和功能安全、隐私保护等其他安全要求联动。
2. 网络安全文化
网络安全文化是看不见的“软实力”。关于网络安全文化，有以下几点要求：
（1）建立良好的网络安全文化，文化要“从上到下渗透”
标准中附录B的例子 ：
差文化 ：员工觉得“安全是安全部门的事，跟我无关”。
好文化 ：全员绷紧一根弦，发现漏洞主动上报，开会必提安全。
（2）保证人员足够的网络安全能力和意识：具备相关领域知识、了解常见的攻防，即能力要“硬”
这里涉及到一个员工得会啥的问题。
- 懂网络攻防（比如黑客怎么入侵ECU）
- 会用工具（比如静态代码检查工具）
- 熟悉功能安全和隐私保护法规
当然，实际上在汽车领域，截止当前，很多企业没有招聘懂网络攻防的攻城狮，这部分的工作主要靠外包给一些国内知名的安全团队。
（3）持续改进：别“躺平”
改进来源 ：
- 内部审核发现的问题
- lesson learn/项目经验：其他项目踩过的坑（比如特斯拉被黑的教训）
- 新员工提出的建议
3. 信息共享
信息共享要求组织必须考虑组织内外部哪些数据共享是必须的、允许的，哪些是被禁止的，并根据这个准则去管理与第三方共享的数据。
但安全信息要“加密快递”。怎么管？
分级 ：比如“绝密级”漏洞只限核心团队知道。
工具 ：用加密通信工具传输漏洞细节，防止被黑客截获。
4. 管理系统
组织应建立一个质量管理体系来支撑网络安全工程。包括变更管理（比如软件更新必须经过CCB审批）、文档管理（哪怕车型停产，安全配置信息也得存档10年）、配置管理和需求管理等。
5. 工具管理
- 开发过程中的工具，如静态代码检测工具
- 生产过程中的工具，如产线刷写工具
- 运维阶段的工具，如在线诊断工具
此外，需要注意权限管理，不是谁都允许碰这些工具！
6. 信息安全管理
相关的工作产品应该由一个信息安全管理系统来管理。
- 组织级网络安全审计
审计和输出：最后要交哪些“作业”？
组织应进行网络安全审计，以判断组织的流程是否达到了本标准的要求。有以下几点注意事项：
- 审计人可以来自组织内部或外部，但必须保证审计的独立性
- 网络安全审计可以包含在质量体系的审计中
- 审计可以分阶段进行
以下是必须准备的材料 ：
- 网络安全方针（比如“所有ECU必须加密通信”）
- 员工培训记录（证明大家真学了安全知识）
- 工具管理清单（比如谁有权限使用产线刷写工具）
- 审计报告（第三方检查是否符合21434标准）
三、ISO/SAE 21434 第6章
接下来是ISO/SAE 21434的第6章——项目级网络安全管理 。这一章是车企在具体项目中落地网络安全的“操作指南”。
1. 首先是职责分配：谁该干啥？
关键点 ：责任必须明确，不能“踢皮球”！
比如：张三负责漏洞扫描，李四负责应急响应，王总负责审批安全策略。
责任可以转移 ，但必须提前沟通清楚（比如外包给供应商时，得签协议明确责任）。
2. 网络安全计划：像“旅行攻略”一样详细
三步走 ：
（1）划范围 ：用附录 D 的方法，找出项目中哪些部件涉及网络安全（比如自动驾驶ECU）。
（2）定计划：明确每个阶段的任务、目标、负责人、资源、时间表。比如：
- 概念阶段（第9章）：定义安全目标；
- 开发阶段（第10章）：设计防护措施；
- 验证阶段（第11章）：测试是否达标。
（3）动态调整 ：计划不是一成不变的，发现问题随时更新（比如发现新漏洞就加一条修复任务）。
3. 裁剪原则：别“一刀切”，要灵活！
啥是裁剪？ 根据项目特点简化流程，但得证明“简化后依然安全”。
能裁剪的理由 ：
- 复用旧组件 （比如沿用上一代车型的安全模块）；
- 用现成软件 （比如开源加密库）；
- 小升级 （比如OTA修复漏洞，不用大改流程）。
4. 复用组件：别偷懒，得验证！
举个栗子 ：
如果复用供应商的刹车控制模块，得检查：
- 模块有没有被修改过？
- 是否适配新车的运行环境？
- 是否有新漏洞未修复？
结论 ：复用可以，但得重新验证安全性！
5. 独立组件 vs 现成组件
独立组件 （比如供应商自研的通用模块）：
必须做完整验证 ，确保符合安全要求。
现成组件 （比如第三方地图API）：
检查供应商提供的安全文档，确认能否直接用；如果文档不够，得自己补测试。
6. 网络安全案例：用证据链“自证清白”
干啥的？ 整合所有安全证据（比如测试报告、漏洞修复记录），证明系统真的安全。
分布式开发 ：
客户和供应商各自提供证据，拼成完整的“安全拼图”。
7. 网络安全评估：该不该“考试”？
评估必要性 ：
根据风险高低决定是否做深度测试。比如：
高风险组件（自动驾驶系统）必须评估；
低风险组件（车载音乐播放器）可以跳过，但得写明理由。
评估方式 ：
分阶段测、重复测，甚至补测（比如发现新漏洞后加一轮测试）。
8. 后开发释放：上市前的“最终安检”
关键检查点 ：
- 网络安全案例是否完整；
- 评估报告是否达标；
- 是否满足后续维护的安全要求（比如OTA升级流程）。