一、什么是汽车网络安全

在智能网联和自动驾驶出现在汽车电子行业之前，功能安全一直是重中之重——如：ISO26262标准，随着智能网联汽车和自动驾驶的出现，汽车联网、车辆维护、交通安全信息共享等变得越来越普及，这增加了黑客攻击车辆的可能性，从而给汽车网络安全带来了新的风险。

考虑一下

如果“不良行为者”可以访问联网的汽车系统，会有什么风险？

①泄露个人信息

显示车辆位置的GPS数据可能被一系列犯罪活动利用，如敲诈勒索、知道何时无人在家，访问连接到车辆系统的手机，而手机里有很多个人信息，包括银行账户、卡号等

②干扰安全关键功能

③影响车辆系统

对车辆系统的干扰可能比较小，但也很令人讨厌。如阻止在线更新，破坏汽车充电计划等

汽车网络安全专注于阻止这些攻击！

二、ISO/SAE 21434发布背景

传统意义上的汽车嵌入式应用都是孤立的、静态的、功能固定的且特定于某个设备，传统的汽车软件开发流程也是针对这种状态的。但互联网汽车的出现改变了这一切，网络安全对车辆安全和数据保护至关重要。

考虑到汽车网络安全所面临的一系列挑战，安全可靠的智能网联汽车的生产和设计已成为行业焦点。在解决汽车网络安全问题上，尽管我们可以借鉴其他领域的一些成功经验，但是，汽车行业也面临一些“专属挑战”！

汽车行业意识到需要制定特定的行业标准，来解决汽车网络安全问题并保护个人资产。2016年，ISO与SAE International决定共同制定汽车网络安全行业标准。两个组织以往分别制定过汽车安全相关标准，ISO制定了功能安全标准ISO 26262，SAE制定了SAE J3061，这为网络安全标准奠定了基础。

当双方认识到有共同目标时，它们与整车厂（OEM）、ECU 供应商、网络安全厂商、监管机构以及来自超过 16 个国家/地区的 80 多家企业的 100 多位专家合作，建立了联合工作组以制定深度并有效的汽车网络安全全球标准。

工作组于2021年8月31日正式发布了汽车网络安全领域首个国际标准ISO/SAE 21434《Road vehicles—Cybersecurity engineering（道路车辆-网络安全工程）》，从此替代SAE International 2016年发布的 SAE J3061TM Cybersecurity Guidebook For Cyber-physical Vehicle Systems.

ISO/SAE 21434标准的目的有三个：

• 确定一个结构化的流程，以确保网络安全设计
• 降低被攻击的可能性，减少损失
• 提供流程方法，帮助车企应对网络安全威胁

ISO/SAE 21434 针对道路车辆及其部件、接口等提出了网络安全风险管理要求，定义了车辆从生产、运行、维护和退役等各阶段的要求。按照该标准设计、生产、测试的产品，意味着具备了一定网络安全防护能力。

三、LDRA ISO/SAE 21434符合性支持

LDRA可以支持的ISO/SAE 21434标准的阶段包括：

a. 持续的网络安全活动

b. 概念阶段

c. 产品开发

d. 网络安全确认

e. 运营和维护

3.1 持续的网络安全活动

3.2概念阶段

与功能安全需求不同，网络安全需求是通过威胁分析和风险评估 (TARA) 过程得到的。网络安全需求的追踪是 IEC/ISO 21434 的一个关键目标项，就像 ISO 26262 中的功能安全需求追踪一样。

概念阶段要求网络安全需求和网络安全目标之间的追踪性，当然，可追踪性的原则也贯穿于整个开发生命周期。例如：

• [RQ-10-02] 和 [RQ-10-03] ：需求和设计之间的追踪
• [RQ-10-08] 和 [RQ-10-09] ：组件实现和需求之间的追踪

