ISO/SAE 21434网络安全落地实施策略与认证深度解读

从网络安全工程、TARA 到 CSMS 与评估认证的系统化方法

图 1：演示文稿封面

一、执行摘要

ISO/SAE 21434:2021 是面向道路车辆网络安全工程的国际标准，定义了道路车辆语境下网络安全风险管理的工程要求，并覆盖车辆 E/E 系统从概念、开发、生产、运行、维护到退役的整个生命周期。[1]

本报告将 ISO/SAE 21434 的落地理解为一套由 CSMS、项目网络安全管理、TARA、网络安全概念、产品安全开发、供应链协同、持续网络安全活动和网络安全案例共同构成的证据化体系。它不是项目末期补做渗透测试，也不是集中准备模板，而是把网络安全风险管理嵌入产品生命周期和组织治理机制。

认证或客户方评估关注的核心，是组织过程是否真实运行、项目证据是否连续一致、TARA 是否充分、网络安全需求与架构对策是否可验证、漏洞和事件响应是否闭环，以及网络安全案例是否能够解释为什么残余风险可接受。

二、标准定位与生命周期范围

图 2：标准定位与生命周期范围

ISO 官方页面说明，ISO/SAE 21434:2021 定义道路车辆语境下网络安全风险管理的工程要求，并适用于车辆 E/E 系统的整个生命周期，从概念和开发到生产、运行、维护和退役。[1]

该标准的落地对象不是单个安全产品，也不是单一渗透测试活动，而是覆盖软件、硬件、通信接口、组件交互和供应链工作产品的工程化风险管理体系。MathWorks 技术资料也指出，ISO/SAE 21434 不强制具体方法或对策，而是定义需要持续产生和更新的活动与工作产品，以作为充分风险管理的证据。[2]

ISO/SAE 21434 与 ISO 26262 是互补关系。ISO 26262 关注由 E/E 系统失效导致的功能安全风险，ISO/SAE 21434 关注面向攻击者的恶意网络攻击风险。两者在需求、架构、验证、变更和证据平台上存在大量交叉，因此企业不宜分裂建设。

三、法规压力与 CSMS 底座

图 3：法规压力与 CSMS 底座

UNECE 官方文件页面显示，UN Regulation No.155 的主题为车辆网络安全和网络安全管理系统，文件于 2021 年发布，形成了车辆型式批准背景下对网络安全管理系统的法规关注。[3]

在这种背景下，ISO/SAE 21434 的价值在于为 CSMS 和项目工程活动提供可执行的工程框架。CSMS 不应只停留在制度文件层面，而应能够驱动项目网络安全计划、TARA、网络安全需求、供应链接口、漏洞管理和持续更新机制。

有效 CSMS 至少应覆盖组织层、项目层和持续层。组织层定义政策、职责、能力建设、审核和持续改进；项目层定义网络安全计划、里程碑门禁、工作产品和评估机制；持续层负责威胁情报、漏洞管理、事件响应、安全更新和退役控制。

四、Item 定义与攻击面边界

图 4：Item 定义决定攻击面边界

网络安全 Item 定义是 TARA 的入口。企业需要先明确系统功能、边界、资产、接口、数据流、运行场景、外部依赖和供应商组件，才能识别真实攻击面。若 Item 定义不清，后续威胁场景、攻击路径和风险处置都会出现源头偏差。

对于车联网系统，攻击面不仅包括 ECU 本身，还包括诊断接口、OTA、云平台、移动端、车内网络、蜂窝通信、蓝牙、USB、V2X、密钥和证书、第三方软件以及供应商组件。每一次边界变化都应触发 TARA 复评、需求变更、验证回归和网络安全案例更新。

五、TARA：网络安全风险管理引擎

图 5：TARA 风险管理引擎

Threat Analysis and Risk Assessment（TARA）是 ISO/SAE 21434 网络安全工程的核心活动。公开技术资料说明，TARA 用于识别潜在威胁和风险，并为开发适当保护措施提供基础；威胁分析关注攻击向量、漏洞和攻击场景，风险评估则用于分析、评价和优先排序风险。[4]

TARA 的工程链路通常包括资产识别、损害场景、威胁场景、攻击路径、影响评估、攻击可行性、风险等级、风险处置、网络安全目标和网络安全需求。风险等级不应由主观判断决定，而应由影响后果与攻击可行性的结构化组合决定。

TARA 输出必须反哺需求、架构和验证。高风险威胁场景应形成网络安全目标和网络安全需求；关键攻击路径应驱动认证、授权、加密、隔离、日志、检测和更新机制；关键威胁场景应映射到漏洞扫描、安全测试、渗透测试和回归验证。

六、网络安全概念、架构对策与安全内建开发

图 6：网络安全概念连接需求与架构

图 7：产品开发需要安全内建

网络安全概念的任务是把 TARA 输出的风险语言转化为工程语言。网络安全目标应被分解为系统级、组件级和接口级网络安全需求，并进一步落到架构对策和实现机制，包括认证、授权、加密、密钥管理、完整性保护、隔离、日志、监测、安全更新和回滚控制。

产品开发阶段需要把网络安全内建到需求、设计、实现、集成和测试主流程。软件开发应覆盖安全编码、静态分析、依赖扫描和漏洞修复；硬件和通信设计应覆盖安全启动、密钥保护、调试控制、安全通信和重放防护；验证确认应覆盖接口测试、漏洞扫描、渗透测试和回归验证。

“后补安全”是常见失败模式。若 TARA 输出没有进入架构与需求，安全控制措施就难以实现或验证；若测试发现没有触发风险复评、漏洞关闭和回归验证，就会形成生命周期断点。

七、供应链与持续网络安全

图 8：供应链与持续网络安全闭环

车辆网络安全风险会通过供应商组件、第三方软件、开源组件、云端服务、移动端和售后更新持续变化。ISO/SAE 21434 的落地不能只覆盖 SOP 之前的开发活动，还必须覆盖 SOP 之后的漏洞管理、事件响应、安全更新、威胁情报和退役控制。

供应链接口是认证评估难点。OEM 与供应商之间应通过接口协议明确网络安全需求、工作产品、漏洞通知、变更责任、证据格式、假设限制和交付节奏。外购组件、第三方软件、开源组件和云服务应形成风险接受或处置依据，并能够支撑系统级网络安全案例。

八、网络安全案例与认证评估深度解读

图 9：网络安全案例是评估核心

图 10：认证评估阶段化路线

Cybersecurity Case 是认证或客户方评估的核心证据载体。它不是把所有文件简单汇总，而是用结构化论证说明网络安全目标已被满足、风险处置有效、残余风险可接受，并且生命周期证据能够持续更新。

评估通常包括准备评估、差距分析、CSMS 评估、项目评估、问题关闭和维持监督。准备评估确认范围、产品、组织边界和计划；差距分析识别流程和证据缺口；CSMS 评估关注组织治理和持续活动；项目评估抽查 TARA、需求、架构、测试、漏洞和网络安全案例；问题关闭验证不符合项、观察项和风险接受是否充分；维持监督则跟踪漏洞、变更、更新和持续改进。

评估的关键判断不是证据数量，而是同一风险是否能够从 TARA 追溯到网络安全目标、需求、设计机制、验证证据、漏洞关闭和持续活动记录。

九、企业落地路线图与成熟度模型

图 11：企业落地路线图与成熟度

企业推进 ISO/SAE 21434 落地应采用分阶段路线。第一阶段建设 CSMS，建立政策、职责、流程、模板、培训、审核和持续改进机制。第二阶段通过试点项目贯通 Item 定义、TARA、网络安全目标、需求、架构、验证和网络安全案例。第三阶段沉淀 TARA 方法、需求追溯、安全测试、供应链接口、漏洞管理和事件响应能力。第四阶段形成平台化资产和工具链自动化，包括资产库、威胁库、对策库、证据模板、度量看板和复用机制。

成熟度应从组织、项目、技术、供应链和持续活动五个维度衡量。组织维度关注 CSMS 有效性；项目维度关注计划、TARA、门禁和问题关闭；技术维度关注攻击面覆盖、架构对策和验证质量；供应链维度关注接口协议和第三方证据；持续活动维度关注漏洞、事件、更新和案例维护。

十、常见失败模式与纠偏策略

ISO/SAE 21434 落地失败通常不是因为完全没有网络安全活动，而是因为活动介入太晚、TARA 与架构脱节、证据链不连续、供应商边界不清、持续活动缺失或网络安全案例无法支撑残余风险结论。

十一、结论：从合规走向网络安全韧性

图 12：从合规走向网络安全韧性

ISO/SAE 21434 的价值不应被狭义理解为获得一次性评估结论，而应被理解为建立可证明、可复用、可持续改进的车辆网络安全工程能力。可证明意味着 TARA、需求、架构、测试、漏洞和网络安全案例之间存在可追溯证据；可复用意味着安全机制、威胁库、组件证据和接口假设能够跨项目沉淀；可改进意味着漏洞、事件、变更和更新能够反馈到 CSMS、流程、工具链和产品平台。

企业最现实的落地策略，是先建立 CSMS 和项目基本流程，再用试点项目贯通 TARA 与证据链，随后沉淀供应链、漏洞管理和安全测试能力，最终形成平台化网络安全资产和自动化度量体系。这样的路径不仅有助于认证或客户方评估，也能真实提升车辆产品面对持续变化攻击面的安全韧性。