跟踪项目需求追踪情况和标准中目标项符合情况，对于项目管理来说，都是很不容易的，尤其是当发生变更时。在许多情况下，项目可能还同时使用了ISO 26262，AUTOSAR 和 ASPICE 等标准，这给目标项的符合进一步增加了困难。

LDRA 工具套件的TBmanager组件可以实现自动化追踪， TBmanager不仅可以自动追踪来自于一个或多个标准的目标项，还可以追踪项目中的需求。

自动化的追踪可以确保用户获得最新的需求追踪矩阵，从而向用户即时的反馈任何失败的测试或变更的需求所带来的影响。

3.3产品开发

3.3.1细化网络安全需求和架构设计

LDRA 工具套件的TBvision组件可以用来检查代码对所选语言子集的遵守情况， 针对偏离项，用户可以使用TBexclude 给出解释说明，并生成到相应报告中。

IEC/ISO 21434标准建议使用合适的语言子集（通常称为编码标准），标准还将MISRA C和CERT C作为语言子集的示例。

从功能安全角度看，ISO 26262 也推荐了 MISRA 语言子集。

3.3.2集成与验证

IEC/ISO 21434中的需求[RQ-10-09]和[RQ-10-10]关注点是将组件集成到子系统/系统中，以验证结果是否满足网络安全规格说明。[RQ-10-10] 中强调了以下几种验证方法：

• 基于需求的测试
• 接口测试
• 资源使用评估
• 控制流和数据流验证
• 动态分析

以上这几种验证方法LDRA 工具套件都支持

• 基于需求的测试

基于需求的测试很重要，它不仅可以确认所有需求的都已实现，而且可以确认没有冗余的代码。这可以通过代码结构化覆盖分析（TBvision 和 TBrun）和需求追踪来实现（TBmanager）

• 接口测试

接口测试可以验证系统间、子系统间和组件间的交互是否正确。 TBrun 组件可以用来确认这些接口的功能正确性，TBextreme 可选模块可以帮助自动化部分测试工作

• 资源使用评估

证明资源充足（内存、时间、文件系统……）并消除竞争问题，对于联网系统来说是很重要的，尤其是遭受攻击的时候。LDRA 工具套件提供了动态测量执行时间的功能，而不是依赖于静态分析的估计值。

• 控制流与数据流验证

有缺陷的数据或控制流可能导致代码漏洞。 控制流和数据流分析可用来确认两者都符合系统设计。 TBvision 组件是为主机和嵌入式软件分析提供的一个图形化的静态和动态分析工具，动态数据流覆盖 (DDFC) 是一个可选模块，可确认程序动态执行时用到了哪些变量。

• 动态分析

动态分析是通用的软件测试方法，它可以分析软件的运行时行为，来对软件的全部或部分进行验证和确认。LDRA 的代码（结构化）覆盖分析和单元测试（TBrun）都是动态分析工具。

• 静态分析

静态分析是通用的软件测试方法，它通过分析源代码，来对软件进行验证和确认。 TBvision 组件支持质量度量，检查对MISRA 和 CERT 等编码标准的符合情况。

3.4运营和维护

与功能安全不同，网络安全系统的开发生命周期会一直延伸到产品发布之后，如需求 [RQ-13-01] 和 [RQ-13-02] 所要求的。

软件修改后，需进行编码标准检查、重新运行单元测试（回归测试）并针对变更进行影响域分析。

LDRA 工具套件提供了以上要求的所有功能。

结论

IEC/ISO 21434可以被认为是对ISO 26262的补充，因为它从网络安全的角度提供了最佳开发实践的指导，就像ISO 26262提供了解决功能安全的实践指导一样。

IEC/ISO 21434还要求采用与ISO 26262类似的健全的开发流程，并反映其开发阶段，因此这些标准并不矛盾，功能安全要求与网络安全要求相一致，设计必须同时反映安全和网络安全。

这两个标准都没有强制要求使用自动化工具，但很明显，除了最简单的项目，工具的使用几乎是必不可少的。正如这些标准相互补充一样，同样工具也可以同时用于支持这些标准。